چجوری dompurify رو دور زدم و از ناهمانگی با مرورگر باگ xss زدم ؟

خیلی خلاصه بریم سراغ اصل مطلب, چجوری این لایبری امن توی چه شرایطی و با چه پیلودی ناامن شد ؟
همونطور که میدونید و باید بدونید xss جزو باگ هایی که هیچ وقت تمومی نداره و روز به روز بیشتر هم میشه ولی یه باگی مثل sqli کلا ریت کشف اسیب پذیریش 1 درصده و داره منقرض میشه چون کتابخونه به اسم orm اونو به صورت کامل امن میکنه .
همونطور که ثابت شده xss کتابخونه ای و یا راه حلی برای امن شدنش نیومده که کاملا 100 درصد دقیق باشه و جلوشو بگیره .

بیایم مرحله به مرحله و دقیق برسیش کنیم .
وقتی من به عنوان یه کلاینت یه پیلود xss رو وارد میکنم چه اتفاقی میوفته واسش ؟
یه پکت http ارسال میشه و توی سرور لایه های زیاد امنیتی رو میگذرونه تا برسه به ui و توی سورس بشینه و مروگر اونو اجرا کنه .

سوال من اینه ایا ui جای درستی برای جلوگیری از پیلود مخرب جاوا اسکریپته ؟
بله , بهترین راه برای جلوگیری xss همون مرحله اخر و جلوگیری ازش توی Ui هست

اینجا دلوپر سایت میتونه از وف استفاده کنه میتونه از encoding های مختلف و .. استفاده کنه .

ولی بازم یه سوال مهم داریم که ایا کافیه ؟

ایا ممکن نیست اون وف با یه پیلود خاصی گیج بشه و دور بخوره ؟

قطعا ممکنه .!
اینو بدونید اخرین ورژن و نسخه نهایی پیلود شما توی dom میشینه نه سورس !

خب اینجا میرسیم سراغ dompurify یه افزونه یا یه لایبرری که باعث از بین رفتن xss میشه چون دقیقا جلوی xss در اخرین مرحله توی dom گرفته میشه و بهترین راه حله . ولی کسب و کار ها و وبسایت نسبت به پیچیدگی و منطق تارگت نمیتونن همیشه از این لایبرری استفاده کنن.

بریم سراغ سناریو اسیپ پذیر :

هفته پیش یه ریسرچ عمیق راجب mxss ها کردم روال کار این پیلود ها در واقع پیلود هاییه که با ترکیب کردن چند نوع تگ پیلود ساخته میشه و خروجی پیلود باعث xss میشه .

تارگت من از dompurify استفاده میکرد و فرض بگیرین یه قسمت سرچ معمولی داشت :

target/q=test

و وقتی یه پیلود وارد میکردم خودکار توسط dom تگ غیرمجاز برداشته میشد و پیلود اجرا نمیشد ❌

توی تحقیقاتم به یه پیلود مثل این رسیدم :

<nonoscript><style></nonoscript><img src=X onerror=alert(orgin)>

و من همینو توی پارامتر گذاشتم و xss اجرا شد و من الرت رو دیدم :)

سوالی که پیش میاد اینه که چرا XSS شد و چرا یه لایبرری امن با همچین پیلودی نا امن شد ؟

عدم توافق بین دو عنصر و یا مرورگر و DOMPURIFY باعث باگ من شد.

لایبرری dompurify این پیلود رو XSS نمی دید و نمیشناخت و اول تگ nonoscript رو میدید که باز شده و بعدش یه استایل وجود داره که باز شده پس ادامه پیلود داخل تگ استایله و nonoscript/ اجرا نمیشه و به عنوان یه ولیو بی ارزش در نظر گرفته میشه و بهش گیر داده نمیشه :

<style></nonoscript><img src=X onerror=alert(orgin)> —> dompurify

ولی وقتی این پیلود به dom مرورگر میرسه اول no noscript با هر ولیوی که داخلشه کنار میره و img اجرا میشه :

