Cross Site Scripting - XSS - Part7

با سلام خدمت دوستان عزیز.

در این پست که آخرین پست از مجموعه پستهای XSS میباشد در مورد برخی تصورات اشتباه رایج در مورد XSS مطالبی بیان خواهد شد.

اگر شما مطالب قبلی در مورد XSS را نخوندین از لینکهای زیر استفاده نمایید:

Cross Site Scripting - XSS - Part1

Cross Site Scripting - XSS - Part2

Cross Site Scripting - XSS - Part3

Cross Site Scripting - XSS - Part4

Cross Site Scripting - XSS - Part5

Cross Site Scripting - XSS - Part6

 

برخی تصورات اشتباه در مورد XSS:

  • "آسیب پذیری XSS موجود در برنامه فقط در درخواستهایPOST  میباشد بنابراین هکر از طریق لینکهای مخرب در درخواستهای GET نمیتواند برنامه را مورد حمله قرار بدهد."

صرف نظر از تغییر Header های درخواست ارسال شده به سرور،  برای تبدیل کردن درخواستهای POST و GET به یکدیگر، ابزارهای Web Proxy  نظیر Burp Suite نیز براحتی قادر به انجام اینکار میباشند.

 اگر برنامه شما به درخواستهای POST وGET به یک شکل جواب میدهد برنامه آسیب پذیر است اما در غیر اینصورت نیز مهاجم وب سایت دیگری که دارای یک فرم با متد POST میباشد را راه اندازی میکند که در آن فرم، برنامه آسیب پذیر بعنوان Target URL تعریف شده و ارسال فرم با جاوا اسکریپت بصورت نامحسوس انجام خواهد شد و بدینوسیله هکر قادر به استفاده از آسیب پذیری برنامه میباشد.

  • "ما تمامی درخواستهای ارسالی به سرور را برای تگهای <Script> و همچنین کاراکترهای Quotation , Space بررسی میکنیم پس هیچگونه حمله XSS امکانپذیر نیست."

صرفنظر از روشهای مختلف برای Bypass کردن فیلترینگ برنامه، اصولا در بعضی از حملات XSS احتیاجی به استفاده از تگ <Script> نیست و مهاجم کد مخرب را مستقیما درون کدهای جاوا اسکریپت موجود در برنامه تزریق میکند و یا در بعضی موارد مهاجم، Event Handler که حاوی کد جاوا اسکریپت است را برای نفوذ به برنامه تزریق میکند. همچنین در حملات DOM-Based لزومی به ارسال کد مخرب به سمت سرور نیست و در سمت کلاینت میماند.

همچنین Elementهای HTML برای جدا کردن Attribute هایشان احتیاجی به Space ندارند. برای مثال کد زیر صحیح میباشد:

<img/src="."alt=""onerror="alert('zombie')"/>

یا  در جاوااسکریپت برای مشخص کردن Stringها لزوما احتیاجی به Quotation  نیست. برای مثال

alert(String.fromCharCode(62,72,61,69,6e,73,21));

alert(/flee humans/.source);

<iframe src=//site/page>

  • " ما از Web ApplicationVulnerability Scanner استفاده میکنیم و چون اسکنر هیچ باگی از نوع XSS پیدا نکرده پس از حملات XSS در امان هستیم"

هر چند بعضی از اسکنرها و ابزارهای Automated در حوزه برنامه های وب قادر به کشف باگهای متداول میباشند اما تعدادی از آسیب پذیریهای XSS براحتی قابل کشف نیستند. تا این تاریخ هیچ نوع ابزاری که بتواند باگهای  XSS را به شکل قابل اطمینانی پیدا کند وجود ندارد.

  1. "تمامی داده های ورودی به  برنامه را HTML Encode میکنیم پس از XSS در امان هستیم."

همانطوریکه در بخش output Encoding گفته شد Encoding های مختلف باید در جایگاه خودشان مورد استفاده قرار بگیرند. HTML Encoding فقط در مواردی که ورودی در داخل Body یک فایل HTML  قرار میگیرد کارآمد میباشد.( برای مثال داخل تگ <div>) اما در مواردی که ورودی در داخل تگ <script> یا یک Event Handler  مانند onmouseover یا داخل CSS قرار بگیرد باید از Encoding مناسب هر Context استفاده شود.(رجوع شود به بخش OutputEncoding). بنابراین فقط استفاده از HTML Encoding نمیتواند از حملات XSS جلوگیری نماید.

 

دوستان و سروران گرامی به انتهای مجموعه پستهای XSS رسیدیم. امیدوارم مطالبی که در این هفت پست ارائه شد مورد توجه و استفاده شما قرار گرفته باشه و همچنین از شما دوستان عزیز میخوام که نظرات خودتون را در مورد مطالب وبلاگ دریغ نفرمایید.

به امید خدا در روزهای آینده در مورد دیگر حملات متداول به برنامه های وب صحبت خواهم کرد.

پیروز و سربلند باشد.

/ 0 نظر / 80 بازدید