قبل از اینکه بریم سراغ روال عادی چنل و گذاشتن پست های باگ بانتی ,

توی این چنل قراره عمیق تر شیم و بریم سراغ تحلیل وب اپلیکشن و این موضوع رو جدی تر برسی کنیم و اپلیکشن ها رو مپ کنیم ✍

۱ - علم تست کیس توی باگ بانتی دیگه جوابگو نیست و شما ازش نتیجه نمیگیرد شاید شانس به همراهتون باشه و باگ اسون بزنید .
ولی باگ هایی که خیلی ساده کشف میشن همه تستش میکنن و نوبت به شما نمیرسه .

۲ - دانشی که از شمارو از یه جونیور و یه فرد سنیور جدا میکنه تحلیل وب اپلیکشنه

همه هانترای خفن امروزی بیشتر روی دانش "application mapping" زمان میزارن و این علم خودشون رو قوی تر میکنن

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

ولی یه فرد هانتر باید روال غیر عادی رو تشخیص بده و به نوعی از این اشتباه و دست بردن برنامه نویس به کد باگ بسازه !

۳ - خب من چه جوری میتونم روال غیر عادی رو بشناسم ؟

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

ایا مثلا اگر از google oauth  برای احراز هویت داره استفاده میکنه ایا طبق داکیومت رسمی داره انجام میده یا برنامه نویس دست برده توی فرایند ؟

برای اینکه جزو تاپ های حوزه بشید باید صبور و دقیق و مهم تر از همه خلاق باشید ـ!

دنبال فلان ابراز نباشید چیزی که شما رو از بقیه هانترا جدا می‌کنه تحلیل بلک باکس و وایت باکس و فرض گرفته !

برای اینکه روال غیر عادی رو تشخیص بدید باید دنبال جایی باشید که برنامه نویس توی فرایند دست برده و از خودش چیز جدیدی اختراع کرده که نبوده اینجا جاییه که دقیقا ما باید روش زمان مفید بزاریم 🤝

در ادامه چنل قراره تمرکز روی بحث های زیر باشه :

نحوه کارکرد وب اپلیکشن + سیستم احراز هویت + تکنولوژی استفاده شده

به چنل‌ یه انرژی جون دار بدید 🔥
وقته پست های تخصصی تره ، بریم ؟

@Dagen_security

داستان یه xss که فقط روی گوگل کروم اجرا میشد ✍️

داستان از این قراره که من یه تارگت رو باز کردم ;
اولین کاری که معمولا میکنم اینه که گوگل دورکینگ رو انجام میدم تا به ادرس هایی برسم که توسط گوگل ایندکس شده و به نوعی در دسترسه ;

هدف من برای این سناریو پیدا کردن یه xss بود و تنها روشی که بتونیم این اسیپ پذیری رو پیدا کنیم و اکسپلیوتش کنیم اینه که بدونیم ورودی ما دقیقا کجا میشینه ؟

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

توی سناریوی من وقتی وبسایت رو با ip آمریکا باز کردم یه منو و دکمه برای کلیک برای من بالای صفحه وجود داشت وقتی روش کلیک کردم :

Target/shops/models

منو رو میبرد یه شاپ لوازم آرایشی بدون هیچ‌ پارامتر اضافه تری !
چون این پیچ و صفحه فقط با اپی آمریکا باز میشد با این طرز تفکر که افراد کمتری روی این صفحه کار کردند جلو رفتم و
توی مرحله بعد یه فاز نسبتا سنگین پارامتر از نوع post,get انجام دادم , که در نتیجه یه کلمه کلیدی پیدا شد که ورودی من توی سورس صفحه رفلکت میشد :

IsOveride=test

مقدار تست توی یک تگ div رفلکت شده بود و تنها کاری که من باید میکردم این بود که تگ رو بریک کنم و اسکریپت خودمو اجرا کنم :

IsOveride=test</div><script>alert(origin)</script>

ولی تارگت یه چکر یا یه وف کاستوم داشت جلوی xss من رو میگرفت با این هشدار :