<img src=X onerror=alert(origin)> —> browser

هیچکدوم از این پارس ها بین مرورگر و این لایبرری نا امن نبود ولی فقط توافقی بین مرورگر و dom purify وجود نداشت این عدم ناهماهنگی بین دو عنصر امن باعث xss شد :)🌷

@Dagen_security

چت گروه باز شد و از این بعد میتونیم با هم اینترکشن داشته باشیم و دانشمون رو به اشتراک بزاریم و از همدیگه سوال بپرسیم ..
بحث غیر و مربوط و یا بداهه لطفا نداشته باشید و در غیر این صورت ریمو میشید

امیدوارم این کمک کنه تا یه فضای جذاب و بدرد بخور داشته باشیم که هم برای من و هم مخاطب این کانال مفید باشه ❤️🔥

توی پست های بعدی قراره بریم سراغ حمله csrf . همونطور که میدونید این حمله یه حمله پنهانه و میتونه شدت اسیپ پذیری بالایی داشته باشه . برسی میکنیم چه پارامتر ها و چه چیزهایی باعث شکست خوردن این حمله میشه و مرورگر چجوری به عنوان یه دستیار ماهیت این حمله رو شکل میده .

پست بعدی قراره نیست فقط درباره اکسپولیت حرف زده بشه قراره از دید برنامه نویس به قضیه نگاه کنیم
و ببینیم برنامه نویس با چه فکری و با دقیقا چه کاری به فرض خودش جلوی این حمله رو میگیره ؟!

در ضمن Xmind بالا میتونه موضوع تحقیقاتی خوبی براتون باشه , چرا اون پروتکشن خاص همیشه امنه ؟!
ریکشن و انرژی کم باعث از بین بردن و نیست شدن پست بعدی میشه.

@Dagen_security

نیاز دونستم که اینو بزارم چون سوال اکثریت بود که چی بخونم چه مدرسی بهتره ؟
از کجا بدونم دانشم کامل و کافیه برای هدف نهایی یعنی باگ زدن ؟

پیام بالا رو بخونید👆

90 درصد کسایی وارد این حوزه میشن بعضیاشون دنبال یه راه سریعن همیشه دوره رو انتخاب میکنن و حین دوره همچیز خوب بنظر میاد و وقتی میرسن به انتهای دوره فلانی و تارگتتو باز میکنن مغز کاملا هنگه چون درک عمیقی نداره نمیدونن از کجا شروع کنند و دوباره باید رو دانش خودشون سرمایه گذاری کنند .

ولی 10 درصدی که عزم رو جزم میکنن و میرن سراغ خودخوان بودن و کتاب خوندن درسته که مسیر سخت تره و گمراه تره ولی به شما نظم میده و سختی که به شما میده شما رو تبدیل به یه فرد خود اموز میکنه که در ادامه اینقدی که مسیر بالا و پایین داشته بلاخره راه درستو پیدا میکنین

به عنوان کسی که همیشه کسب علم بهم انگیزه ادامه کار میده و توی این حوزه مشغول به کارم , نمیگم دوره چیز بدیه ولی بدونین که چقد تفاوت بین هر انتخابی که دارید هست و هدف مرکزیتون دقیقا چیه ؟

هوشمند باشید 🌷

نتیجه یه هفته ریسرچ خفن روی oauth و autorization شد یه xmind با تاپیک های عظیمو جثه ای که بالا میبینید .👆

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

بروز بودن خیلی مهمه و اینکه شما هر روز از هر مبحث یه نکته اضافه تری یاد بگیرید و درک کنید قطعا در اینده براتون هینتی میشه که باگای خلاقانه تر و قشنگ تر بزنید .

خیلی دوس داشتم راجب oauth پستی بزارم و فکر میکنم همتون توی برسی هاتون این نوع احراز هویت رو دیدید که مثلا میتونید با اکانت گوگلتون توی حسابتون لاگین کنید
چون درک این فلو خیلی جذابه و دقیقا باگ های کریتیکال و خطرناک همونجاست پس ما چرا سمتش نریم و به جای اینکه کامند فلان ابزار کنیم بریم سراغ تحلیل این نوع احراز هویت و حالت های مختلف پیاده سازی .

