Dagen | Security

خب مثل اینکه انرژی برای یه برسی یه سناریو دیگه پایینه پایینه میتونیم کاتش کنیم ولی از اونجایی که رد شدن ازش می‌تونه باعث درک نشدن سناریو های تخصصی تر بشه توی یه پست سریع جمع و جورش می‌کنیم توی پست های آینده و فوق العاده مهم میرسیم سراغ اینکه چجوری پیشرفت هوش مصنوعی رو برای خودمون به چشم یه فرصت و چالش های جدید تر برای حوزه کاریمون ببنیم

اگه می‌خوای بدونی پشت پرده‌ی حملات سایبری منتسب به ایران چی می‌گذره، این کتاب دقیقاً همون چیزیه که دنبالشی. این اثر یک تحلیل دست‌اول و موشکافانه از نحوه استفاده ایران از ابزارهای سایبری برای جاسوسی، خرابکاری و انتقام‌گیریه. نویسنده‌ها اینجا فقط به بحث‌های فنی خشک و خالی نپرداختن؛ بلکه قشنگ باز می‌کنن که چطور سناریوهای پیچیده‌ی نفوذ به زیرساخت‌ها از صفر تا صد طراحی و اجرا می‌شن. Channel : @Sec_Book_Mind

ترجمه فارسی کتاب Iran Cyber Threats رو خوندم و عجیب و غریب به دل نشست ، کتاب کار درست و سنگینیه. با بچها صحبت کردم قرار شد این کتاب رو کاملا رایگان بزارن توی @sec_book_Mind تا همه ازش بهره مند بشن. شرایط سختیه من واقعا درک میکنم بعضیا از ته دل دوست دارن ترجمه این کتاب رو بخونن و به هر دلیلی نمیتونن. ترجمه کتاب همین امروز توی چنل SecBookMind قرار داده میشه تنها چیزی که ازتون می‌خوایم اینه که حمایتی کنید که کار بچها دیده بشه چون دارن انرژی و زمان زیادی صرف میکنن و طبیعتاً نیاز به بازخورد دارن همین. منتظرش باشید 🔥

سری پادکست های کانال یوتیوب Critical Thinking Bug bounty Padcast بزودی فارسی میشه و بدون هیچ منتی در اختیارتون قرار میگیره ♥️ لینک کانال بزودی همینجا گذاشته میشه.

زرنگ اونیه که روی هر لاگین پیجی این تریک رو تست کنه! من خودم این بای‌پاس رو اختراع نکردم؛ من فقط تجربه هانترهای مختلف رو یاد می‌گیرم. راستش، تجربه تاپ ها برای من میشه اعتمادبه‌نفس و بهم امید ادامه دادن میده. وقتی ناامید باشی، ذهن قفل میکنه و نمی‌تونی باگ بزنی باگ زدن زوری نیست! باید با حال خوب و ذهن باز تارگتت رو باز کنی. بهت قول میدم اگه حالت خوب باشه و هوشیار باشی، کار تمومه. نباید به خودت سخت بگیری؛ توی این مسیر باید خاک خورد. ارزشِ واقعی همیشه به سختی لینک میشه. ماموریت تو اینه که از دل سناریوهای مختلف، باگ بکشی بیرون. باگ نخورد؟ فدای سرت برو تارگت بعدی. ولی اگه ناامید بشی، بازی رو باختی. قبول کن که یه روز بالایی و یه روز پایین، ولی باید برای نتیجه تلاش کنی. در نهایت، رضایت واقعی از دیدن نتیجه میاد، مگه نه؟ یه نکته مهم : توی این پست اشاره به یه لاگین تایپ اشاره کردیم ولی چون مرتبط نبود با تایتل اصلی پستمون، راحت ازش رد شدیم اونجا هم یه باگ تپل خورد تا پست بعدی یکم بهش فکر کنید و سناریو های مختلف که باگ میشه رو توی ذهنتون برای لاگین تایپ تداعی کنین اول باید برسی کنم چقدر مشتاق داریم انرژی هست تا تا یه سناریو دیگه رو با هم برسی کنیم ؟ @Dagen_security