malicious request blocked

حالا وقت فرض گرفتنه , با خودم گفتم وف ممکنه وقتی تگ اسکریپت رو ببینه در جا منو بلاک کنه و شاید تارگت یه بلک لیست تعین کرده باشه ;

پس من بیام و تگ های مختلف رو امتحان کنم با این چیت : xss cheat sheet

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

target/shops/models?IsOveride=test</div><div onreadystatechange='alert(origin)'>

و بله بلک لیست بود ✅
و اون چکر یا وف دور خورد و پیلود من توی سورس نشست , همه چیز درست بود ولی یه جار کار میلنگید و پیلود اجرا نشد ❌

تصمیم گرفتم به جای فایر فاکس برم روی brave و safari تست کنم و در نهایت پیلود من فقط و فقط روی کروم اجرا شد و من تاییده reflected xss رو گرفتم👌🔥

ولی چرا این اتفاق افتاد ؟

@Dagen_security

ریشه امنیتی این باگ دقیقا چیه چرا پیلود من فقط روی کروم اجرا شد ؟

هرکدوم از مرورگر هایی که ما میشناسیمشون ممکنه از render engin برای لود کردن و پارس کردن کد js و html استفاده میکنند

Firefox —> Gecko
Safari —> webkit
chrome and edge —> Blink

پس مرورگر ها میتونن توی پیاده سازی تفاوت هایی داشته باشن و چون blink یه نسبت یه رندر انجین های دیگه تفاوت توی js engin,html parse داشته این فقط روی کروم جواب میده چون کروم داره از این انجین استفاده میکنه پس xss هم داریم .✅

بریم سراغ بخش پیلود :
همونطور که میدونید ایونت هندلر کارش اجرا کردن جاوااسکریپته ;

توی این پیلود اینونت هندلر اصلا برای div استاندارد نیست و از یه کلاس و ابجکت قدیمی اومده مثل (document,XMLHttpRequest) ولی blink این غیر استاندارد رو پارس میکنه و میگه :

تو اینو نوشتی ولی عیبی نداره من پارسش میکنم !
و این دقیقا میشه مغز اسیپ پذیری 👌

ولی مرورگر هایی مثل firefox و safari اینو پیلود رو نمیشناسن و ایگنورش میکنن .🫡


دقیقا توی متن گزارش نوشته شد :

following this link in the google chrome , xss will be popped up ;

@Dagen_security

سم کری نویسنده و هانتر تاپ هکروان یه تریک جذابی برای دور زدن otp توی کرانفراسش اراعه کرده , اون گفتش که :

فرض بگیریم ما یه فرمی داریم که وقتی ایمیل رو وارد میکنیم مثل هر لاگین معمولی دیگه ای یه otp کد یا همون کد تایید رو برای ما ارسال میکنه , حالا سم کری میگه وقتی میخوای otp کد رو وارد کنی , یه OTP اشتباه وارد کن و میبینی که مثلا 400 میگیری .

حالا برو همین ریکوست رو دوباره توی برپت کپچر کن و به جای مقدار OTP اینو قرار بده :

otp=../sms

و میبینی که دور میخوره :)

دلیل و منطقش چیه ؟

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

https://internal-ip/sms/1234 — > 400 bad request

که کد تاییدی که وارد میکنی با اون اینترنال چک میشه , حالا اگه تویه مهاجم 1234 رو وارد کنی و کد اشتباه باشه از اینترنال یه 400 میاد ولی وقتی تو اینو وارد میکنی ../sms توی اینترنال این اتفاق میوفته :

https://internal-ip/sms/../sms

این یه مسیر میاد عقب و چون دایرکتوری sms توی اینترنال وجود داره پس تو از طرف اینترنال یه استاتوس کد 200 میگیری و otp رو بایپس میکنی :)

ایا همیشه جوابه ؟ نه
ایا همیشه اسم دایرکتوری sms هستش نه ! باید فاز کنی و بدستش بیاری
این سناریو فقط با وقتی جوابه که بکند سرور و پیاده سازی برنامه نویس بر اساس استاتوس کد چک رو انجام میده 🤝

