
Дізнайтесь, як порушення контролю доступу може вплинути на безпеку вашої системи, і які практики допоможуть мінімізувати ризики. Розглянемо основні методи атак і рекомендації щодо захисту.
Дисклеймер: Цей матеріал призначений виключно для ознайомлювальних цілей. Викладена інформація надається для підвищення обізнаності та покращення безпеки програмного забезпечення.
Порушення контролю доступу – це ситуації, коли користувачі отримують доступ до ресурсів або функцій, для яких у них немає відповідних прав. Це може статися через кілька причин:
Опис: Коли система не перевіряє особу користувача перед наданням доступу до чутливих даних або функцій.
Приклад: Веб-додаток дозволяє користувачам переглядати інформацію про інші облікові записи без необхідності входу в систему. Наприклад, користувач може переглядати особисті дані інших без авторизації.
Опис: Після того, як користувач пройшов автентифікацію, система не перевіряє, чи має він право доступу до конкретних ресурсів або функцій.
Приклад: Звичайний користувач може отримати доступ до адміністративної панелі або змінювати дані, які повинні бути доступні лише адміністраторам. Наприклад, звичайний користувач може видаляти пости інших користувачів.
Опис: Код 403 означає, що доступ до ресурсу заборонено, в той час як код 404 вказує, що ресурс не знайдено. Неправильне використання кодів статусу може розкрити інформацію про структуру додатка.
Приклад: Якщо при спробі доступу до адміністративного розділу веб-додатка система повертає 404, це може вказувати на існування такого розділу, але доступ до нього заблоковано.
Натомість, код 403 чітко сигналізує про заборону доступу.
Опис: Включення чутливих даних у URL або в параметри запиту, які можуть бути видимі або доступні для зловмисників.
Приклад: Передача ID користувача або токенів доступу в URL, який може бути збережений у журналах сервера або історії браузера. Наприклад, URL на зразок https://example.com/profile?user_id=1234 дозволяє змінити user_id і отримати доступ до іншого профілю.
Опис: Атаки, при яких зловмисник спонукає користувача, який вже автентифікований у веб-додатку, виконати небажану дію.
Приклад: Зловмисник може створити фальшиву веб-сторінку, що містить форму для зміни пароля на сайті, де користувач уже автентифікований. Якщо користувач відкриє цю сторінку, то запит на зміну пароля буде автоматично відправлений до справжнього сайту, змінюючи його пароль без його відома.
BLUE TEAM
Аутентифікація — це процес підтвердження особи користувача. Найбільш розповсюдженим прикладом є введення користувачем свого ідентифікатора, такого як електронна пошта, разом з паролем. Коли запит направляється до захищеної зони, брандмауер отримує можливість витягти з об’єкта Request особисті дані користувача. Далі система генерує токен, який включає менеджера аутентифікації. Цей менеджер перевіряє токен і, якщо надана інформація відповідає очікуванням, видає підтверджений токен. Після цього цей токен зберігається в спеціальному сховищі для подальшого використання.
RED TEAM
Brute force
Атака стає можливою, коли аутентифікація відсутня або недостатньо надійна, що дозволяє зловмисникам використовувати метод перебору для підбору паролів, перебираючи всі можливі варіанти, поки не знайдеться правильний. У контексті Symfony атака брутфорс полягає в спробах зламати захищені частини сайту або додатка, підбираючи правильні комбінації логінів і паролів. Такі атаки зазвичай спрямовані на стандартні механізми аутентифікації, які Symfony реалізує через Security Bundle.
Цей скрипт систематично перебирає різні паролі зі списку, поки не буде знайдено правильний. Атака виявляється ефективною у випадках, коли відсутнє обмеження на кількість спроб або не відбувається блокування акаунта після декількох невдалих спроб.
Застосування інструментів для брутфорсу: Інструменти на кшталт Hydra, Burp Suite або OWASP ZAP можуть автоматизувати цей процес, значно підвищуючи ефективність атаки.
BLUE TEAM
Авторизація — це процес перевірки прав доступу або модифікації ресурсів.
RED TEAM
IDOR – Insecure Direct Object References. Відсутність перевірки прав доступу може дозволити зловмисникам отримати доступ до ресурсів, просто змінивши ідентифікатори в URL.
Змінивши ідентифікатор у URL, зловмисник може отримати доступ до даних іншого користувача, якщо не проведена належна перевірка прав доступу.
Forbidden – Код статусу 403 Forbidden вказує, що сервер зрозумів запит, але відмовляється його виконати через відсутність необхідних дозволів.
Not Found – Код статусу 404 Not Found вказує, що запитуваний ресурс не знайдено на сервері. Це може бути результатом невірного URL або відсутності файлу на сервері.
BLUE TEAM
Якщо ви не бажаєте, щоб користувач знав про наявність певного ресурсу, варто використовувати відповідь із кодом 404 (Not Found). Якщо ж вам потрібно чітко показати, що ресурс існує, але доступ до нього обмежений, краще скористатися кодом 403 (Forbidden).
RED TEAM
Resource Enumeration. Зловмисники можуть скористатися різницею між відповідями 403 та 404, щоб визначити, чи існує ресурс, навіть якщо вони не мають доступу до нього.
Цей скрипт перевіряє наявність ресурсів, аналізуючи відповіді сервера. Якщо ресурс існує, але доступ заборонений, повертається код 403, якщо ж його не існує — код 404.
Sensitive Data in Insecure Parameters (Чутливі дані в ненадійних параметрах) — це ситуація, коли конфіденційна інформація, така як паролі, токени чи особисті дані, передається через параметри запитів або інші ненадійні механізми. Це становить загрозу, оскільки недостатній захист таких даних може призвести до їх витоку або компрометації.
BLUE TEAM
RED TEAM
Insecure Parameter Exploitation. Зловмисники можуть маніпулювати небезпечними параметрами, щоб отримати доступ до конфіденційної інформації або отримати підвищені права доступу.
Цей скрипт використовує небезпечні параметри, такі як can_edit і is_admin, для отримання доступу до функцій, які повинні бути захищені.
Куки до сайту автоматично відправляються з кожним запитом.
Зловмисник може змусити жертву відправити запити (включаючи POST) на якийсь сайт.
Коли це відбувається, куки жертви (серед яких аутентифікаційні куки) відправляються на сервер.
BLUE TEAM
Використання CSRF-токенів. Вони зберігаються у сесіях користувачів та додаються у форми у вигляді прихованого поля. Коли користувач надсилає форму, токен перевіряється.
Якщо він не збігається з тим, що у сесії, користувач отримує помилку.
RED TEAM
Використання CSRF для зміни даних. Зловмисники можуть змусити жертву відправити запит на сервер, використовуючи їхні аутентифікаційні дані, щоб виконати небажані дії.
Цей код змушує жертву перевести кошти на рахунок зловмисника, використовуючи їхню сесію та куки, навіть не підозрюючи про це.
Криптографічні помилки – це недоліки в реалізації криптографії, які можуть призвести до витоку або компрометації даних.
Опис: Використання застарілих або небезпечних криптографічних алгоритмів або протоколів.
Приклад: Використання MD5 для хешування паролів замість більш сучасних алгоритмів, таких як bcrypt або Argon2, що може призвести до легкого злому хешів.
Опис: Неправильне або недостатнє шифрування чутливих даних.
Приклад: Зберігання паролів в простому текстовому форматі або використання слабких ключів шифрування, що робить дані доступними для зловмисників.
Опис: Зберігання криптографічних ключів у ненадійних місцях або без належного захисту.
Приклад: Зберігання криптографічних ключів у коді додатка або конфігураційних файлах, доступних для зловмисників.
Опис: Ненадійне управління сеансами, яке дозволяє зловмисникам перехоплювати або підробляти сеанси користувачів.
Приклад: Використання передбачуваних або недостатньо складних сесійних ідентифікаторів, які можуть бути легко вгадані або підроблені.
HTML entities – це спеціальні символи, які використовуються для заміни небезпечних або резервованих символів у HTML-коді, щоб запобігти їх неправильній інтерпретації браузером.
Приклад:
Оригінальний код: <script>alert(‘XSS’);</script>
Закодований: <script>alert(‘XSS’);</script>
HTML-код у браузері інтерпретується як текст, а не як виконавчий код, що запобігає XSS-атакам.
Якщо вебсайт некоректно обробляє HTML-код і не проводить належне кодування введених даних, зловмисник може скористатися XSS-атакою (Cross-Site Scripting) для виконання JavaScript-коду на клієнтській стороні. Це може дозволити йому викрасти сесії користувачів, вставити шкідливі скрипти або змінити дані на сторінці.
Приклад:
Зловмисник вводить: <script>alert(‘XSS’);</script> у форму введення, і якщо дані не закодовані належним чином, цей скрипт буде виконаний у браузері іншого користувача.
URL кодування (також відоме як процентне кодування) використовується для забезпечення передачі спеціальних символів у URL-адресах. Це потрібно, щоб уникнути конфліктів зі спеціальними символами, які мають значення в URLструктурі.
Приклад:
Оригінальний текст: lorem with !@#$%^
Закодований: lorem+with+%21%40%23%24%25%5E
Спеціальні символи кодуються у форматі %XX, де XX – це шістнадцяткове значення ASCII коду символу.
Зловмисники можуть використати URL-кодування для обходу фільтрів веб-додатків. Наприклад, якщо сервер фільтрує небезпечні символи, такі як < і >, зловмисник може закодувати їх у %3C і %3E і ввести шкідливий код.
Приклад:
URL кодування може бути використане для обходу фільтрів SQL-ін’єкцій або XSS-атак. Зловмисник може закодувати шкідливий SQL-запит або JavaScript-код і ввести його у форму на сайті, який не перевіряє та не розкодовує ці дані належним чином.
Base64 – це спосіб кодування даних, що перетворює їх у формат, який складається лише з символів, які можуть бути представлені в текстовому вигляді (букви, цифри та кілька спеціальних символів). Цей метод зазвичай застосовується для передачі бінарних даних, таких як зображення або файли, у текстовому форматі.
Приклад:
Оригінальний текст: this is original text
Закодований: dGhpcyBpcyBvcmlnaW5hbCB0ZXh0
Base64 кодує дані у вигляді тексту, який можна передавати через текстові протоколи.
Перспектива Red Team:
Зловмисники можуть використовувати Base64 для приховування шкідливого коду або даних у невидимому для користувача форматі, що ускладнює виявлення атаки.
Приклад:
Зловмисник може закодувати шкідливий JavaScript-код у Base64 і вбудувати його у веб-сторінку або електронний лист. Після декодування цей код може виконатися і завдати шкоди системі користувача.
Як працює HTTP:
Клієнт (наприклад, браузер) відправляє HTTP-запит до веб-сервера з проханням надати певний ресурс (наприклад, веб-сторінку).
Сервер відповідає на запит, надсилаючи назад ресурс, який може бути HTML-файлом, зображенням, або іншим типом даних.
HTTP – небезпечний протокол, оскільки передає дані у відкритому вигляді, без шифрування. Це дає можливість зловмисникам перехопити інформацію під час атаки типу “людина посередині” (MITM). Такий доступ дозволяє їм отримати конфіденційні дані, зокрема паролі, сесійні токени та іншу важливу інформацію.
Приклад:
MITM-атака: Зловмисник може використовувати мережевий сніфер, наприклад, Wireshark, для перехоплення трафіку HTTP і читання переданих даних, наприклад, логінів і паролів.
Session Hijacking: Використовуючи перехоплені дані, такі як сесійні куки, зловмисник може захопити сесію користувача і отримати доступ до його облікового запису.
HTTPS – це безпечна версія HTTP, яка застосовує шифрування для забезпечення конфіденційності, цілісності та аутентичності даних, що передаються. Для захисту даних HTTPS використовує протокол TLS (Transport Layer Security) або його попередника SSL (Secure Sockets Layer).
Як працює HTTPS:
При використанні HTTPS, всі дані між клієнтом і сервером шифруються, що захищає їх від перехоплення і модифікації.
HTTPS також забезпечує аутентифікацію серверу за допомогою цифрових сертифікатів, що підтверджують, що клієнт підключається до правильного сервера, а не до підробленого.
Перспектива Red Team:
HTTPS не є повністю захищеним. Хоча HTTPS шифрує дані, це не захищає від інших типів атак. Наприклад, якщо сервер неправильно налаштований, зловмисники можуть виконати атаки типу SSL-stripping або використовувати вразливості в реалізації TLS/SSL.
Приклад:
SSL-Stripping: Зловмисник перехоплює трафік і замінює HTTPS на HTTP під час запиту. Користувач бачить звичайну HTTP-сторінку, думаючи, що вона захищена, а всі дані передаються у відкритому вигляді.
Атаки на TLS: Вразливості у старих версіях SSL/TLS, таких як POODLE, можуть бути використані для розшифрування даних або здійснення інших атак на конфіденційність.
Зберігання чутливих даних за допомогою шифрування. Щоб забезпечити захист чутливої інформації, яка може бути використана в майбутньому, її слід зберігати у зашифрованому вигляді. Це гарантує, що навіть у разі викрадення або злому даних, доступ до них буде обмежений для несанкціонованих осіб.
Приклад шифрування:
Приклад:
Атака на недостатньо надійний пароль: Якщо пароль або фраза ключа є слабкими, зловмисник може здійснити атаку перебором (brute-force) і отримати доступ до даних. Наприклад, використовуючи такі інструменти, як Hashcat, можна автоматизувати підбір ключа.
Атака на IV: Якщо ініціалізаційний вектор (IV) занадто короткий або повторюється, зловмисник може спробувати розшифрувати дані за допомогою атак на шифротекст (ciphertext attacks).
Зберігання паролів з використанням хешування. Паролі повинні зберігатися у вигляді хешу, а не у відкритому вигляді, щоб забезпечити їхній захист у разі витоку бази даних.
Приклад хешування пароля:
Атака на хеш: Якщо хеші паролів зберігаються без належного додаткового захисту, зловмисники можуть скористатися такими методами, як Rainbow Tables або brute-force атаки, щоб розкрити паролі.
Приклад:
Слабке хешування: Якщо використовується слабкий або застарілий алгоритм хешування (наприклад, MD5 або SHA1), зловмисники можуть швидко розкрити паролі.
Атака на сіль (salt): Якщо хешування здійснюється без додавання солі (random salt), зловмисник може використовувати попередньо обчислені таблиці (Rainbow Tables) для розкриття хешів.
Ін’єкції – це вразливості, що дозволяють зловмисникам вносити шкідливий код або дані в додаток, що призводить до небажаних або небезпечних дій.
Опис: Вразливість, яка дозволяє зловмисникам вставляти SQL-код у запити до бази даних.
Приклад: Веб-додаток, що використовує введення користувача для формування SQL-запитів без належної перевірки, що дозволяє зловмиснику виконувати довільні SQL-запити.
Опис: Вразливість, при якій зловмисник може вносити команди операційної системи.
Приклад: Додаток, що виконує системні команди на основі введення користувача, дозволяючи зловмиснику виконувати небажані команди.
Опис: Вразливість, при якій зловмисник може вставляти шкідливий JavaScript-код в веб-сторінки, які потім виконуються в браузері інших користувачів.
Приклад: Додаток, що відображає дані, введені користувачем, без належного очищення, що дозволяє зловмиснику вставляти шкідливий код.
XSS (Cross-Site Scripting) – це уразливість, що дозволяє зловмиснику вставляти шкідливий скрипт у вебсторінку, який виконується у браузері жертви. Це може призвести до крадіжки сесійних кукі-файлів, зміни контенту сторінки, або перенаправлення користувача на шкідливий сайт.
Зловмисник може вставити JavaScript код, який виконує небажані дії, такі як крадіжка кукі-файлів або перенаправлення користувача.
Для запобігання XSS атак, забезпечте санітизацію вводу та виводу:
Санітизація вводу: Використовуйте htmlspecialchars() для очищення даних, отриманих від користувача.
Санітизація виводу: Використовуйте функції, які автоматично екранізують вивід, такі як htmlspecialchars() в PHP або автоекранування у шаблонних двигунах Twig або Blade.
HTTP Only флаг: Використовуйте флаг HTTP Only для кукі-файлів, щоб заборонити доступ до них через JavaScript.
Крадіжка кукі-файлів:
Підробка контенту сторінки:
SQL Injection – це уразливість, при якій зловмисник може вставити шкідливий SQL код у запити до бази даних, що дозволяє отримати доступ до даних, змінити їх або видалити.
Небезпечний SQL-запит:
Запобігання SQL Injection:
Використовуйте підготовлені запити (prepared statements):
Зловмисник може вставити небезпечний код у $someString:
HTTP Parameter Injection – це уразливість, яка виникає, коли зловмисник модифікує параметри HTTP запитів для отримання несанкціонованого доступу або зміни даних.
Уразливий код, який дозволяє змінювати параметри:
Файлові уразливості можуть виникати через неправильну обробку або валідацію файлів, які завантажуються користувачами, або через уразливості у веб-серверах.
Використання require() та include() в PHP:
Зловмисник може включити шкідливий файл, на приклад: http://attacker.site/malicious.php.
Слабка валідація файлів:
Зловмисник може використовувати ../ для навігації до небажаних директорій.