
در این بخش از دوره آموزشی تست نفوذ سطح متوسط که برگرفته از دوره SEC642 می باشد به مبحث آشنایی با DOM Based XSS می پردازیم.
آشنایی با آسیب پذیری XSS از نوع DOM Based
یکی از انواع حمله XSS که در طول تست شما مفید است، حمله XSS مبتنی بر DOM است. این نوع حمله در واقع یک نوع فرعی از حمله Reflected است. تفاوت اصلی XSS مبتنی بر DOM با Reflected این است که برنامه کاربردی Payload شما را منعکس نمیکند.
در برنامههای آسیبپذیر در برابر XSS مبتنی بر DOM، کدی در سمت مشتری وجود دارد که URL یا منابع دیگر را میخواند و از Document Object Model یا همان DOM استفاده میکند. برای مثال، یک برنامه میتواند URL را بخواند تا یک فیلد فرم را پر کند. اگر برنامه این عمل را از طرف مشتری انجام دهد، برنامه میتواند نسبت به این نقص آسیبپذیر باشد.
ما معمولا این نقص را در سیستمهای تجزیه و تحلیل یا مبتنی بر Mash-up پیدا میکنیم. این به دلیل نیاز برنامهها به استفاده از URLیا سایر اطلاعات در توابع آنها است.
XSS مبتنی بر DOM دقیقا یک نقص در کد سرور نهایی (Backend Server) نیست؛ به این معنی که به منظور اکسپلویت این آسیبپذیری، نیازی به ارسال موارد به سرور ندارد. درک این موضوع مهم است زیرا بسیاری از توسعه دهندگان این موضوع را درست درک نمیکنند و نمیدانند که چرا فیلتر کردن یا Encoding آنها بر روی سرور این مساله را حل نخواهد کرد.
روشی که در DOM – XSS انجام میشود این است که کاربر درخواستی را برای برنامه ارسال میکند. صفحه وب، به ویژه هر کارکرد سمت مشتری، از این مقادیر در پردازشهای خود استفاده میکند و سپس مرورگر آن را از داخل DOM اجرا میکند. وقتی این اتفاق میافتد، مرورگر متوجه نمیشود که حمله وجود دارد و کد فقط به عنوان بخشی از صفحه در نظر گرفته میشود. به همین دلیل است که میتوانیم بگوییم این آسیبپذیری در سمت کلاینت بوده و چیزی از سمت سرور را منعکس نمیکند.
اگرچه بطور سنتی متد GETجایی هست که شما این مشکل را در آن جا پیدا میکنید، اما میتوان از بسیاری منابع دیگر نیز برای شناسایی این آسیبپذیری استفاده کرد.
Traditional Reflected XSS Example
همانطور که در مثال زیر نشانداده شدهاست، یک کاربر میتواند درخواستی مانند تصویر زیر را ارسال کند:

این درخواست شامل یک پارامتر GET میباشد که اکسپلویت ما در آن قرار داده شده است. در یک آسیبپذیری Reflected XSS سنتی، سرور محتوای کاربر را میگیرد و آن را به HTML پاسخ اضافه میکند. همانطور که در اینجا نشانداده شدهاست، این موضوع باعث میشود مرورگر زمانی که آن کد را از سرور دریافت میکند، اسکریپت را اجرا نموده و Alert مد نظر را نمایش دهد که داخل آن عدد 42 نمایش داده می شود.
DOM Based XSS Example
همانطور که در مثال زیر نشانداده شدهاست، یک کاربر میتواند درخواستی مانند تصویر زیر را ارسال کند:

این درخواست شامل یک پارامتر GET میباشد که اکسپلویت ما در آن قرار داده شده است. زمانی که صفحه بارگذاری میشود، مرورگر، اسکریپت داخل صفحه را اجرا میکند.
اسکریپت در ابتدا، offset را در URL پیدا میکند که در آن رشته ” user=” رخ میدهد و ۵ را به آن اضافه میکند تا offset با مقدار تعریف شده توسط کاربر برای پارامتر “user” شروع شود. سپس اسکریپت مابقی URL را که در آفست شروع میشود مینویسد و این را به عنوان متغیر user ذخیره میکند. این احتمالا بهترین راه برای انجام این کار نیست چون فرض میکند که هیچ پارامتر دیگری بعد از این وجود ندارد، اما برای مثال ما جواب میدهد.
در نهایت، این متغیر user سپس با استفاده از document.write در صفحه (یا DOM) نوشته میشود که خروجی آن، همان صفحه در مثال قبلی میباشد. مشکل این است که وقتی اسکریپت به پارامتر user اضافه گردید، توسط تابع document.write() اجرا میشود. این متفاوت از مثال قبلی است زیرا سرور در پاسخ، اسکریپت را به ما ارسال نمیکند. در عوض، این کد JavaScript است که منجر به حمله XSS شده و کد را از URL خارج کرده و آن را به صورت محلی در مرورگر اجرا میکند. لازم به ذکر است که در هیچ نقطهای در این مدل، کد XSS از سمت سرور ارسال نمی شود.
به این Comment توجه کنید که چرا توسعه دهنده از تابع unescape() استفاده میکند.