در واقع من می‌تونستم هر ایمیلی که دلم می‌خواد رو با استفاده از این بایپس Account Takeover کنم! داستان فنی پشت صحنه چیه؟ دلیل این باگ این بود که سرور روی تعداد ورودی‌های داخل آرایه لیمیتی اعمال نکرده بود (Rate Limiting روی درخواست بود نه اعضای آرایه)، و اینکه سمت دیتابیس یا کد سرور، به جای مقایسه کردن دقیق و تک‌به‌تک کدها، فقط چک می‌کرد که آیا «حداقل یکی» از این کدها درسته یا نه ! همین تست به ظاهر ساده باعث شد کلی آدم این باگ رو میس Miss بدن و من گزارشش بدم. امیدوارم که ساده از این سناریوی ریل‌ورد رد نشید و حتماً حتماً توی تست‌کیس‌هاتون بذاریدش. ممنون که وقت و انرژی گذاشتید 🌷

چجوری با یک تریک ساده OTP ایمیل رو دور زدم و می‌تونستم بدون تایید ایمیل وارد هر حسابی بشم؟ توی پست قبلی به این اشاره داشتیم که عرف یه ثبت‌نام به چه شکله و اگه یه فلو مخالف داشتیم چه تست‌هایی رو می‌تونیم روی اون فلو بزنیم. پس ما نسبت به سیستم احراز هویتی که جلومونه تغییر جهت می‌دیم و تست‌های مربوط به اون سیستم رو اجرا می‌کنیم. سناریوی من یه سناریو روی یه تارگت واقعی Real-World هستش؛ پس آماده بشید بریم سراغ یه سناریوی کمی پیچیده‌تر. سناریوی من یه ثبت‌نام عادی بود با چند تا مرحله اضافه‌تر: صفحه ریجستر تارگت از من یه ایمیل + شماره موبایل و پسورد می‌خواست. زمانی که من روی confirm کلیک می‌کردم، منو می‌برد به یه صفحه‌ای که ازم سوال می‌پرسید: «کدت رو به شماره موبایلت اس‌ام‌اس کنم یا به ایمیل بفرستمش؟» روی ایمیل کلیک کردم. همون‌طور که داشتم با فرآیند آشنا می‌شدم، برپ‌سوییت Burp Suite هم دونه به دونه درخواست‌ها رو می‌گرفت. در واقع زمانی که من روی continue کلیک کردم، یه درخواست زده شد مشابه این: یه درخواست POST زده می‌شد به این ای پی آی 👈 (/api/authentication/sign-in) کانتنت بادی من جیسون JSON بود که این دیتا رو می‌فرستاد:

{
  "LoginType": "email",
  "password": "mypass",
  "user": "dagen@gmail.com",
  "session": "randommmmmmmmmmmmmmmmmm",
  "locale": "en_us"
}

تا اینجا درست. سرور بهم میگه تو لاگین تایپت ایمیله، درستم میگه چون خودم انتخابش کردم. ولی یه چیزیو نمیگه؛ اینکه آیا ما فقط دو حالت داریم؟ یعنی فقط SMS و ایمیل؟ زیاد واردش نمیشیم چون هدف ما فعلاً تست کردن این قسمت نیست و ازش رد می‌شیم. توی پارامتر بعدی ما یه پسورد داریم که خودمون فرستادیمش. پارامتر بعدی یه سشن (session) داشتیم که توی هر درخواست ارسال می‌شد و بعد از وریفای شدنم تبدیل به access-token می‌شد. بسیار خب، پارامترهای مهم رو بهش پرداختیم. نوبت به این می‌رسه که درخواست رو فوروارد کنم. وقتی فوروارد رو زدم، یه صفحه برام باز شد که من باید OTP که به ایمیلم ارسال شده بود رو وارد می‌کردم. اینتر رو زدم و اومدم توی برپ؛ یه درخواست POST دیگه زده شد که مربوط به کانفِرم کد تایید بود: (/api/authentication/confirm-otp) توی دیتای جیسون هم دو تا پارامتر بیشتر نداشتیم:

