{ بسم الله الرحمن الرحيم }
Привіт, хакери! У цій статті ви ще раз задумаєтесь, як отримати IDOR, чому? Тому що ви повинні перевірити ефективність функції, і якщо знайдете дефект, відкладіть його та будьте терплячими.
У цій цілі я створив обліковий запис і відвідав сторінку профілю. Зазначив, що для ідентифікації користувачів сайту використовується UUID.
UUID: Це глобальний унікальний ідентифікатор, що використовується для унікальної ідентифікації даних або сутностей, і складається з рядка з 32 символів (16 байт) у формі 8–4–4–4–12.
На перший погляд може здатися, що отримати IDOR неможливо. Я теж так думав, але хакер-програміст всередині мене має іншу думку.
- Перше, що прийшло мені на думку, це знайти журнали в Wayback Archive, які могли бути зафіксовані.
echo "https://ex.com/profile/" | waybackurl | grep -oE '[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12}'
І спробувати пошук без регулярних виразів (не знайдено).
-
Пошук в будь-яких розкриттях API для отримання UUID (не знайдено).
-
Перевірка, чи працює ця функція належним чином? На цьому етапі ми перевершуємо програміста.
—
Я змінив свої дані і надіслав їх до Repeater, створив обліковий запис жертви та отримав UUID облікового запису жертви.
Логічно, як програміст, ви повинні спочатку перевірити через сесію користувача, що вона містить в cookies, чи є це користувачем, відповідним до надісланого UUID! Це не має сенсу, що система покладається лише на UUID.
І змінив дані, використовуючи UUID жертви, через мої cookies!!
—
Цей профіль до зміни
Профіль після зміни:
Зверніть увагу, що зміни відбулись лише після того, як ви отримали UUID, це означає, що ваша сесія (session) також повинна перевіряти, чи дійсно ви — це ви, і тут лежить помилка в програмуванні.
Я думаю, що вразливий код виглядає ось так!? :
prepare("UPDATE users SET username = ?, email = ?, phone_number = ? WHERE uuid = ?");
$stmt->bind_param("ssss", $username, $email, $phone_number, $uuid);
$stmt->execute();
} else {
echo "Error!!";
?>
—
Але проблема в тому, як отримати UUID у цьому випадку?
1. Іноді можна застосувати brute force, але якщо воно коротше за це
2.
Якщо ви знайдете CORS, наприклад, у випадку, коли UUID відображається на сторінці (Це дуже очікувано), це може бути дуже небезпечно. І, на щастя, коли я намагався знайти CORS, я виявив, що сайт інфікований.
Є проблема, що нам потрібно зв’язатися з жертвою для отримання її UUID. Це щось схоже на XSS, CSRF, але я спробував ці вразливості, і не знайшов, щоб сайт був вразливий до них.
—
Я пішов на приватний сервер, пограв на піаніно та написав наступне:
З CORS це як поєднання XSS + CSRF, але дивно, що ці вразливості насправді не існують!!
Чому я не можу скористатися CORS і обійти IDOR, і де тут IDOR?
Це тому, що UUID з'являється на головній сторінці
Але реальна сторінка для зміни даних знаходиться за адресою https://ex.com/profile
І ця сторінка не має вразливості після багатьох спроб, таких як XSS, CSRF, CORS тощо...
Дякую, що прочитали до кінця. Це була моя стаття, сподіваюся, вона вам сподобалась і змінила ваше ставлення до деяких аспектів.
—
قال الرّسول -صلّى الله عليه وسلّم-: (لو كانتِ الدُّنيا تعدلُ عندَ اللهِ جناحَ بعوضةٍ ما سقى كافرًا منها شربةَ ماءٍ)
قال الرّسول -صلّى الله عليه وسلّم-: (لَا يُؤْمِنُ أحَدُكُمْ، حتَّى يُحِبَّ لأخِيهِ ما يُحِبُّ لِنَفْسِهِ)
قال الرّسول -صلّى الله عليه وسلّم-: (ما يُصِيبُ المُؤْمِنَ مِن وصَبٍ، ولا نَصَبٍ، ولا سَقَمٍ، ولا حَزَنٍ حتَّى الهَمِّ يُهَمُّهُ، إلَّا كُفِّرَ به مِن سَيِّئاتِهِ)
Перекладено з: Think Outside The Box Again, With IDOR !