یک اشتباه رایج در تست XSS
یه چیزی توی Search Box وارد میکنی.
بر میگرده توی صفحه.
بعد اولین فکری که میاد:
«خب، حالا یه Payload بزنیم ببینیم اجرا میشه یا نه.»
اینجا دقیقاً جاییه که خیلی از تست ها اشتباه شروع میشن.
قبل از Payload، من معمولاً یه سؤال ساده‌تر می‌پرسم:
این Input دقیقاً کجا قرار گرفته؟
داخل HTML؟
داخل یک Attribute؟
داخل JavaScript؟
توی URL؟
یا اصلاً JavaScript سمت Client داره این مقدار رو از جایی می‌خونه و وارد DOM میکنه؟
چون این:
<input>
به تنهایی چیزی بهت نمیگه.
مهم اینه که Application و Browser باهاش چه رفتاری میکنن.
یه سناریوی ساده:
تو Search میزنی:
THB
صفحه هم نشون میده:
Search results for: THB
خوبه.
حالا به جای اینکه سریع بری سراغ Payloadهای مختلف، مسیر مقدار رو دنبال کن.
Input → Source → Data Flow → Sink → Context → Execution
اگر بفهمی داده از کجا وارد شده و نهایتاً به کجا رسیده، تازه می فهمی باید دنبال چه چیزی بگردی.
حالا سه حالت اصلی XSS رو از هم جدا کن:
🔹 Reflected XSS
اInput از Request میاد و در Response برمیگرده.
🔹 Stored XSS
اInput ذخیره میشه و بعداً وقتی یک User دیگه صفحه رو می‌بینه، Render میشه.
🔹 DOM-Based XSS
این یکی جالب تره.
ممکنه Server اصلاً چیزی از Payload نبینه.
جاوااسکریپت سمت Client داده رو از یک Source میگیره و به یک Sink خطرناک میرسونه.
یعنی اگر فقط Responseهای Server رو نگاه کنی، ممکنه کل داستان رو از دست بدی.
حالا یه سؤال برای خودت:
فرض کن مقدار زیر رو وارد کردی:
THB123
و این مقدار داخل HTML صفحه ظاهر شد.
آیا همین به معنی XSS Vulnerability هست؟
اگر جوابت «بله» یا «نه» هست، دلیلش رو هم بنویس.
ببینیم چند نفر واقعاً Context رو بررسی میکنن، نه فقط دنبال Payload می گردن.
@TryHackBox
#تست_نفوذ #امنیت_سایبری