{
  "otp": "11111",
  "session": "randommmmmmmmmmmmmmmmmm"
}

پارامتر otp همون کد ولیدیه که به ایمیل من ارسال شد و پارامتر سشن هم همون سشنیه که توی هر درخواست ارسال میشه. همین درخواست رو بردم توی تب Repeater و روی دکمه Send کلیک کردم. انتظار میره همه‌چیز درست باشه؛ ریسپانس سرور من یه 200 بود با یه بدنه جیسون که از کلاس usersigninsession توی پارامتر access-token توکن احراز شده منو بهم می‌داد:

{
  "usersigninsession": {
    "access-token": "myToken"
  }
}

(اینم اضافه کنم که اگه اشتباه وارد می‌کردم به من ۵۰۰ می‌داد با یه جیسون که ارور مسیج داشت). ثبت‌نام با این فلو به پایان رسید و قدم آخر اینکه سایت یه چیزیو از من ذخیره کنه تیک خورد ✅ بریم سراغ مغز آسیب‌پذیری من تمام مراحل رو طی کردم. اینجا یه OTP ولید داشتم، درسته؟ زمانی که درست بود سرور به من یه اکسس توکن می‌داد و زمانی که اشتباه بود من ارور مسیج داشتم. توی ذهن من مدام یادآوری میشه که من باید کاری کنم که این منطق دور زده بشه و در نهایت سشن من آپگرید بشه و تبدیل به access-token بشه. چه تستی کردم؟ "Array in SMS code" توی کانتنت جیسون تست‌های ما محدوده چون سمت سرور ما جیسون‌پارس داریم و این پارامترها می‌شینن توی آبجکت. برعکس خیلی‌ها که میان این‌جوری تست می‌کنن و کد دلبخواهی رو توی ارایه میزارن:

{
  "otp": ["false-code"],
  "session": "randommmmmmmmmmmmmmmmmm"
}

و بعدش یه ارور مسیج خوشگل می‌گیرن و بی‌خیال ادامه می‌شن، من اومدم این‌جوری تست کردم: کد ولیدی که به ایمیلم ارسال شده بود رو گذاشتم توی آرایه!

{
  "otp": ["true-code"],
  "session": "randommmmmmmmmmmmmmmmmm"
}

دکمه Send رو زدم و بوممم! access-token برام برگشت! داستان جذاب شد؛ این به این معناست که من الان می‌تونم دونه به دونه کدهای مختلف رو تست کنم؟

{
  "otp": ["true-code", "111", "222", "333"],
  "session": "randommmmmmmmmmmmmmmmmm"
}

ولی من نمی‌خوام دستی این کار رو انجام بدم چون عاقلانه نیست. در آخر اومدم یه پکت ارسال کردم که توش ۱۵,۰۰۰ کد با کاما توی این آرایه از هم جدا شده بود و وقتی سند رو می‌زدم یکی از کد با کد ولیدی که برای ایمیل اومده بود مچ میشد و باگ در میومد

چجوری با یک تریک ساده OTP ایمیل رو دور زدم و می‌تونستم بدون تایید ایمیل وارد هر حسابی بشم؟ توی پست قبلی به این اشاره داشتیم که عرف یه ثبت‌نام به چه شکله و اگه یه فلو مخالف داشتیم چه تست‌هایی رو می‌تونیم روی اون فلو بزنیم. پس ما نسبت به سیستم احراز هویتی که جلومونه تغییر جهت می‌دیم و تست‌های مربوط به اون سیستم رو اجرا می‌کنیم. سناریوی من یه سناریو روی یه تارگت واقعی Real-World هستش؛ پس آماده بشید بریم سراغ یه سناریوی کمی پیچیده‌تر. سناریوی من یه ثبت‌نام عادی بود با چند تا مرحله اضافه‌تر: صفحه ریجستر تارگت از من یه ایمیل + شماره موبایل و پسورد می‌خواست. زمانی که من روی confirm کلیک می‌کردم، منو می‌برد به یه صفحه‌ای که ازم سوال می‌پرسید: «کدت رو به شماره موبایلت اس‌ام‌اس کنم یا به ایمیل بفرستمش؟» روی ایمیل کلیک کردم. همون‌طور که داشتم با فرآیند آشنا می‌شدم، برپ‌سوییت Burp Suite هم دونه به دونه درخواست‌ها رو می‌گرفت. در واقع زمانی که من روی continue کلیک کردم، یه درخواست زده شد مشابه این: یه درخواست POST زده می‌شد به این ای پی آی 👈 (/api/authentication/sign-in) کانتنت بادی من جیسون JSON بود که این دیتا رو می‌فرستاد:

