Cross-site scripting (XSS)
زمان مطالعه :5 دقیقه
Reflected XSS, Impact, Contexts, Testing, FAQs
Reflected XSS
در این بخش، cross-site scripting را توضیح میدهیم، تأثیر reflected XSS attacks را شرح میدهیم، و نحوه یافتن آسیبپذیریهای reflected XSS را توضیح میدهیم.
?What is reflected cross-site scripting
Reflected cross-site scripting (یا XSS) زمانی رخ میدهد که یک برنامه کاربردی دادهای را در یک HTTP request دریافت کرده و آن داده را به صورت ناایمن در پاسخ فوری (immediate response) خود قرار میدهد.
فرض کنید یک وبسایت دارای یک تابع جستجو (search function)است که عبارت جستجوی ارائه شده توسط کاربر را در یک URL parameter دریافت میکند:
https://insecure-website.com/search?term=gift
برنامه عبارت جستجوی ارائه شده (supplied search)را در پاسخ به این URL بازتاب میدهد:
<p>You searched for: gift</p>
با فرض اینکه برنامه هیچ پردازش دیگری بر روی دادهها انجام نمیدهد، یک attacker میتواند حملهای به شکل زیر بسازد:
https://insecure-website.com/search?term=<script>/+Bad+stuff+here...+/</script>
این URL منجر به پاسخ زیر میشود:
<p>You searched for: <script>/* Bad stuff here... */</script></p>
اگر کاربر دیگری از برنامه این URL مهاجم را درخواست کند، اسکریپتی که توسط مهاجم ارائه شده است در مرورگر کاربر قربانی اجرا خواهد شد، در زمینه session آنها با برنامه.
Impact of reflected XSS attacks
اگر یک attacker بتواند اسکریپتی را کنترل کند که در مرورگر قربانی اجرا میشود، معمولاً میتواند به طور کامل آن کاربر را در اختیار بگیرد. در میان چیزهای دیگر، مهاجم میتواند:
· هر عملی را که کاربر میتواند در برنامه انجام دهد، انجام دهد.
· هر اطلاعاتی را که کاربر قادر به مشاهده آن است، مشاهده کند.
· هر اطلاعاتی را که کاربر قادر به تغییر آن است، تغییر دهد.
· تعاملاتی با سایر کاربران برنامه، شامل حملات مخرب، که به نظر میرسد از طرف کاربر قربانی اولیه آغاز شده است، شروع کند.
روشهای مختلفی وجود دارد که یک attacker ممکن است یک کاربر قربانی را به ارسال درخواستی که کنترل میکند، تحریک کند تا یک حمله reflected XSS را تحویل دهد. این شامل قرار دادن لینکها در یک وبسایت کنترل شده توسط مهاجم، یا در وبسایت دیگری که اجازه تولید محتوا میدهد، یا ارسال لینک در یک ایمیل، توییت یا پیام دیگر میشود. حمله میتواند مستقیماً علیه یک کاربر شناخته شده هدف قرار گیرد، یا میتواند یک حمله بیتفاوت (indiscriminate attack)علیه هر کاربر برنامه باشد.
نیاز به یک مکانیزم تحویل خارجی برای حمله به این معناست که تأثیر reflected XSSعموماً کمتر از stored XSS شده است، جایی که یک حمله خودکفا میتواند در خود برنامه آسیبپذیر، تحویل داده شود.
Read more
Exploiting cross-site scripting vulnerabilities
Reflected XSS in different contexts
انواع مختلفی از reflected cross-site scripting وجود دارد. مکان reflected data در response برنامه تعیین میکند چه نوع payloadی برای بهرهبرداری مورد نیاز است و ممکن است تأثیر آسیبپذیری را نیز تحت تأثیر قرار دهد.
علاوه بر این، اگر برنامه هر گونه اعتبارسنجی (validation)یا پردازش دیگری بر روی دادههای ارسالی انجام دهد قبل از بازتاب (reflected)آن، این عموماً بر نوع payload XSS مورد نیاز تأثیر میگذارد.
Read more
How to find and test for reflected XSS vulnerabilities
اکثریت عظیم آسیبپذیریهای reflected cross-site scripting میتوانند به سرعت و به صورت قابل اعتمادی با استفاده از Burp Suite's web vulnerability scanner پیدا شوند.
آزمایش دستی برای آسیبپذیریهای reflected XSS شامل مراحل زیر است:
· Test every entry point. هر نقطه ورود (entry point)داده را در HTTP requestهای برنامه به صورت جداگانه آزمایش کنید. این شامل parameters یا دادههای دیگر در URL query string و message body و مسیر فایل URL میشود. همچنین شامل HTTP headers میشود، اگرچه رفتار XSSمانندی که تنها از طریق برخی HTTP headers قابل فعالسازی است ممکن است در عمل قابل بهرهبرداری نباشد.
· Submit random alphanumeric values. برای هر نقطه ورود(entry point)، یک مقدار تصادفی منحصر به فرد ارسال کرده و تعیین کنید آیا مقدار در پاسخ بازتاب داده میشود یا خیر. مقدار باید به گونهای طراحی شود که اکثر اعتبارسنجیهای ورودی را تحمل کند، بنابراین باید نسبتاً کوتاه باشد و تنها حاوی حروف و اعداد باشد. اما باید به اندازهای بلند باشد که احتمال تطابق تصادفی در پاسخ را به شدت کاهش دهد. یک مقدار تصادفی الفبایی عددی حدود ۸ حرف معمولاً ایدهآل است. میتوانید از Burp Intruder's number payloads با مقادیر تصادفی hex تولید شده برای ایجاد مقادیر تصادفی مناسب استفاده کنید. و میتوانید از Burp Intruder's grep payloads settings برای خودکارسازی پرچمگذاری (automatically flag responses) پاسخهایی که حاوی مقدار ارسال شده هستند استفاده کنید.
· Determine the reflection context. برای هر مکان در response که مقدار تصادفی بازتاب (reflected)داده شده است، context آن را تعیین کنید. این ممکن است در متن بین HTML tags، در یک ویژگی tag که ممکن است نقل قول (quoted)شده باشد، در یک رشته JavaScript، و غیره باشد.
· Test a candidate payload. بر اساس context بازتاب، یک XSS payload کاندید اولیه را آزمایش کنید که اجرای JavaScript را فعال میکند اگر به صورت تغییرنیافته در پاسخ بازتاب داده شود. سادهترین راه برای آزمایش payloadها ارسال درخواست به Burp Repeater است، درخواست را برای وارد کردن payload کاندید تغییر دهید، درخواست را ارسال کنید، و سپس پاسخ را بررسی کنید تا ببینید آیا payload کار کرده است یا خیر. یک راه کارآمد این است که original random value را در درخواست بگذارید XSS payload کاندید را قبل یا بعد از آن قرار دهید. سپس random value را به عنوان Burp Repeater's response view تنظیم کنید. Burp هر مکان را که عبارت جستجو در آن ظاهر میشود برجسته میکند، به شما اجازه میدهد تا بازتاب را به سرعت پیدا کنید.
· Test alternative payloads. اگر XSS payload کاندید، توسط برنامه تغییر داده شده یا به کلی مسدود شده باشد، باید payloadها و تکنیکهای جایگزین را آزمایش کنید که ممکن است یک حمله XSS کارآمد را بر اساس context of the reflection و نوع اعتبارسنجی ورودی (input validation)که انجام میشود، تحویل دهند. برای جزئیات بیشتر، به cross-site scripting contexts مراجعه کنید.
· Test the attack in a browser. در نهایت، اگر موفق به پیدا کردن یک payload شوید که به نظر میرسد در Burp Repeater کار میکند، حمله را به یک مرورگر واقعی منتقل کنید (با چسباندن URL در نوار آدرس، یا با تغییر درخواست در Burp Proxy's intercept view) و ببینید آیا JavaScript تزریق شده واقعاً اجرا میشود. اغلب، بهتر است برخی JavaScript ساده مانند alert(document.domain) را اجرا کنید که اگر حمله موفق شود یک پنجره پاپآپ قابل مشاهده (visible popup within)در مرورگر ایجاد میکند.
Common questions about reflected cross-site scripting
تفاوت بین reflected XSS و stored XSS چیست؟ reflected XSS زمانی رخ میدهد که یک برنامه برخی ورودیها را از یک HTTP request دریافت کرده و آن ورودی را به صورت ناایمن در پاسخ فوری جاسازی میکند. با stored XSS شده، برنامه به جای آن ورودی را ذخیره کرده و آن را به صورت ناایمن در یک پاسخ بعدی جاسازی میکند.
تفاوت بین reflected XSS و self-XSS چیست؟ Self-XSS شامل رفتار برنامه مشابه با reflected XSS عادی است، اما نمیتواند به روشهای عادی از طریق یک URL ساخته شده یا یک cross-domain request فعال شود. به جای آن، آسیبپذیری تنها زمانی فعال میشود که قربانی خودش payload XSS را از مرورگرش ارسال کند. تحویل یک حمله self-XSS معمولاً شامل فریب اجتماعی قربانی برای چسباندن برخی ورودیهای ارائه شده توسط مهاجم در مرورگر خودشان است. به همین دلیل، به طور معمول به عنوان یک مسئله کماهمیت و بیتأثیر در نظر گرفته میشود.
امیر رضا کبریادار
مشاهده مقاله های بیشتر
مقالات مرتبط
What is XSS, How does XSS work? Impact of an attack
زمان مطالعه :6 دقیقه
.Stored XSS, Impact , Contexts, Testing for vulnerabilities
زمان مطالعه :3 دقیقه
DOM-based XSS, Testing, Exploiting
زمان مطالعه :8 دقیقه
XSS contexts: Between HTML tags, In HTML tag attributes, JavaScript, Client-side template injection
زمان مطالعه :6 دقیقه
Exploiting XSS vulnerabilities & Dangling markup injection
زمان مطالعه :4 دقیقه