A1:Broken Access Control

Наступний вид вразливості з OWASP TOP 10 розглянемо Broken Access Control, вона вже на першому місці, оскільки цей вид один із найпоширеніших на проектах і за статистикою приблизно 42% мають її.

Назва вразливості говорить сама за себе)))

І так суть цієї вразливості, полягає у відсутності перевірки доступу до запитуваного об'єкта (це може бути адмін сторінка, доступ до обладнання тощо) для різних груп користувачів, чи ваших клієнтів чи співробітників. Більшість веб-аплікух перевіряє права доступу, перш ніж відобразити дані сторінок, які запитують. Також такі перевірки повинні виконуватись перевірки контролю доступу на сервері при запиті будь-якої функції. Адже є безліч допоміжних служб, які часто відправляються у фоновому режимі програми асинхронно, за допомогою AJAX. Якщо параметри запиту недостатньо мають перевірку, то зловмисники зможуть підробити запит для доступу до даних без дозволу.

Давайте розглянемо кілька прикладів, на які варто звертати увагу при тестуванні вашого проекту на цю вразливість:

В першу чергу варто звертати увагу на перебір геть параметра в URL (того ж айді допустимо id користувача, id сторінки замовлення, шлях до файлу і т.д.)

На прикладі:

Допустимо у нас, як у простого користувача, є сторінка, де ми можемо подивитися перелік доступних для нас книг у форматі PDF, як це показано на скрині вище. Але звернемо увагу на урл, і побачимо там якийсь геть параметр, який формулює нам видачу відповідної нашої ролі на цьому ресурсі. Давайте пограємося з ним, замінивши аргумент "documents", на більш цікаве слово "admin", яке говорить саме за себе, найчастіше розробники запихають щось важливе під такі назви і якщо ж він не обмежив у такому шляху доступ, то буде кака. Дивимося, що вийшло...

По друге треба перевіряти також і не тільки контроль існуючих в системі користувачів, але і тих яких у нас немає в нашій базі, це ті самі незареєстровані користувачі. Тобто є у них доступ до сторінок, які мають бути доступні лише тим, хто залогінен. Щоб у зловмисників був можливості перебрати урли чи айди в урлі тих листів, у яких зберігається конфіденційна информация. Приклад...

Ось ми залогінені як користувач "Bee" і припустимо, що є документи, які мали б бути доступні тільки для цього користувача. Тепер розлогуємося

Звернемо увагу знову на урл. Що буде, якщо ми замінимо в урлі сторінку "login.php" на сторінку "documents". Нагадую, ми зараз як незалогінений користувач, тиснемо ентер, дивимося.

Знову немає перевірки на те, що поточні дані не повинні світитись у такому вигляді для незалогінених хлопців. Гаразд, якщо хакер ще буде підбирати ці пейджі. Але а якщо гугл бот пробіжиться і ці сторінки будуть у відкритому доступі в пошуковій машині))) Я не раз зустрічав такі сайти, у яких проіндексувалися адмін сторінки і можна просто переходити з пошуковика на такі сторінки без авторизації і робити справи...

В третьих можно через такую уязвимость даже загружать сторонние функционалы с других сайтов. То-есть вредоносные урлы с скриптами или же просто функции, которые по началу не были доступны, к примеру давайте добавим возможность загружать картинки на сервер на ту страницу, на которой никогда такой возможности не было.

Так, тут на малюнку вище ми бачимо якийсь геть параметр, в даному випадку це мова, яку ми вибрали для відображення на цій сторінці. А якщо в цей геть параметр передати урл на скрипт. В даному випадку використовуємо шкідливий урл "http://www.c99php.com/shell/symlink.txt". На цьому урлу знаходиться скрипт, який генерує функціонал для можливості завантажувати сторонні файли на сервер, на якому його застосувати... Давайте подивимося, що вийшло

Бачимо, що в цей параметр ми передали сторонній урл і що сталося з нашої сторінки))) Тепер ми можемо цей сайт юзати як гугл диск для зберігання якихось файлів))) Дешево і сердито.

Що стосується секретних даних, які варто обмежити від доступності для різних осіб.

Так само до цього типу вразливості можна віднести і зберігання секретних креденшелів (паролей та логінів) у відкритому доступі.

Це може бути конфіги, що лежать у відкритому вигляді на гіті

Сюди можна віднести резервні копії, логи користувачів тощо.

Як зрозуміти що вразливі:

- Обхід перевірок контролю доступу шляхом зміни URL-адреси

- Дозвіл змінювати первинний ключ до чужого обліку користувача, дозволяючи переглядати або редагувати чужий обліковий запис

- Неправильна конфігурація CORS дозволяє несанкціонований доступ до API.

Як захиститься:

- Введіть механізми контролю доступу один раз і повторно використовуйте їх у всьому додатку

- Зміна даних в облікових записах повинні мати лише власники облікових записів

- Закрийте від публічного доступу, наприклад у git, резервні копії налаштувань обліків

І так, ми побачили цікаві файли, замість книжок)) напевно це якісь налаштування щодо конфігів нашого проекту. Можемо клікнувши по них побачити як все влаштовано, а може і знайти в них креденшели для входу в систему як адмін користувач.

Можна так грати й надалі, вживаючи різні невід'ємні слова, типу "login", "email", "password" тощо.

Але можна ще не тільки прямий шлях вказувати на директорію, а й переміщатися цим шляхом, використовуючи звичайний синтаксис "../", що говорить про переміщення по ієрархії дерева нашого проекту.

Дивимося приклад нижче...

З кожним застосуванням "../" ми переміщуємося вище нашою ієрархією. Тобто, якщо ми введемо ще раз "../", то ми побачимо папку, в якій щойно були і які папки знаходяться на тому ж рівні, що і дана папка... Дивимося на скрін нижче, ось вона "bwapp" -git", де ми були раніше.