امیدوارم درک کافی از این سناریو داشته باشید 🌷

@Dagen_security

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

@Dagen_security

عزیزانی که پی وی پیام داده بودند همه پیام ها جواب داده شد ✅

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

برای همین یه تصمیم گرفتم xmind owasp top 10 رو که خودم اول راهم با اون شروع کردم و صفر تا صد دانشمو داخلش نوشتم رو برای اعضای چنل پاپ کنم تا ازش استفاده کنید و به نوعی مرحله به مرحله با اون پیش برید و کار خودتون رو راحت تر کنید ;

برای دریافتش فقط به پشتیبان پیام بدید تا شرایط رو برای ارسال بگه خدمتتون 🙏👇

@bookmind369

چجوری 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 تگ غیرمجاز برداشته میشد و پیلود اجرا نمیشد ❌

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

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

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

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

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

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

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

ولی وقتی این پیلود به dom مرورگر میرسه اول no script با هر ولیوی که داخلشه کنار میره و 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 در حال منقرض شدنه ولی دقیقا کجا ها میتونید در حال حاضر پیداش کنید .🫡
ریکشن و انرژی بدید تا بریم برای اماده سازی پست بعدی رفقا 🙌

کتاب : Web hacking arsenal

این کتاب یک مرجع کاربردی برای ابزارها و تکنیک‌های تست نفوذ وب هست و بیشتر از تئوری، روی اجرای عملی حملات تمرکز داره. داخلش مجموعه‌ای از ابزارهای معروف و تخصصی برای شناسایی و اکسپلویت آسیب‌پذیری‌های وب معرفی می‌شن؛ از Recon و Enumeration گرفته تا Exploitation و Post-Exploitation.
کتاب ابزارهایی مثل Burp Suite، sqlmap، Nuclei، ffuf، Gobuster، wfuzz و ده‌ها ابزار دیگه رو پوشش می‌ده و توضیح می‌ده هر کدوم دقیقاً کِی و کجا استفاده می‌شن. همچنین سناریوهای واقعی برای حملاتی مثل SQLi، XSS، File Inclusion، SSRF، Auth Bypass و Logic Bugs ارائه می‌ده.
مناسب پنتسترها و باگ‌بانتی‌کارهایی که می‌خوان سرعت و دقت کارشون تو تست نفوذ وب بالا بره و بدونن برای هر مرحله دقیقاً چه ابزاری بهترین انتخابه.

+ به دلیل درخواست بالای عزیزان این کتاب هم
ترجمه فارسی شد و آماده تحویله

برای دریافت به آیدی پشتیبان پیام بدید 👇

@bookmind369

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

نام کتاب : JavaScript for hackers

کتاب روی استفاده از JavaScript از دید امنیتی تمرکز دارد و نشان می‌دهد چطور می‌شود از جاوااسکریپت برای درک بهتر رفتار وب‌اپلیکیشن‌ها و پیدا کردن باگ‌ها استفاده کرد. مفاهیم مهم JavaScript مثل DOM، Events، Scope، Async Code و Browser Behavior به شکلی توضیح داده شده که برای تست نفوذ وب کاربردی باشند.
کتاب کمک می‌کند بفهمی کدهای سمت کلاینت چطور کار می‌کنند، چه داده‌هایی در مرورگر پردازش می‌شوند و چطور می‌توان از این درک برای شناسایی ضعف‌هایی مثل XSS، Logic Bugs و Client-Side Validation Issues استفاده کرد.
مناسب پنتسترها و باگ‌بانتی‌کارهایی است که می‌خواهند درک عمیق‌تری از جاوااسکریپت داشته باشند و تست‌های وب را هدفمندتر انجام دهند

+ ترجمه نسخه فارسی این کتاب تکمیل شده و آماده تحویله ✅

برای دریافت به پشتیبان پیام بدید ⬇️

@bookmind369