{ "LoginType": "email", "password": "mypass", "user": "dagen@gmail.com", "session": "randommmmmmmmmmmmmmmmmm", "locale": "en_us" }

تا اینجا درست. سرور بهم میگه تو لاگین تایپت ایمیله، درستم میگه چون خودم انتخابش کردم. ولی یه چیزیو نمیگه؛ اینکه آیا ما فقط دو حالت داریم؟ یعنی فقط SMS و ایمیل؟ زیاد واردش نمیشیم چون هدف ما فعلاً تست کردن این قسمت نیست و ازش رد می‌شیم. توی پارامتر بعدی ما یه پسورد داریم که خودمون فرستادیمش. پارامتر بعدی یه سشن (session) داشتیم که توی هر درخواست ارسال می‌شد و بعد از وریفای شدنم تبدیل به access-token می‌شد. بسیار خب، پارامترهای مهم رو بهش پرداختیم. نوبت به این می‌رسه که درخواست رو فوروارد کنم. وقتی فوروارد رو زدم، یه صفحه برام باز شد که من باید OTP که به ایمیلم ارسال شده بود رو وارد می‌کردم. اینتر رو زدم و اومدم توی برپ؛ یه درخواست POST دیگه زده شد که مربوط به کانفِرم کد تایید بود: (/api/authentication/confirm-otp) توی دیتای جیسون هم دو تا پارامتر بیشتر نداشتیم:

{
  "otp": "11111",
  "session": "randommmmmmmmmmmmmmmmmm"
}

پارامتر otp همون کد ولیدیه که به ایمیل من ارسال شد و پارامتر سشن هم همون سشنیه که توی هر درخواست ارسال میشه. همین درخواست رو بردم توی تب Repeater و روی دکمه Send کلیک کردم. انتظار میره همه‌چیز درست باشه؛ ریسپانس سرور من یه 200 بود با یه بدنه جیسون که از کلاس usersigninsession توی پارامتر access-token توکن احراز شده منو بهم می‌داد:

{
  "usersigninsession": {
    "access-token": "myToken"
  }
}

(اینم اضافه کنم که اگه اشتباه وارد می‌کردم به من ۵۰۰ می‌داد با یه جیسون که ارور مسیج داشت). ثبت‌نام با این فلو به پایان رسید و قدم آخر اینکه سایت یه چیزیو از من ذخیره کنه تیک خورد امیدوارم درک کرده باشید بریم سراغ مغز آسیب‌پذیری من تمام مراحل رو طی کردم. اینجا یه OTP ولید داشتم، درسته؟ زمانی که درست بود سرور به من یه اکسس توکن می‌داد و زمانی که اشتباه بود من ارور مسیج داشتم. توی ذهن من مدام یادآوری می‌شد که من باید کاری کنم که این منطق دور زده بشه و در نهایت سشن من آپگرید بشه و تبدیل به access-token بشه. چه تستی کردم؟ "Array in SMS code" توی کانتنت جیسون تست‌های ما محدوده چون سمت سرور ما جیسون‌پارس داریم و این پارامترها می‌شینن توی آبجکت. برعکس خیلی‌ها که میان این‌جوری تست می‌کنن:

{
  "otp": ["false-code"],
  "session": "randommmmmmmmmmmmmmmmmm"
}

