سلام رفقا ، آرمان هستم و قراره امروز بریم و یک خرید ارزون رو با باگ Web Parameter Tampering به خودمون هدیه بدیم.

فرض کنید میخواییم PS5 بخریم , قیمت توی سایت حدودای یک میلیون تومنه اما ما سرجمع با هم صد هزار تومن داریم. پس باید ی حرکتی بزنیم که قیمت PS5 ما ی صفر از دست بده.🙂

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

ما توی حالت عادی از دید یک کاربر معمولی که میخواد خرید رو انجام بده , فقط تعداد رو میتونیم تغیر بدیم. تازه اونم با محدودیتی که برنامه نویس برامون تعریف میکنه.

اما تویی که داری این مقاله رو میخونی , ی کاربر معمولی نیستی و همیشه ی راهی برای دور زدن این فیلتر ها پیدا میکنی😎بریم ی بررسی روی داده ها بندازیم.

درخواست های ما که سمت سرور بررسی میشن , حاوی دو مدل دیتا هستش , داده ای که کاربر انتخاب کرده ( رنگ عینک , اینچ مانیتور و … ) و داده ای که اغلب (نه همیشه🤔 ) سمت سرور ذخیره شده مثل قیمت.

یکی از داده هایی که به طور معمول همیشه میتونیم تغیرش بدیم سمت کلاینت , تعداد محصولمونه.

بیایید ی بازی ریاضی کنیم , من ی محصول 100 تومنی دارم و میخوام دوتا ازش بخرم , چقدر باید پرداخت کنم؟ درسته 200 تومن.
حالا اگر برنامه نویس محترم نیومده باشه و فیلتری تنظیم نکرده باشه روی تعداد و من تعداد 0.1 رو سفارش بدم , اون موقع چقدر باید پرداخت کنم؟ دقیقا…10 تومن , به همین راحتی تونسیم قیمت نهایی محصول رو تغیر بدیم 🙂.

الان با خودتون میگین که چطوری 0.1 رو بچپونیم توی تعداد سفارشمون؟🤔
اینجاس که نام زیبای Burp Suite میدرخشه …

از بخش proxy میایید مرورگر برپ رو باز میکنید و اون ادرس سایت محصولیتون رو قرار میدین . زمانی که خواستید افزودن به سبد خرید رو بزنید. پروکسی رو روشن کنید تا درخواست هایی که دونه دونه میره سمت سرور رو بررسی کنید. توی یکی از درخواست ها بخش بادی درخواست یکسری اطلاعات راجب سفارش شما هست که یکی از متغیر ها حاوی دیتای تعداد سفارش شماست, که معمولاااااا نام متغیرش ( count , q , quantity ) یکی از این سه تا هستش . تعداد رو تبدیل به 0.1 یا 0.01 میکنید و درخواست رو ارسال میکنید سمت سرور. زمانی که بریم و سبد خرید خودمون رو نگا کنیم , مشاهده میکنید که قیمت نهایی سفارشتون یکی دوتا صفر کم داره 😎

خوشحال شدید ن؟؟ منم خوشحال شدم 😂 این تئوری که چیدیم ی جا ممکنه کار دستت بده ! کجا؟ میتونی حدس بزنی ؟ زمانی که طمع کنی و مقدار اعشاریت رو زیاد کنی مثلا 0.0000001 خیلی تمایل میکنه سمت صفر و سرور دیگ اونو صفر میبینه و تعداد محصول رو برات صفر میزنه و کل پروسه بهم میریزه , پس لطفا خیلی طمع نکنید 😐 با تشکر مرسی

سبد خرید رو بزارید ی نگاهی بندازیم ببینیم چه خبره من ی کالا یک میلیونی به تعداد 0.1 سفارش دادم و در نهایت باید صد هزار تومن پرداخت کنم.

این اولین تئوری حمله بودش که ما بیاییم روی تعداد بازی کنیم.

یادتونه گفتم ” و داده ای که اغلب (نه همیشه🤔 ) سمت سرور ذخیره شده مثل قیمت. ” این بار میخواییم روی همون استثناء ” نه همیشه ” مانور بدیم.
توی 98 درصد مواقع قیمت ی محصول سمت سرور ذخیره میشه و سمت کلاینت خبری از قیمت محصول نیستش. اما هنوز 2 درصد ممکنه که باشه پس ساده ازش نگذرید. 👨🏻‍🦯

بازم معمولا تو همون درخواستی که داره تعداد محصول سمت سرور فرستاده میشه ممکنه ی متغیر خاص باشه که قیمت محصول رو توی خودش جا داده باشه و گاها اسم متغیر رو Price میزارن. بیایید اونو تغیر بدین , ی صفرش رو بردارین (خودمونیم هیچ فک میکردین ی صفر انقدر تاثیر داشته باشه😂) درخواست رو بفرستید سمت سرور . بریم سبد خریدمون رو چک کنیم ببینیم چه خبره !!!

اینجاش رو دوست دارم خودم , توی سبد خرید ما تعداد محصول فرضا 1 هستش و ی چیز عادیه ولی قیمت یک عدد محصول اینجوری نیست و اون رقمی که ما گذاشتیم پس در نهایت قیمت نهایی خریدمون هم تغیر میکنه و انگار از اول اون رقمی که ما گذاشتیم توی محصول تعریف شده براش 😐 خیلی خفنه خودم میدونم 😂😂

تا اینجای کار یاد گرفتیم که دقیقا پروسه و روند حمله چجوریه و دوتا استراتژی خوب رو یادگرفتیم.
این دوتا حمله به ی مدل دیگ هم انجام میشه که شما رو باید با مفهوم متغیر و درخواست های Http بیشتر آشنا کنم. مثلا تو حمله اول که روی تعداد کار میکردیم . روی همچین داده ای کار میشد :
…&count=1&…

اینجا count ی متغیره که حاوی مقدار 1 هستش ؛ شما count رو مثل ی جعبه ببین که برنامه نویس اونو ساخته و مقدارش رو ما انتخاب میکنیم. حالا اگر ما بیاییم یه جعبه دیگ درست کنم با اسم count و مقدار توشو بزاریم 0.1 ؛ این جعبه که خودمون درست کردیم رو بدیم سمت سرور و بگیم اینو برای تجزیه و تحلیل کم و بیخیال قبلی شو…..

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

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

سرور کدوم رو برای ما بررسی میکنه ؟؟ درسته دومی رو ! پس مقدار جعلی ما پردازش میشه , به همین راحتی میشه این کار رو برای قیمت هم انجام داد . فقط حواستون رو جمع کنید که پارامتر جعلی بعد از پارامتر اصلی بیاد.

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

اما با گزارش این باگ میتونید بانتی خوبی رو دریافت کنید و این باگ ، باگی نیست که توسط اسکنر ها شناسایی شه ؛ باید خودتون آستین هاتون رو بالا بزنید.

خیلی ممنون منو تا اینجا همراهی کردین امیدوارم که این مقاله آموزشی برات مفید واقع شده باشه.

این آسیب پذیری توسط مجموعه ما کشف شده و به سایت مورد نظر گزارش شده