رایتاپ idor شماره 1

سلام.من بهروز منصوری هستم و با رایتاپ idor شماره 1  که مربوط به یک برنامه پرایوت در سایت هکروان است در خدمتتون هستم.

در این نوشته به شما میگم که چطور یک آسیب‌پذیری IDOR را دور زدم و در پایان روش‌های دیگری را نیز برای دور زدن آن به اشتراک می‌گذارم، پس با من همراه باشید.

IDOR همیشه در مورد تغییر پارامتر id نیست زیرا راه‌های مختلفی وجود دارد که می‌توانیم آن آسیب‌پذیری را پیدا کنیم.

اما بیشتر ما فقط سعی می‌کنیم پارامتر ID را تغییر دهیم و پس از دریافت 401 (دسترسی غیرمجاز) و سایر خطاها، منصرف می‌شویم و به سراغ آسیب پذیری دیگری می‌رویم.

اما این یک رویکرد اشتباه است، سعی کنید کمی برای همان باگ وقت بگذارید، کمی در گوگل تحقیق کنید و سعی کنید محدودیت را دور بزنید.

داستان باگ

چند وقت پیش، من یک دعوت VDP خصوصی در HackerOne با دامنه محدود دریافت کردم.

این برنامه نوعی سایت ورزشی بود که در آن می‌توانیم یک تیم برای یک ورزش خاص ایجاد کنیم و امکان اضافه کردن اعضا به تیم  را داشتیم تا در نهایت تیم خود را به عنوان مربی مدیریت کنیم.

من با recon و بررسی ساب دامنه ها شروع کردم اما هیچ ساب دامنه جالبی یا endoint مناسبی پیدا نکردم.

سپس شروع به بررسی دستی دامنه اصلی وب سایت کردم و برخی از آسیب پذیری ها مانند CSRF و XSS را تست کردم اما خوش شانس نبودم.

پس از آن گزینه جالبی به نام “تیم بازنشستگی” را در زیر گزینه تنظیمات تیم دیدم.

تصمیم گرفتم با این قابلیت بازی کنم و burp را روشن کردم. درخواستی که دیدم چیزی شبیه به این بود:

POST /account/teamsetting/retired_team?team_id=12345

ذهن من با صدای بلند فریاد می زد “IDOR IDOR IDOR IDOR”. من بلافاصله یک اکانت قربانی ایجاد کردم و سپس یک تیم قربانیان ایجاد کردم، شناسه تیم قربانی را به جای شناسه تیم مهاجم تغییر دادم اما پاسخ در repeater چیزی که انتظارش را داشتم نبود(خطای دسترسی غیرمجاز را به من نشان داد).

من تسلیم نشدم و ادامه دادم.

شروع فرایند بایپس

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

کاری که من انجام دادم این بود که %20 را در انتهای پارامتر id قرار دادم. به این صورت:

POST /account/teamsetting/retired_team?team_id=victim’s_id%20

خوشحال و هیجان‌زده بودم، چون هیچ محدودیت وجود نداشت، هکر می‌تواند پارامتر team_id را قرار دهد و تیم سایر کاربران را بازنشسته کند.

آسیب پذیری را گزارش کردم و منتظر پاسخ تیم تریاژ بودم. بعد از 6 روز جواب دادند:

گزارش تکراری بود 🙁 😡 

راه های دیگه ای هم برای دور زدن  IDOR وجود دارد:

Parameter Pollution

قرار دادن مقادیر متعدد برای یک پارامتر، می تواند منجر به سناریویی شود که در آن امکان پیاده سازی idor وجود دارد.

درخواست به جای این حالت:

GET /api/card?custom_id=<attacker_id>

به این حالت تغیر می کند:

GET /api/card?custom_id=<attacker_id>&custom_id=<victm’s_id>

 

اضافه کردن کاراکترهای خاص و string های تصادفی

با جایگزین کردن شناسه ها ممکن است با ارور 401، رد شدن دسترسی یا نامعتبر بودن برخورد کنید.

در این موارد، اضافه کردن کاراکترهای خاص (/) یا رشته‌هایی مانند %20، %09، %0b، %0c، %1c، %1d، %1e، %1f و غیره ممکن است به شما کمک کند.

 

GET /profile/update/12345

GET /profile/update/12345%20

تغییر متد درخواست

اگر یکی از روش‌های درخواست HTTP کار نمی‌کند، می‌توانید به جای آن روش‌های زیادی را امتحان کنید: GET، POST، PUT، DELETE، PATCH و غیره.

 

قرار دادن شناسه در درخواست های بدون شناسه

حتی اگر URL درخواست از پارامترهای ورودی استفاده نمی کند، پارامترهایی را برای هر درخواست قرار دهید و ببینید آیا تفاوتی ایجاد می کند یا خیر.

برای مثال، اگر این درخواست تمام جزئیات کارت شما را نشان دهد:

GET /api/card

اگر هکر شناسه کاربری را همانطور که در زیر ذکر شده است اضافه کند، چه اتفاقی خواهد افتاد؟

GET /api/card?custom_id=<victim_id>

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

این رایتاپ idor شماره 1 بود و قطعاً در آینده رایتاپ های بیشتری رو در این زمینه قرار خواهم داد.

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