و بعدش یه ارور مسیج خوشگل می‌گیرن و بی‌خیال ادامه می‌شن، من اومدم این‌جوری تست کردم: کد ولیدی که به ایمیلم ارسال شده بود رو گذاشتم توی آرایه!

{
  "otp": ["true-code"],
  "session": "randommmmmmmmmmmmmmmmmm"
}

دکمه Send رو زدم و بوممم! access-token برام برگشت! داستان جذاب شد؛ این به این معناست که من الان می‌تونم دونه به دونه کدهای مختلف رو تست کنم:

{
  "otp": ["true-code", "111", "222", "333"],
  "session": "randommmmmmmmmmmmmmmmmm"
}

ولی من نمی‌خوام دستی این کار رو انجام بدم چون عاقلانه نیست. در آخر اومدم یه پکت ارسال کردم که توش ۱۵,۰۰۰ کد با کاما توی این آرایه از هم جدا شده بود و وقتی سند رو می‌زدم باگ در میومد

⭕️ اولین کتابی که برای شروع هک باید توی اولویت قرارش بدی

نسخه فارسی کتاب : ( Linux basic For Hackers Persian )

Channel : @Sec_Book_Mind

چجوری Otp ایمیلم رو با یه تریک ساده دور زدم با علم اینکه این تست رو صد نفر قبل من روی این لاگین پیج انجام دادن من فقط یه چیز رو متفاوت تست کردم ، همین تفاوت یه باگ برام ساخت. تایتل پست بعدی ، ریل ورد ، آپلود به زودیه زود...

هیچوقت خودت رو دست کم نگیر. یکی از مهم‌ترین چیزهایی که توی این حوزه یاد گرفتم اینه که اگه خودت به خودت اعتماد نداشته باشی، خیلی وقت‌ها قبل از اینکه سیستم جلوت رو بگیره، خودت جلوی خودت رو گرفتی. اینکه از همون اول بگی «نمیشه»، «این سیستم خیلی امنه»، «اینجا چیزی پیدا نمیشه» و از این حرف‌ها، فقط باعث میشه کمتر فکر کنی و کمتر تلاش کنی. به جاش روی دانش و مهارتت کار کن. هر روز یه چیز جدید یاد بگیر و سعی کن از دیروز خودت بهتر باشی. یه نکته دیگه هم اینه که وقتی میری روی یه تارگت، فقط به فکر این نباش که سریع یه چیزی پیدا کنی و گزارش بدی. معلومه که همه پول دوست دارن، ولی اگه تمام تمرکزت روی پول باشه خیلی از چیزهای باارزش رو از دست میدی. سعی کن از پروسه لذت ببری. هر تارگت می‌تونه یه تجربه جدید باشه. ممکنه کلی چیز یاد بگیری که بعدها ارزشش از چندتا باگ بیشتر بشه. وقتی میری روی یه تارگت، با ذهنیت ناامید وارد نشو که چندتا تست‌کیس و چک‌لیست رو بزنی و بری. کنجکاو باش، عمیق شو، سوال بپرس و سعی کن سیستم رو واقعاً درک کنی. خیلی از باگ‌های خوب رو آدم‌هایی پیدا می‌کنن که بیشتر از بقیه وقت میذارن و بیشتر از بقیه فکر می‌کنن. رمز موفقیت چیز پیچیده‌ای نیست: تلاش + اعتماد به خود + تکرار + یاد گرفتن از اشتباهات