مثال میزنیم اگه یه روزی وب اپلیکشنی مثل تارگتتون به عنوان یه احرازهویت جدید از oauth استفاده کرد تا کاربراشون راحت تر لاگین انجام بدن یه مهاجم چه چیزهایی رو تست میکنه و چه باگ هایی از دل این پیاده سازی میزنه بیرون !؟

خیلی از مباحث نمیتونه در قالب یه پست تموم بشه چون نیاز به درک عمیق و زمان زیادی داره ولی همیشه سعی کردم دید کلی رو منتقل کنم تا یه هینتی بشه برای اینکه شروع کنی و خودتو تکون بدی .

در ضمن دوستانی که از قبل xmind اوسپ پیش نیاز من رو گرفتند و به عنوان یه رودمپ کامل برای پیشنیاز ازش استفاده کردند
به پشتیبانیم پیام بدن و web application vulenrability xmind اسیپ پذیری و تست کیس هایی که روی تارگت واقعی انجام دادم و هر نکته ای که توی مسیر کارم بهش اضافه کردم برای تست وب اپلیکشن , و باهاش باگای زیادی زدم رو به عنوان هدیه رایگان ازم دریافت کنن .

و دوستانی که به هر دلیلی رودمپ رو ندارند و به کار من ایمان دارند و میخوان xmind پیشنیاز اوسپ + هانت رو داشته باشند کافیه به پشتیبانی من پیام بدن تا شرایط رو بدونن و به عنوان یه اهرم از این تست کیس ها توی هانت خودشون استفاده کنن .

ایدی پشتیبان : @bookmind369

چون معتقدم اشتراک دانش مفید باعث خلق باگای بیشتر میشه و جامعه متخصص ها قوی تر و بیشتر میشه 🙌

همین الان با بچه های تیممون روی یه سامانه کار کردیم و دقیقا یکی از تست های oauth مون خورد :)

بچها باگه اینجوری بود که توی oauth وقتی پارامتر scope که پرمیزشن ها رو برای گرفتن اکسس توکن نهایی تعیین می‌کنه رو مقدار ایمیل رو ازش بر می‌داشتی و بدون ایمیل میفرستادی :

scope=openid%20name

میرفتی توی اکانت آخرین نفری که توی سایت ریجستر کرده 😂


شدیداً دوسش داشتم چون تست خیلی قشنگ و سریعی بود که منجر به یه باگ high لول شد :)

تبریک نداره ؟🫶

@dagen_security

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

اولین سوالی که باید از خودمون بپرسیم اینه : csrf چیه ؟

وقتی من به عنوان یه مهاجم کاربری مجبور کنم کاری کنه که نمیخواد این میشه crsf .
خب یه سوال دیگه برامون پیش میاد : من چجوری میتونم کاربر رو مجبور به انجام کاری کنم ؟

دقیقا قراره راجب همین موضوع صحبت کنیم ; ما میتونیم از طرف کاربر درخواست ارسال کنیم و اون درخواست میتونه کوکی داشته باشه و اگه اون کوکی privilage باشه چه اتفاقی میوفته !؟

موضوع اول : درخواستی که کاربر میخواد انجام بده حتما باید با یه state یا یه حالتی داخلش تغیر بکنه مثال forget_password که پسورد یوزر داخلش تغیر میکنه

با موضوع اول توضیحم تکمیل تر شد باید کاربر رو مجبور به کاری کنیم که نمیخواد و توی این کار باید حتما یه استیت و یا پروفایل و یا پسورد کاربر تغیر بکنه
یعنی کاربر باید http requset بفرسته .

بریم سراغ شرط های این اسیپ پذیری :

