Атаки ін’єкцій належать до будь-якого типу атак, які націлені на ін’єкційні вразливості – широку категорію вразливостей кібербезпеки, яка містить кілька найсерйозніших ризиків для безпеки додатків. Хоча можна стверджувати, що це штучний спосіб згрупувати атаки, які не пов’язані між собою, у Топ 10 OWASP за 2021 рік використали саме такий підхід, назвавши ін’єкції третьою категорією ризиків для безпеки вебдодатків, не перелічуючи конкретні вразливості, як у попередніх виданнях.
Попри широке розмаїття векторів атак, спільним знаменником для ін’єкційних атак є те, що зловмисники можуть впроваджувати корисне навантаження у виконуваний код застосунку через неперевірене користувацьке введення. Залежно від конкретної вразливості та цілі атаки, ін’єкції можуть включати запити до бази даних, код JavaScript, власний код програми, команди операційної системи тощо. В разі успіху, ін’єкційні атаки можуть мати широкий спектр наслідків, від розкриття менш чутливої інформації до більш серйозних витоків даних, відмови в обслуговуванні, підвищення привілеїв, обходу автентифікації або навіть віддаленого виконання коду та потенційно повної компрометації цільової системи.
Атака ін’єкцій №1: SQL-ін’єкція (SQLi)
Більшість вебдодатків підтримуються базами даних, багато з них покладаються на стандартні системи управління реляційними базами даних, які використовують SQL як мову доступу до даних і запитів. Атаки SQL-ін’єкцій здійснюються шляхом включення оператора SQL в дані, що надсилаються через вебформу, поле для коментарів, рядок запиту, параметр або інший канал введення, доступний для зовнішніх користувачів. Шкідливий код може являти собою SQL-запит, призначений для вилучення конфіденційних даних, або SQL-запит, спрямований на модифікацію вмісту бази даних шляхом додавання або видалення записів або навіть цілих таблиць бази даних. Зловмисники часто націлені на записи користувачів, щоб додати привілейованого користувача або підвищити привілеї для наявного облікового запису.
Додаток, який має вразливість до SQL-ін’єкцій, включає контрольоване користувачем введення в оператори SQL, які він будує. Отриманий запит надсилається на сервер бази даних без достатньої перевірки або кодування і виконується, включаючи будь-які зловмисні оператори SQL, введені зловмисником. Якщо вразливий додаток не повертає дані безпосередньо, зловмисники можуть використовувати blind SQL-ін’єкції для непрямого отримання інформації.
Інструменти DAST компанії Invicti можуть автоматично виявляти багато типів SQL-ін’єкцій, від типових in-band SQL ін’єкцій (включаючи UNION ін’єкції) до blind SQL-ін’єкцій (включаючи булеві) та позасмугових SQL-ін’єкцій.
Атака ін’єкцій №2: Міжсайтовий скриптинг (XSS)
Хоча в назві немає слова «ін’єкція», міжсайтовий скриптинг (XSS) полягає у використанні вразливостей, пов’язаних з впровадженням скриптів. Якщо вебдодаток не може захистити вхідні дані, що вводяться користувачем і містять код скриптів (зазвичай JavaScript), він може бути вразливим до XSS. Щоб використати XSS-вразливість, зловмисник передає користувачеві рядок, який містить шкідливий код, зазвичай додаючи його як значення параметра запиту. Замість того, щоб обробити це значення відповідно до логіки програми, вразливий додаток виконує наданий скрипт у браузері користувача.
Хоча іноді XSS-атаки вважаються низькоризиковими та обмежуються однією сесією користувача, вони можуть мати серйозні наслідки, особливо якщо використовуються в довшому ланцюжку атак. Щобільше, оскільки повно стекові JavaScript-додатки тепер також працюють на стороні сервера за допомогою Node.js, вплив XSS-атак більше не обмежується браузером. Для запобігання XSS недостатньо лише фільтрації користувацького вводу, оскільки існує багато способів обійти XSS-фільтри, тому для запобігання XSS рекомендується дотримуватися безпечних практик кодування та обмежувати джерела скриптів за допомогою Content Security Policy.
Invicti DAST може виявляти та автоматично підтверджувати багато типів XSS-вразливостей, включаючи відображені XSS, збережені («persistent») XSS та XSS на основі DOM-файлів.
Атака ін’єкцій №3: Ін’єкція команд операційної системи
Вебдодаткам іноді може знадобитися виконання команд операційної системи, наприклад, для читання або запису файлів на вебсервері.
Для програми з вразливістю до ін’єкції команд в ОС зловмисники можуть приховати шкідливі системні команди у вхідних даних користувача та змусити програму виконати їх на сервері. Успішне введення команд (також зване ін’єкцією командного рядка (shell injection)) може бути надзвичайно небезпечним, дозволяючи зловмисникам отримати інформацію про конфігурацію системи та сервера, підвищити рівень дозволів користувача або виконати довільні системні команди, щоб повністю скомпрометувати систему.
Оскільки наслідки можуть бути дуже серйозними, рекомендується уникати виклику системних команд, які містять дані, контрольовані користувачем, у вебдодатках. Якщо виконання системної команди є необхідним, обов’язково ретельно перевірити всі її вхідні дані та обмежити їх конкретними дозволеними значеннями.
Сканери Invicti DAST можуть виявляти кілька варіантів вразливостей, включаючи сліпе та позасмугове введення команд.
Атака ін’єкцій №4: Ін’єкція коду (віддалене виконання коду, RCE)
Додаток має вразливість до ін’єкції коду (також відома як віддалене виконання коду або RCE), якщо зловмисник може включити код додатка у вхідні дані користувача і змусити додаток виконати його. Різниця у порівнянні з ін’єкцією команд ОС полягає в тому, що впроваджується код додатка, а не системні команди (хоча ці два випадки можуть траплятися разом, якщо додаток приймає шкідливий код, який потім викликає системну команду). Наприклад, при впровадженні коду у вразливий додаток, написаний на PHP, буде використано PHP-код, а у вразливий Java-додаток буде впроваджено Java-код.
Хоча більшість вразливостей, пов’язаних з ін’єкцією коду, можна використати лише як частину довшого ланцюжка атак, RCE має високий авторитет у тестуванні безпеки додатків, оскільки якщо зловмиснику вдається отримати віддалене виконання коду, він може робити практично все, що завгодно, тому цільова система вважається повністю скомпрометованою. Хоча конкретний рейтинг серйозності залежить від простоти експлуатації, RCE вразливості майже завжди є критичними.
Сканер вразливостей Invicti може виявляти та часто автоматично підтверджувати десятки вразливостей виконання та оцінки коду в різних мовах програмування та фреймворках.
Атака ін’єкцій №5: XXE-ін’єкція
Останнім пунктом в цьому списку є ін’єкція зовнішніх об’єктів XML (XXE-ін’єкція), яка дещо відрізняється від попередніх. XML-документи використовуються у всіх видах запитів вебдодатків, і якщо додаток, який приймає вхідні дані в XML, налаштований на підтримку застарілих визначень типів документів (DTD) зі слабким захистом парсера XML, зловмисники можуть використовувати спеціально створені XML-документи для виконання XXE-ін’єкції. Це порушує роботу аналізатора XML і може бути використано для подальших кібератак, починаючи від обходу каталогів і закінчуючи підробкою запитів на стороні сервера (SSRF) або навіть віддаленим виконанням коду.
В той час як перші чотири розглянуті тут атаки типу «ін’єкція» базуються на збоях у перевірці користувацького введення, XXE використовує небезпечні за своєю суттю застарілі функціональні можливості парсерів XML. Оскільки це скоріше випадок небезпечної конфігурації, ніж небезпечного коду, XXE важко виявити, що робить цю вразливість особливо небезпечною. Якщо програма обробляє XML-документи, єдиний спосіб уникнути XXE-вразливостей – вимкнути підтримку DTD або (якщо доводиться їх використовувати) принаймні заборонити використання зовнішніх сутностей.
Сканер вебвразливостей Invicti виявляє багато вразливостей XXE-ін’єкцій, включаючи out-of-band XXE-ін’єкції.
Інші поширені ін’єкційні атаки
Перша п’ятірка представляє найпоширеніші ін’єкційні вразливості, які сьогодні зустрічаються в додатках та API, але кілька менш поширених ін’єкційних атак також заслуговують на згадку:
- NoSQL-атаки працюють за тим же принципом, що й SQL-атаки, але націлені на бази даних, які не використовують SQL-запити, такі як MongoDB, Cassandra або Elasticsearch. Оскільки не існує стандартної мови запитів для NoSQL-баз даних, корисне навантаження NoSQL-ін’єкцій відрізняється для кожного типу серверів баз даних.
- Атаки з використанням JSON-ін’єкцій тісно пов’язані з XSS, але замість того, щоб впроваджувати скриптовий код, зловмисники намагаються вставити або змінити JSON-дані, що надсилаються або отримуються додатком. Цей метод особливо корисний при атаках на REST API, де JSON є основним форматом даних.
- Server-side template injection, SSTI атакує цільові серверні шаблони, які використовуються для динамічної генерації коду вебсторінок. Якщо зловмисникам вдасться вставити вирази у відповідну мову шаблонів, їхній шкідливий код буде включений в HTML-код сторінки.
- Ін’єкція HTTP-заголовка (CRLF-ін’єкція) можлива, коли програма приймає символи нового рядка, які потім потрапляють безпосередньо в HTTP-заголовок. HTTP-запити використовують новий рядок для розділення заголовка і тіла запиту, тому ін’єкція символів нового рядка може дозволити зловмиснику замінити легітимне тіло відповіді на HTML-дані, що містять шкідливий код, наприклад, XSS-дані.
Запобігання ін’єкційним вразливостям та атакам
Окрім XXE, всі перелічені тут атаки ін’єкцій ґрунтуються на тому, що вебдодаток приймає та виконує неавторизовані дані, введені користувачем. Основною проблемою безпеки є неналежна перевірка вхідних даних, яка займає четверте місце в списку CWE Top 25. Належна перевірка, фільтрація та кодування всіх даних, що вводяться користувачем в додаток, допоможе запобігти переважній більшості тривіальних вразливостей, пов’язаних з ін’єкціями. Встановлення правильних заголовків безпеки HTTP і правил CSP також заблокує багато шляхів зовнішніх атак на самому початку.
Розробники повинні знати та використовувати функції безпечної обробки вхідних даних в сучасних вебфреймворках і мовах. Більшість SQL-ін’єкцій можна запобігти, використовуючи параметризовані запити або підготовлені на стороні сервера оператори (так звані збережені процедури), а такі фреймворки, як React, надають вбудовані конструкції, які роблять майже неможливим написання коду, вразливого до XSS (якщо тільки навмисно не обходити всі вбудовані захисні засоби).
Вразливості завжди можуть з’являтися як у новому та оновленому коді, так і в коді, який раніше вважався безпечним, тому дуже важливо постійно тестувати всю поверхню атак, яку можна використати. Рекомендованою практикою є регулярне автоматичне сканування всіх вебдодатків та API за допомогою високоякісного динамічного рішення для тестування безпеки додатків, інтегрованого як у життєвий цикл розробки, так і в операції з забезпечення безпеки.