✍ من فقط توی ایمیل قربانی یه اینتر اد کردم، چجوری باعث اکانت تیک‌اور شد؟ تایتل این پست یه تایتل عجیب و کاملاً منطقیه. قبل از اینکه بریم سراغ توضیح این باگ، بیاین یه روال عادی ثبت‌نام یه سایت رو بررسی کنیم. یه روال عادی ثبت‌نام توی یه وب‌سایت همچین چیزیو برای ما بازگو میکنه: من به عنوان یه کاربر دوست دارم توی وب‌سایت مورد نظرم ثبت‌نام کنم؛ یه یوزرنیم وارد میکنم، یه ایمیلم میدم به همراه یه پسورد و دکمه تاییدو میزنم. سایت یه پیام بهم میده میگه برو کد چند رقمی رو وارد کن و اگه کد درست بود، کوکی یا توکن برات ست میکنه. این میشه یه روال عادی و عرف همه ثبت‌نام‌ها پس من اینو برای خودم ثابت میگیرم و به عنوان یه روال عادی ثبت‌نام میرم هانت میکنم و هر بخش ثبت‌نامی که از این فلو پیروی نکنه، روش کمی عمیق میشم. ببینید توی این سناریو من وارد یه وب‌سایت شدم، بخش signup ازم میخواد یه سری فیلدو پر کنم؛ یه یوزرنیم، ایمیل و پسورد. دکمه تایید رو میزنم و مستقیم میرم توی اکانتم! چی شد؟ یه مرحله از یه روال عادی حذف شد و ما اینجا یه ریجستر فوری داریم اصطلاحاً (immediate login registration)، کاری که پینترست میکنه. در واقع سایت لاگینت می‌کنه و میگه بعداً برو ایمیلتو تایید کن خب این یعنی اگه من ایمیل یه قربانی رو وارد کنم (victim@gmail.com) که توی این سایت قبلاً ثبت‌نام کرده و یه پسورد دلبخواه هم واسش بزنم، چون تایید ایمیل نداره میرم توی حسابش؟ مسلماً نه، به این راحتیا نیست؛ سایت یه پیام زیبا بهت میده، میگه این ایمیل از قبل ثبت‌نام کرده و اجازه ورود نمیده بهت. اینجا یه تست‌کیس قشنگ داریم که باید روی هر ریجستریشنی بی قید و شرط تستش کنید. کاری که کردم ساده بود؛ فرم ثبت‌نام رو پر کردم، روی دکمه تایید کلیک کردم و پکت رو با برپ‌سویت گرفتم. توی پارامتر ایمیل:

email = victim@gmail.com

اول یا آخر ایمیل یه اینتر زدم:

email = victim@gmail.com%0a

درخواست رو فوروارد کردم، رفتم پنل کاربری و تمام ❗️ من وارد اکانت قربانی شدم؛ زیرو کلیک اکانت تیک‌اور بعضیاتون ممکنه کمی گیج شده باشید، شاید سوال براتون پیش بیاد آیا این ایمیل ولیده اصلاً؟ چی شد؟ برگردیم به یه مبحث که حتی امروز بهترین باگ‌ها از دل این مفهوم میزنن بیرون: عدم هماهنگی بین دو عنصر. یه چک داریم —> ایمیل من سمت دیتابیس چک میشه (victim@gmail.com%0a)؛ برای دیتابیس، این یه ایمیل جدیده. اما زمانی که میخواد پشت صحنه ریجسترش کنه، اینو نرمالیزه (Normalize) میکنه به این: victim@gmail.com متوجه شدید؟ این شد سناریوی آسیب‌پذیری که دو تا ایمیل متفاوت رفت توی یه اکانت. در چه صورتی آسیب‌پذیری نداریم؟ زمانی که من اینو وارد کنم (victim@gmail.com%0a) و برای من یه اکانت جدا بسازه و هیچ نرمالیزیشنی اتفاق نیفته! حتی بعضی از سیستم‌ها چه اینتر رو وارد کنی یا وارد نکنی، بهت میگن از قبل این اکانت وجود داره. ریشه این آسیب‌پذیری اتفاقی بود که اون پشت می‌افتاد؛ این ایمیل از چند لایه رد میشد و نرمال میشد. بهترین راه جلوگیریش اینه که همون لایه اول چک بشه و با ایمیلی که از قبل وجود داشته مقایسه بشه. این باگو عیناً یک سال پیش زدم و هنوز که هنوزه روی هر ریجستر کدهای مختلف رو میزنم: آخر ایمیل، اول ایمیل، وسط ایمیل. و اصلاً ضرر نداره که کاراکترهای هکس 00 تا 20 (Hex 0x00 to 0x20) رو هم روش تست کنید و فقط %0a نزنید این تست رو شاید ده هزار بار روی چک‌لیست‌های آماده دیده باشید، چیزی که ارزش داره اینه که مفهوم پشتشو بدونید و فکر کنید چه تستی برای چه لاگینی مناسبه. خیلی مهمه یه سری از کارها رو دستی انجام بدید، نه اینکه فقط با ابزار اسپری کنید. اتنتیکیشن مبحثیه که خیلی باید روش فکر کنید، فلوها رو بشناسید و سعی بکنید ازش باگ بکشید بیرون. این یکی از بیسیک‌ترین و ساده‌ترین نوع تست‌کیس‌ها بود؛ برای بچه‌هایی که هنوز نمیرن سمت اتنتیکیشن چون درکی از تست کردنش ندارن، این پست مفیدترینه. توی این پست بذر این مفهوم رو کاشتیم، همینجوری میریم جلو و میرسیم به تست‌های قشنگ oauth، کلاسیک تکون دادن توکن‌ها، 2fa و... همینجوری بهش شاخ و برگ میدیم. امیدوارم براتون مفید بوده باشه. اگه کانال زنده باشه و انرژی داشته باشید، همینجوری براتون مینویسم و با انجام دادنش خودمم یاد میگیرم. 🌷 @Dagen_security