1 - برای اینکه یه وبسایت به csrf اسیپ پذیر باشه حتما باید با کوکی کار کنه چون مرورگر به صورت اتوماتیک رو میزاره توی هر درخواست هر چیزی جز این باعث اجرا نشدن حمله میشه
2 - قوانین same site نباید فعال باشه - حمله شکست میخوره ! مگه اینکه شرایط خاصی وجود داشته باشه
3- درخواست http که ما میخوایمcsrf کنیم باید حتما simple باشه و گرنه یه preflight زده میشه . یعنی چی شما از کجا میفهمی یه درخواست simple هست؟

HTTP methods: GET,POST,HEAD
headers: referer,user-agent,cookie (browsers header automaticity send )
content-type: application/X-www-form-url-encoded , text/plain , multipart/form-data

4- فرض کنیم پکت HTTP ما همه این شرایط رو داشت ایا csrf ممکنه ؟

نه یه چیز دیگه حتما باید چک بشه ,درخواستی که شما ارسال میکنی , حتما باید تکرار پذیر باشه و توی بادی نباید پارامتری یا شناسه ای داشته باشه که توی هر درخواست تغیر کنه اگه یه رندوم استرینگ و یا نامبر مخصوص یه کاربر باشه این باعث شکست خوردن حمله میشه ( کاری که وردپرس میکنه !)

بریم سراغ پروتکشن ها , برنامه نویس ها برای جلوگیری از این اسیپ پذیری کجا ها چک های امنیتی رو میزارن !؟

راه اول : گذاشتن csrf token هستش که توی هر درخواست قرار داده میشه و خیلی راه برای دور زدنش وجود داره .

راه دوم : چک کردن ریفرر ( اگه من به عنوان کلاینت چینچ پسورد انجام بدم و ریدارکت بشم ریفرر من خود سایته و ولیده ) پس من اگه حمله انجام بدم ریفرر میشه یه سایت جز سایت اصلی و حمله شکست میخوره و اجرا نمیشه که تقریبا پروتکشن خیلی خوبیه ولی همیشه نمیتونه سیف باشه (کاری که فیسبوک قبلا انجام میداد!)

راه سوم : که من یه راه فول سیف میبینمش اینه که اینه وب سرور توی هر درخواستی که ارسال میکنه یه هدر کاستوم بزاره مثل x-test که با این کار باعث میشه هیچ درخواست simple وجود نداشته باشه و حمله ها شکست میخورن .

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

امیدوارم یه درک نسبی راجب csrf گرفته باشید و هینت گرفته باشید که شرایط اجرای این حمله دقیقا چیه , حمایت از پست ها فراموش نشه 🌷

@Dagen_security

برای پست بعدی قراره دوباه بریم سراغ sql-injection ولی نه یه تزریق معمولی توی کوعری استرینگ . تزریق sql توی هدر user-agent بود که تایم بیس sql-injection میخورد
باگی که روی یه پروگرم نسبتا ریت خوب توی پلتفرم integrity زدم و میخوام براتون شرح بدم که درسته sqli در حال منقرض شدنه ولی دقیقا کجا ها میتونید در حال حاضر پیداش کنید .🫡
ریکشن و انرژی بدید تا بریم برای اماده سازی پست بعدی رفقا 🙌

شکار باگ SSTI؛ چطوری مهاجم از یه فیلد ساده به SSTI رسید ؟

توی این رایتاپ، شکارچی نشون میده که چطوری با زیرکی تونسته آسیب‌پذیری SSTI (تزریق به قالب سرور) رو پیدا کنه. این باگ وقتی پیش میاد که سرور، ورودی کاربر رو مستقیم بذاره وسط کدهای Template خودش.

فلو و مراحل هانت:

1️⃣پیدا کردن هدف: یک فیلد ورودی (مثل اسم کاربر یا نام پروفایل) که حدس می‌زد توسط موتور قالب‌ساز (مثل Jinja2 یا Twig) پردازش می‌شه.

2️⃣ تست جادویی (Polyglot Payload): هانتر از عبارت‌های محاسباتی استفاده کرد؛ مثلاً وارد کردن {{7*7}}. اگه سایت عدد 49 رو نشون بده، یعنی تبریک! موتور قالب داره کد شما رو اجرا می‌کنه.

