تایتل این پست یه تایتل عجیب و کاملاً منطقیه.
قبل از اینکه بریم سراغ توضیح این باگ، بیاین یه روال عادی ثبت‌نام یه سایت رو بررسی کنیم.
یه روال عادی ثبت‌نام توی یه وب‌سایت همچین چیزیو برای ما بازگو میکنه:
من به عنوان یه کاربر دوست دارم توی وب‌سایت مورد نظرم ثبت‌نام کنم؛ یه یوزرنیم وارد میکنم، یه ایمیلم میدم به همراه یه پسورد و دکمه تاییدو میزنم.
سایت یه پیام بهم میده میگه برو کد چند رقمی رو وارد کن و اگه کد درست بود، کوکی یا توکن برات ست میکنه.
این میشه یه روال عادی و عرف همه ثبت‌نام‌ها
پس من اینو برای خودم ثابت میگیرم و به عنوان یه روال عادی ثبت‌نام میرم هانت میکنم و هر بخش ثبت‌نامی که از این فلو پیروی نکنه، روش کمی عمیق میشم.
ببینید توی این سناریو من وارد یه وب‌سایت شدم، بخش 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