✍ من فقط توی ایمیل قربانی یه اینتر اد کردم، چجوری باعث اکانت تیک‌اور شد؟ تایتل این پست یه تایتل عجیب و کاملاً منطقیه. قبل از اینکه بریم سراغ توضیح این باگ، بیاین یه روال عادی ثبت‌نام یه سایت رو بررسی کنیم. یه روال عادی ثبت‌نام توی یه وب‌سایت همچین چیزیو برای ما بازگو میکنه: من به عنوان یه کاربر دوست دارم توی وب‌سایت مورد نظرم ثبت‌نام کنم؛ یه یوزرنیم وارد میکنم، یه ایمیلم میدم به همراه یه پسورد و دکمه تاییدو میزنم. سایت یه پیام بهم میده میگه برو کد چند رقمی رو وارد کن و اگه کد درست بود، کوکی یا توکن برات ست میکنه. این میشه یه روال عادی و عرف همه ثبت‌نام‌ها. پس من اینو برای خودم ثابت میگیرم و به عنوان یه روال عادی ثبت‌نام میرم هانت میکنم و هر بخش ثبت‌نامی که از این فلو پیروی نکنه، روش کمی عمیق میشم. ببینید توی این سناریو من وارد یه وب‌سایت شدم، بخش signup ازم میخواد یه سری فیلدو پر کنم؛ یه یوزرنیم، ایمیل و پسورد. دکمه تایید رو میزنم و مستقیم میرم توی اکانتم! چی شد؟ یه مرحله از یه روال عادی حذف شد و ما اینجا یه ریجستر فوری داریم اصطلاحاً (immediate login registration)، کاری که پینترست میکنه. در واقع سایت لاگینت می‌کنه و میگه بعداً برو ایمیلتو تایید کن خب این یعنی اگه من ایمیل یه قربانی رو وارد کنم (victim@gmail.com) که توی این سایت قبلاً ثبت‌نام کرده و یه پسورد دلبخواه هم واسش بزنم، چون تایید ایمیل نداره میرم توی حسابش؟ مسلماً نه، به این راحتیا نیست؛ سایت یه پیام زیبا بهت میده، میگه این ایمیل از قبل ثبت‌نام کرده و اجازه ورود نمیده بهت. اینجا یه تست‌کیس قشنگ داریم که باید روی هر ریجستریشنی بی قید و شرط تستش کنید. کاری که کردم ساده بود؛ فرم ثبت‌نام رو پر کردم، روی دکمه تایید کلیک کردم و پکت رو با برپ‌سویت گرفتم. توی پارامتر ایمیل:

email = victim@gmail.com

اول یا آخر ایمیل یه اینتر زدم:

email = victim@gmail.com%0a