بدون تابع unescape()، اگر کاربر نام خود را به صورت O’Hara وارد میکرد، متن وی به صورت O%27Hara بر روی صفحه نمایش چاپ میشد. از نظر توسعه دهندگان وب، سادهترین راه حل این مشکل، Escape نمودن آن است. با این حال، این چیزی است که باعث میشود آسیبپذیری رخ دهد زیرا حفاظت داخلی در نظر گرفته شده مربوط به URL-Encoding را حذف میکند. راه مناسب برای یک توسعه دهنده برای انجام این کار، URL Decode و سپس HTML Encode است، به طوری که نمادهای خاص در مرورگر به درستی چاپ شوند اما به عنوان کد دیده نشوند.
با این حال، نیاز امنیتی برای این کار برای اکثر توسعه دهندگان آشکار نیست، و حتی بدتر از آن، توسعه دهنده باید تابع HTML Encode خود را بنویسد؛ زیرا جاوا اسکریپت یک تابع بومی برای انجام این کار ندارد.
DOM Based XSS Inputs
همانطور که پیش از این بحث شد، بیشتر تستها به بررسی درخواستهای GET میپردازند. اگرچه این میتواند بسیاری از نقصهایی که در وب وجود دارند را پیدا کند، ولیJavaScript و DOM بسیار قدرتمندتر از این هستند. از آنجا که JavaScript میتواند از منابع مختلف استفاده کند، آسیبپذیری DOM – XSS را میتوان با استفاده از نقاط ورودی مختلف مورد بهرهبرداری قرار داد. این امر به طور کامل بستگی به آنچه که کد سمت مشتری در اجرای آن استفاده میکند، دارد. البته باید به خاطر داشته باشید که بسیاری از این موقعیتهای برای بهرهبرداری یا نشان دادن سختتر از موقعیتهای مبتنی بر GET هستند و حتی نیازی به پیلودهای خاص خود را دارند.
این نقاط ورودی به عنوان snik در نظر گرفته میشوند. مکانهای مختلف بسیاری میتوانند به عنوان snik در بهرهبرداری از آسیبپذیری DOM – XSS مورد استفاده قرار گیرند. مکانهایی مانند کوکیها، Referer، و پاسخهای درخواستهای XHR نمونه هایی از آنها هستند.
شناسایی آسیب پذیری XSS از نوع DOM Based
کشف آسیبپذیری هدف اصلی تست نفوذگر است. ما این فرآیند را در طول فاز Mapping حمله خود، مانند بسیاری از آسیبپذیریها، آغاز میکنیم. ما از نقشه برنامه خود استفاده میکنیم و به دنبال تمام کدهای سمت مشتری هستیم. با بررسی این کد، میتوانیم مکانهایی را پیدا کنیم که در آن کد از “Snik” در اجرا و پردازش آنها استفاده میکند. سپس سعی میکنیم مشخص کنیم که آیا میتوانیم از آن استفاده کنیم یا خیر.
این آسیبپذیریها را میتوان از طریق تکنیکهای دستی یا با استفاده از مجموعه ابزارهای تخصصی یافت. ابزار OWASP ZAP میتواند حملات DOM – XSS را شناسایی و اجرا کند. لازم به ذکر است که اگر چه بهره گیری از روشهای دستی برای شناسایی آسیبپذیری XSS مبتنی بر DOM مناسب میباشد ولی در سایتهای بزرگ، استفاده از ابزارهای خودکار میتواند به ما کمک نماید.
ابزارهایی مانند Burp Suite و BC Detect هم گزینههای دیگری برای این موضوع میباشند.
اکسپلویت آسیب پذیری XSS از نوع DOM Based
بهرهبرداری از DOM – XSS در طول یک تست نفوذ به دلیل عدم درک بسیاری از افراد با آن مهم است. از آنجا که آنها نمیدانند حمله چگونه کار میکند، ارزیابی سطح ریسکی که در برنامه در معرض آن قرار میگیرد برای آنها دشوار است. این بدان معنی است که حتی مهمتر این است که شناسایی آسیبپذیری ما با اجرای حمله همراه باشد و مشکلاتی که این آسیبپذیری میتواند ایجاد کند را نشان دهند. (Impact)
خوشبختانه برای ما، بهرهبرداری از XSS مبتنی بر DOM تفاوتی با بهرهبرداری از دیگر انواع نقصهای XSS ندارد. ما میتوانیم از تمام اکسپلویتهای معمول خود استفاده کنیم و آنها به یک روش کار میکنند.