Вразливості IDOR: що собою представляють і як захистити від них свою платформу, чим дійсно можуть загрожувати небезпечні прямі посилання на об’єкти?
Небезпечні прямі посилання на об’єкти (Insecure Direct Object Reference, IDOR) є поширеними і потенційно руйнівними вразливими факторами, що виникають внаслідок безграмотного налаштування доступів у веб-додатках.
Вразливості IDOR дозволяють кіберзлочинцю зловмисно взаємодіяти з вашою веб-програмою, маніпулюючи «прямим посиланням на об’єкт», такий як, наприклад, ключ бази даних, параметр запиту або ім’я файлу.
У цій статті ми постараємося відповісти на такі ключові питання:
- Що таке IDOR?
- Як знайти цю уразливість у своєму веб-додатку?
- Що можна зробити, щоб захиститись від IDOR?
Як працюють уразливості IDOR
Під IDOR найчастіше мають на увазі заміну одного з параметрів URL-адреси веб-програми для отримання доступу до інформації, яка спочатку прихована від сторонніх очей.
Візьмемо як приклад реальний випадок, що стався за кордоном багато років тому. Один із студентів рядового іноземного ВУЗу відкрив свій університетський профіль, перейшов у розділ з розкладом занять і помітив в адресному рядку такий вміст:
“https://lk.example-university.com/Schedule?ID=000021156” (URL вказаний для прикладу).
Очевидно, що ідентифікатор «000021156», коли він відображається в особистому кабінеті студента, явно належить саме йому. Однак що буде, якщо змінити його на інший? Хоча б просто змінити одну цифру. Цікавість зіграла над студентом, і він зробив задумане, отримавши доступ до розкладу занять, а потім і всіх інших даних з особистого кабінету зовсім іншого студента цього університету.
Подібну процедуру отримання доступу до чужих даних можна було повторювати нескінченно, підставляючи дійсні ідентифікатори інших учнів, якщо вони відомі, або банально вгадувати їх, адже вони призначалися студентам по порядку.
Щоб така вразливість спрацювала в сучасному веб-застосунку, безліч речей повинні піти не так. По-перше, додаток, очевидно, не повинен включати додаткових перевірок авторизації, щоб зрозуміти, чи повинен конкретний користувач мати доступ до запитаної інформації. Тобто доступ до даних має бути реалізований у «небезпечний» спосіб.
По-друге, база даних вразливого веб-додатку має працювати виключно на основі ідентифікатора користувача, тобто має існувати якесь «пряме посилання на об’єкт», за яким можна зчитати всю інформацію.
Нарешті, ідентифікатори повинні бути перераховані в адресному рядку у зручному для розпізнавання форматі, що дозволить легко маніпулювати ними навіть людині, яка не володіє пізнаннями в області хакінгу.
Готові популярні CMS-рішення, як правило, не грішать подібними недоліками безпеки, проте створюючи свій веб-додаток з нуля, було б непогано переконатися в тому, що ви не припустилися тієї ж помилки, що й фахівці згаданого вище університету.
Розповсюджені канали для використання
У наші дні різні ідентифікатори частіше зустрічаються в заголовках або API, ніж у адресному рядку. Однак динамічний характер більшості веб-сайтів означає, що ідентифікатори та параметри, як і раніше, широко використовуються в тій чи іншій формі. Ідентифікатори можуть включати:
- Ключі бази даних;
- Параметри запиту;
- Іідентифікатори користувача чи сеансу;
- Імена файлів.
Як виявити вразливості IDOR
Вразливості IDOR легко експлуатувати, проте самі розробники часто можуть і зовсім не здогадуватися про їхню наявність. Аналіз коду та автоматичне сканування цілком прийнятні для багатьох інших поширених проблем безпеки, проте вони не такі хороші для виявлення недоліків типу IDOR. Це означає, що для виявлення таких уразливостей може знадобитися ручне тестування безпеки.
Деякі способи виявлення вразливостей включають:
- Виконання базових тестів за допомогою вбудованих інструментів розробника у веб-браузері;
- Використання інструментів “Burp Suite” або “Open Web Application Security Project Zed Attack Proxy” (OWASP ZAP) для підвищення ефективності ручного тестування.
- Участь у програмі розкриття вразливостей;
- Наймання зовнішньої компанії, яка здійснює послуги пентесту для перевірки критичних веб-додатків.
Чотири типи атак IDOR
Концептуально більшість атак, що використовують IDOR, працюють аналогічним чином, проте невеликі нюанси все ж таки є.
1. Фальсифікація URL
Фальсифікація URL-адрес – це найпростіший спосіб використовувати вразливість IDOR. Для його використання не потрібно значних технічних знань, тому що все, що необхідно зробити для успішної експлуатації, просто змінити видиме значення параметра в адресному рядку веб-браузера. Кінцевий результат завжди один: сервер надає атакуючому неправомірний доступ до інформації, доступу до якої він має бути.
2. Маніпуляції з тілом
Маніпуляції з тілом веб-застосунку дуже схожі на фальсифікацію URL-адрес, за винятком того, що зловмисник змінює одне або кілька значень у тілі сайту, а не в URL-адресі. Це може означати зміну значень перемикачів, прапорців або інших елементів форми, включаючи приховані значення.
Можливо, форма має приховані значення, які можуть бути знайдені в коді сайту. Наприклад, приховане значення передачі ідентифікатора конкретного користувача системи поточному активному сеансу. Якщо зловмисник зможе змінити таке приховане значення до відправлення форми, він зможе зробити так, щоб його запити виходили з іншого користувача системи.
3. Маніпуляції з cookie-файлами або JSON ID
Cookie-файли, як і JSON, широко використовуються за лаштунками веб-додатків для зберігання та обміну даними між клієнтом та сервером, допомагаючи зробити веб-сторінки динамічнішими. Наприклад, коли ми заходимо на веб-сайт, сервер може зберігати значення ідентифікатора користувача або сеансу всередині cookie-файлу або об’єкта JSON. Якщо веб-додаток містить вразливість IDOR, зловмисник може змінити ці значення.
4. Обхід шляху
Обхід шляху, що також називається обходом каталогу, — це унікальний тип вразливості IDOR, який зловмисник може використовувати для доступу та керування файлами або папками безпосередньо на сервері, на якому виконується веб-програма. Така атака набагато глибша, ніж інші типи атак IDOR, оскільки вона дозволяє отримати прямий доступ до ресурсів файлової системи, а не до записів бази даних.
Обхід шляху може дозволити зловмиснику отримати доступ до файлів конфігурації, дізнатися про облікові дані користувачів або навіть отримати повнофункціональну оболонку цілі.
Як IDOR впливає на дані
Уразливості IDOR найчастіше прості у використанні, але наслідки таких атак можуть бути катастрофічними. Нижче наведено лише кілька способів, якими IDOR може вплинути на конфіденційність, цілісність та доступність даних вашої організації:
- Конфіденційність. Як ми бачили на прикладі з університетом, успішна атака IDOR дає зловмисникові доступ до того, що він не повинен бачити. Це може бути будь-що: від коду знижки для частих покупців онлайн-маркетплейсу до конфіденційної особистої інформації про здоров’я пацієнта або якоїсь комерційної таємниці.
- Цілісність. У деяких випадках зловмисник може використовувати IDOR для зміни даних. Зазвичай, ці типи атак маніпулюють параметрами в HTTP-запиті POST. Так, у 2020 році один із дослідників безпеки вчасно помітив уразливість IDOR, яка дозволила б зловмиснику змінити пароль облікових записів користувачів на веб-серверах Міністерства оборони США. Зловмисники можуть використовувати аналогічні вразливості для додавання до системи несанкціонованих даних, таких як фальсифікована фінансова інформація або різні документи, що компрометують.
- Доступність. IDOR також можна використовувати, щоб зменшити доступність ресурсів. Уявіть собі функцію у програмі PHP, яка видаляє документи на ім’я файлу. З її допомогою без належних перевірок авторизації зловмисник зможе змінити ім’я потрібного йому файлу та видалити будь-які документи, до яких він навіть не має повноцінного доступу.
Чотири поради щодо запобігання вразливості IDOR
Уразливості IDOR можна запобігти, уникаючи прямих посилань на об’єкти, реалізуючи перевірку введення користувача і реалізуючи глобально унікальні ідентифікатори (відомі як GUID) або випадкові ідентифікатори. Хоча не існує по-справжньому універсального рішення, коли йдеться про те, як запобігти вразливості IDOR, деякі з наведених нижче кроків можуть істотно знизити ризик їх виявлення та експлуатації.
Введіть належний контроль доступу та керування сеансами
Open Web Application Security Project (OWASP), учасники якого і вигадали термін «небезпечне пряме посилання на об’єкт», розглядає IDOR насамперед як проблему контролю доступу. Належні перевірки контролю доступу та функції управління сеансом повинні запобігати доступу зловмисника до даних або маніпулювання ними, навіть якщо в системі використовуються ідентифікатори, що легко піддаються перерахуванню. Пам’ятки OWASP з авторизації та аутентифікації можуть бути корисними для ознайомлення перед впровадженням такого захисту.
Уникайте прямих посилань на об’єкти
Крім проблем із контролем доступу, використання прямих посилань на об’єкти у веб-додатку часто вважається неакуратною практикою кодингу. Особливо, коли йдеться про конфіденційні дані, такі як ідентифікатори клієнтів, співробітників, номери рахунків і т.д. Непрямі посилання на об’єкти – часто у вигляді довідкових карток або хешування – усувають уразливості IDOR, приховуючи чи заплутуючи справжній ідентифікатор. Якщо ж використовуються хеші, не забудьте включити сильну та унікальну сіль, оскільки базові алгоритми хешування, такі як MD5, легко скасувати за допомогою спеціалізованого софту.
Використовуйте GUID або випадкові ідентифікатори
У додатках, які використовують послідовні ідентифікатори або параметри, експлуатація IDOR не складає труднощів. Якщо потенційний зловмисник помітить, що ідентифікатор користувача в системі виглядає як “0001”, він може зробити цілком обґрунтоване припущення, що існує користувач “0002”, “0003” і т.п.
Сучасні обчислювальні потужності та методи автоматизації дозволяють досить легко перебрати всі можливі значення від 0000 до 9999, доки хакер не знайде потрібного користувача.
Проте ні GUID, ні універсальні унікальні ідентифікатори до кінця не усувають основну природу вразливості IDOR. Вони лише значно ускладнюють її експлуатацію.
Перевірте ще раз дані, що вводяться користувачами
Перевірка введення користувача може допомогти пом’якшити безліч проблем безпеки, включаючи IDOR. Перелік ідентифікаторів стає набагато складнішим, якщо введені користувачем параметри будуть перевірені на правильну та допустиму довжину/формат. Перевірка може виконуватися або на стороні клієнта, або на стороні сервера, залежно від того, що найбільше підходить у конкретній ситуації.
Висновок
Уразливості IDOR — дуже поширена проблема веб-додатків, здатна завдати серйозної шкоди конфіденційності та безпеці даних. Хоча вони можуть здатися важковловимими, уважне тестування та аудит коду допоможуть виявити їх ще до виявлення та зловмисної експлуатації зловмисниками.
Крім того, при проектуванні програм варто спочатку закладати надійні механізми авторизації та уникати прямих посилань на конфіденційні дані. Ретельний та проактивний підхід до безпеки – найкращий засіб захисту від атак, що експлуатують уразливості IDOR та подібні до них.