درخواست رو فوروارد کردم، رفتم پنل کاربری و تمام ❗️ من وارد اکانت قربانی شدم؛ زیرو کلیک اکانت تیک‌اور بعضیاتون ممکنه کمی گیج شده باشید، شاید سوال براتون پیش بیاد آیا این ایمیل ولیده اصلاً؟ چی شد؟ برگردیم به یه مبحث که حتی امروز بهترین باگ‌ها از دل این مفهوم میزنن بیرون: عدم هماهنگی بین دو عنصر. یه چک داریم —> ایمیل من سمت دیتابیس چک میشه (victim@gmail.com%0a)؛ برای دیتابیس، این یه ایمیل جدیده. اما زمانی که میخواد پشت صحنه ریجسترش کنه، اینو نرمالیزه (Normalize) میکنه به این: victim@gmail.com متوجه شدید؟ این شد سناریوی آسیب‌پذیری که دو تا ایمیل متفاوت رفت توی یه اکانت. در چه صورتی آسیب‌پذیری نداریم؟ زمانی که من اینو وارد کنم (victim@gmail.com%0a) و برای من یه اکانت جدا بسازه و هیچ نرمالیزیشنی اتفاق نیفته! حتی بعضی از سیستم‌ها چه اینتر رو وارد کنی یا وارد نکنی، بهت میگن از قبل این اکانت وجود داره. ریشه این آسیب‌پذیری اتفاقی بود که اون پشت می‌افتاد؛ این ایمیل از چند لایه رد میشد و نرمال میشد. بهترین راه جلوگیریش اینه که همون لایه اول چک بشه و با ایمیلی که از قبل وجود داشته مقایسه بشه. این باگو عیناً یک سال پیش زدم و هنوز که هنوزه روی هر ریجستر کدهای مختلف رو میزنم: آخر ایمیل، اول ایمیل، وسط ایمیل. و اصلاً ضرر نداره که کاراکترهای هکس 00 تا 20 (Hex 0x00 to 0x20) رو هم روش تست کنید و فقط %0a نزنید این تست رو شاید ده هزار بار روی چک‌لیست‌های آماده دیده باشید، چیزی که ارزش داره اینه که مفهوم پشتشو بدونید و فکر کنید چه تستی برای چه لاگینی مناسبه. خیلی مهمه یه سری از کارها رو دستی انجام بدید، نه اینکه فقط با ابزار اسپری کنید. اتنتیکیشن مبحثیه که خیلی باید روش فکر کنید، فلوها رو بشناسید و سعی بکنید ازش باگ بکشید بیرون. این یکی از بیسیک‌ترین و ساده‌ترین نوع تست‌کیس‌ها بود؛ برای بچه‌هایی که هنوز نمیرن سمت اتنتیکیشن چون درکی از تست کردنش ندارن، این پست مفیدترینه. توی این پست بذر این مفهوم رو کاشتیم، همینجوری میریم جلو و میرسیم به تست‌های قشنگ oauth، کلاسیک تکون دادن توکن‌ها، 2fa و... همینجوری بهش شاخ و برگ میدیم. امیدوارم براتون مفید بوده باشه. اگه کانال زنده باشه و انرژی داشته باشید، همینجوری براتون مینویسم و با انجام دادنش خودمم یاد میگیرم. 🌷 @Dagen_security

از سی نفر با عضویت پنج نفر شدیم 35 نفر عذرخواه از اون چهار نفر اولیت با پنج نفر اول بود ❤️

تمام ❤️😂

https://t.me/+Kb4ShztlBek1NmZk Just click

⭕️ 5 نفر اولی که روی لینک زیر کلیک کنن عضو VIP میشن! واسه اینکه یه حالِ اساسی به بچه‌های پایِ کار بدم همین الان یک ماه اشتراک کاملاً رایگانِ دیتابیس VIP (کتاب‌های ۲۰۲۶ آمازون) به 5 نفری که روی لینک دعوت کلیک میکنن میدم کلیک کردن که کاری نداره، شرطش فقط اینه که آنلاین باشی راس 5 دقیقه دیگه لینک رو ارسال میکنم

#موقت