3️⃣ شناسایی موتور (Fingerprinting): هر موتور قالب (Template Engine) سینتکس خاص خودش رو داره. با تست کردن پی‌لودهای مختلف، مشخص شد که سیستم از چی استفاده می‌کنه.

4️⃣ حمله نهایی (Exploit): حالا که راه باز شده، هانتر به جای عدد، کدی زد که بتونه فایل‌های سرور رو بخونه یا دستورات سیستم‌عاملی رو اجرا کنه (RCE).

✅ نکته طلایی: همیشه لازم نیست دنبال باگ‌های پیچیده باشید؛ گاهی اوقات تست کردن یک عبارت ریاضی ساده توی فیلد پروفایل، می‌تونه کل دسترسی سرور رو بهتون بده!

🔗 لینک مقاله: SSTI on YesWeHack

جزئیات فنی هک میلیون‌ها خودروی KIA 🔥

تیم سم کری (Sam Curry) نشون داد که چطوری یه اشتباه توی طراحی API می‌تونه فاجعه بسازه. اینجا بحث هک کردن خودِ ماشین نبود، بحث دور زدن پورتال مدیریت کیا بود.

فلوچارت دقیق حمله:

1️⃣ دور زدن ثبت‌نام (HTTP Request Tampering): اونا دیدن که پورتال نمایندگی‌های کیا (kiadlp.com) موقع ثبت‌نام، چک نمی‌کنه که آیا ایمیل شما واقعاً متعلق به یه نماینده‌ست یا نه. با تغییر دادن پارامترها در ریکوئست ثبت‌نام، تونستن یه Token سطح بالا (مخصوص تعمیرکارها) بگیرن.

2️⃣ نقطه ضعف در API (IDOR): این هکرها به یه پکیج از APIها رسیدن که وظیفه‌اش وصل کردن اپلیکیشن موبایل به ماشین بود.

اونا فهمیدن با داشتن VIN (شماره شناسایی خودرو)، می‌تونن دستور get_owner رو صدا بزنن.

خروجی این API چی بود؟ ایمیل و شماره تماس صاحب ماشین!

3️⃣ تزریق ایمیل هکر به ماشین: حالا که ایمیل صاحب رو داشتن، از یه متد دیگه به اسم add_command استفاده کردن. اونا یه درخواست فرستادن که: "این ایمیل (ایمیل هکر) رو به عنوان دسترسی ثانویه به این ماشین (با این VIN) اضافه کن."

نکته حساس: سیستم هیچ تاییدیه یا OTP برای صاحب اصلی ماشین نفرستاد!

4️⃣ اجرای فرمان در ۴۰ ثانیه: تیم یه اپلیکیشن ساده نوشتن که کل این پروسه (پیدا کردن ایمیل صاحب -> اضافه کردن هکر -> ارسال دستور باز شدن در) رو در کمتر از ۴۰ ثانیه انجام می‌داد. یعنی فقط با داشتن پلاک، ماشین زیر پای طرف باز می‌شد!

⚠️ باگ‌های کلیدی که باعث این فاجعه شد:

عدم احراز هویت درست (Broken Authentication): پورتال نمایندگی به هر کسی اجازه ورود داد.

افشای اطلاعات حساس: API نباید ایمیل صاحب ماشین رو به بقیه برمی‌گردوند.

نبود کنترل دسترسی (BOLA/IDOR): هر کسی می‌تونست برای هر ماشینی دستور "اضافه کردن کاربر" بفرسته.

لینک مقاله : Hacking Kia

SSTI یه چک لیست ساده واسه تست اولیه

این تصویر خیلی تصویر قشنگ و درستیه 🫡

1 - این تصویر به ما میگه برای تست اولت ${{7*7}} رو تست کن
اگه جواب داد و به سمت خط سبز رفتی اسیپ پذیره و برو برای ادامه تست و اکسپولیتش .

2 - اگه جواب نگرفتی و عدد 49 رو ندیدی و به سمت خط قرمز رفتی , برای تست دومت علامت ($) رو بردار و بدونش تست کن :

{{7*7}}

اگه دوباره جواب نگرفتی و عدد 49 رو ندیدی , بیخیال تست شو چون اسیپ پذیری نیست !

و اگه 49 رو دیدی یعنی اسیپ پذیره یه هفت رو استرینگ کن این پیلود رو تست کن :

{{7*'7'}}

این پیلود باعث چاپ شدن هفتای زیادی توی صفحه میشه
اگه جواب داد یا jinja2 هستش و یا یه انجینی که نمیدونیم :)

@Dagen_security

فرایند کشف آسیب پذیری PDF-based Stored XSS روی یک وبسایت فروشگاهی ایرانی ✍

اول از همه بریم ببینیم اصلاً PDF-based Stored XSS چیه.

همون‌طور که می‌دونید Stored XSS جزو آسیب‌پذیری‌های خطرناک محسوب می‌شه، چون Payload روی سرور ذخیره می‌شه و هر کسی که بهش دسترسی داشته باشه، اکسپولیت می‌شه.

معمولاً برای پیدا کردنش سراغ پروفایل کاربری، احراز هویت، کامنت‌ها، تیکت‌های پشتیبانی و جاهایی که از کاربر ورودی گرفته میشه میریم.

ولی خیلی وقت‌ها WAF ( Application Firewall) اجازه نمیده Payload های مخرب xss  جواب بدن و باعث بلاک کردن پیلود میشن .


اینجاست که آپلود فایل PDF مخرب می‌تونه راه خوبی برای رسیدن به Stored XSS باشه، چون PDF می‌تونه javanoscript parsing داشته باشه و خیلی از سایت‌ها این موضوع رو جدی نمیگیرن.

چطور به این آسیب‌پذیری می‌رسیم؟

اول باید Payload یا کد کد مخرب جاوا اسکریپت رو داخل یک فایل PDF تزریق کنیم. بعد اون فایل رو توی بخش‌هایی که سایت اجازه آپلود فایل میده، آپلود می‌کنیم؛
مثل:
حساب کاربری، تیکت‌های پشتیبانی، ارسال مدارک، نظرات و موارد مشابه
وقتی فایل مخرب پشت صحنه آپلود می‌شه، اگه سایت فایل PDF رو مستقیم داخل مرورگر نمایش بده و محدودیتی روی محتوای فعالش نداشته باشه، مرورگر میاد کدهای JavaScript داخل PDF رو اجرا می‌کنه. Payload ما (مثلاً alert) اجرا می‌شه و یعنی به Stored XSS رسیدیم.

نکته مهم: این رفتار معمولاً روی مرورگر Chrome بهتر دیده می‌شه.

چه زمانی باگ حساب نمی‌شه؟

بعضی وقت‌ها بعد از آپلود فایل مخرب، مرورگر به‌جای اجرا کردن PDF، فایل رو دانلود می‌کنه یا اصلاً اجازه اجرای کد رو نمی‌ده. این یعنی سایت تنظیمات امنیتی بهتری داره و عملاً به Self XSS یا عدم بهره‌برداری می‌خوریم و باگ قابل سوءاستفاده‌ای وجود نداره.

چطوری این باگ رو کشف کردم؟

داشتم یکی از فروشگاه‌های اینترنتی ایرانی رو بررسی می‌کردم که دیدم توی بخش تیکت پشتیبانی امکان آپلود فایل PDF وجود داره. فایل PDF مخرب خودم رو اونجا آپلود کردم و به محض اینکه روی فایل کلیک کردم، Payload اجرا شد و به باگ رسیدم.

این آسیب‌پذیری روی یکی از Subdomainها بود. طبیعتاً اگه همین مشکل روی دامنه اصلی وجود داشت، شدت باگ خیلی بالاتر حساب می‌شد و پاداش بیشتری هم می‌شد گرفت.

@dagen_security