Ін’єкції — поширений різновид кіберзагроз. Які базові перевірки безпеки може виконати QA?
Для QA-фахівця перевірка безпеки не менш важлива, ніж пошук багів. Навіть не будучи тестувальником із безпеки, можна виконувати цю задачу на своєму проєкті. Для цього достатньо інструментів, якими ви користуєтеся щодня. У цій статті розглянемо їх, а також один із найпоширеніших видів кіберзагроз — ін'єкції.
Базові елементи безпеки
Зазвичай вразливості націлені на одну з таких ознак:
- Confidentiality. У цьому випадку треба захищати чутливі дані від несанкціонованого доступу. Уявімо сайт постачальника електроенергії. Якщо зламати його, то можна отримати інформацію про вашу адресу, суми, які ви сплачуєте за світло тощо. Інформація є персональною та вважається чутливою, тому тут атаки зазначала конфіденційність.
-
Integrity. Захист, спрямований на підтримку точності, послідовності та надійності інформації. Повернімося до попереднього прикладу. Ви заходите на сайт, вказуєте дані лічильників і доходите до етапу здійснення оплати. Але замість потрібної кнопки бачите повідомлення про зміну рахунку для розрахунків і номер нового рахунку. Якщо виникнуть підозри, можете перевірити URL сайту та наявність HTTPS-протоколу — і тут все буде добре. Але насправді зловмисник змінив контент сайту, якому ви довіряєте. Тож інформація перестала відповідати дійсності. Із сайтом ніби все нормально, але ваші гроші відправляться не туди, куди потрібно. Це й є атака на цілісність.
-
Availability. Передбачає гарантії своєчасного та безперебійного доступу до інформації та ресурсів. У випадку із сайтом постачальника електроенергії ресурс перестає відкриватися, наприклад, через DDoS-атаку.
Варто згадати OWASP Top 10 — перелік 10-ти найбільш критичних ризиків безпеки. Рейтинг створила некомерційна організація OWASP (Open Web Application Security Project). Команда аналізує вразливості, які трапляються у репортах пентестерів з усього світу, та розбиває їх по категоріям за рівнем небезпеки.
До OWASP Top 10 входять:
- порушений контроль доступу;
- криптографічні збої;
- ін’єкції;
- небезпечний дизайн;
- неправильна конфігурація безпеки;
- вразливі та застарілі компоненти;
- помилки ідентифікації та автентифікації;
- порушення цілісності програмного забезпечення та даних;
- збої реєстрації та моніторингу безпеки;
- підробка запитів на стороні сервера.
Якщо ви глибоко займаєтесь тестуванням безпеки, детальніше про все це можете дізнатися на сайті OWASP. На базовому рівні пропоную зосередитися на одному з найпоширеніших типів ризику — ін’єкціях.
Що таке ін’єкції
Вони є наслідком недостатньої валідації даних, і вона може проявлятися в багатьох ситуаціях. А саме:
- перевірка типу даних;
- перевірка довжини та розміру даних;
- перевірка формату даних;
- перевірка на основі білого/чорного списку;
- санітарна обробка входу;
- обробка помилок.
Видів ін’єкцій існує багато. У цій статті зосередимося на найбільш поширених:
- Cross Site Scripting (XSS);
- HTML-ін’єкції;
- SQL-ін’єкції;
- Command-ін’єкції.
Перевірити ці ризики можна без додаткових, спеціальних інструментів.
Cross-Site Scripting
Цей вид атак виконується за допомогою шкідливого скрипту на сайті, який занесено зловмисником. Такий скрипт виконує певні дії, на які користувачі не розраховують. Наприклад, редирект на іншу сторінку або завантаження непотрібних файлів. Все це відбувається через неналежну якість очищення чи перевірки введених даних юзера.
XSS-атаки бувають трьох видів:
- Збережені. Скрипти зберігаються на сервері та відображаються кожен раз, коли користувач звертається до сайту.
-
Відбиті. Такі скрипти розміщуються, як правило, в URL і відображаються під час особливого сценарію. Відбиті атаки не стосується того, що ви відбили цю атаку. Просто ви виступаєте як дзеркало: відбиваєте атаку, яку самі й створили.
-
DOM-based XSS. Кіберзлочинець вбудовує шкідливий скрипт в URL-адресу. При підключенні до сторінки браузер користувача аналізує HTML-сторінку, досягає сценарію і запускає його, витягуючи шкідливий JavaScript. Особливістю DOM-based XSS є те, що атака базується на маніпуляціях з об'єктною моделлю документа веб-сторінки (Document Object Model).
Як проходить відбита XSS-атака
На ілюстрації нижче ви бачите приклад звичайної форми логіну. Коли юзер заносить якісь дані та натискає на кнопку Go, на сторінці одразу відображається повідомлення, яке копіює введені дані. Також ці дані з’являються в URL.
Зловмисник може ввести в одне з полів шкідливий скрипт, який виконує найпростішу функцію. У прикладі наведено скрипт, який просто показує вам ваші ж cookies. Але реальні скрипти діють трохи інакше: вони відправляють кукіс на чужий сервер (тобто відбувається викрадення сесії). Завдяки цьому зловмисник може користуватись cookies та робити щось від імені юзера. Це можливо завдяки тому, що введений в поле шкідливий скрипт відображається в URL. Для активації скрипту достатньо передати користувачу заражене посилання.
Після введення дані жодним чином не оброблялися, а напряму передаються в тіло сторінки.Там, де зображено Welcome test, цей скрипт не відобразився, бо він виконався. Залишилося друге поле, яке ми виконали. В результаті в тілі сторінки цей скрипт виглядає як повноцінний елемент.
І це саме відбита, а не збережена атака, адже код не зберігається на сервері. Скрипт буде виконуватись, лише коли користувач перейде за шкідливим посиланням. До того зловмисник має якось передати лінк іншій людині та переконати її перейти на сайт. При цьому шкідливий код виконується виключно на стороні клієнта. А тому вразливою буде людина, якій дали URL, а в інших користувачів усе буде добре.
Чому варто контролювати cookies
Cookies є важливим елементом безпеки даних. Це невеликі фрагменти даних про користувача та його дії, які використовує браузер. Завдяки ним сайт персоналізує інформацію, яка потрібна людині. В cookies зберігаються дані про переглянуті сторінки, налаштування, стан сеансів тощо.
При перевірці безпеки з cookies необхідно відкрити DevTools та звернути увагу на такі моменти:
- Наявність приватної інформації. Неприпустимо зберігати в кукіс у відкритому вигляді будь-які особисті дані, платіжні реквізити, фізичні та віртуальні адреси та іншу конфіденційну інформацію.
-
Є спеціальні атрибути. Cookies мають бути захищені. Наприклад, сесійні файли повинні мати атрибути HttpOnly і Secure. Перший атрибут закриває доступ для JavaScript-коду. Завдяки цьому згадана XSS-атака не дасть зловмиснику ніякої інформації, адже вона базувалась на скрипті JS-коду. Другий — вимагає передавати cookies лише через захищене з’єднання. Це убереже від MITM-атаки, скорочення Man in the middle. У такому випадку між користувачем та сервером знаходиться зловмисник, який перехоплює трафік та аналізує його. Якщо cookies не матимуть атрибуту Secure, їх можна буде легко прочитати.
-
Не використовуються local storage та session storage. Потрібно переконатися, що в цих сховищах не зберігається вся перелічена чутлива інформація.
Як проходить збережена XSS-атака
Уявімо сайт, на якому можна створити запис або залишити коментарі. При внесенні тексту він напряму відображається на сторінці. Сам же URL не змінюється (на відміну від попереднього прикладу).
Проте якщо ввести той самий шкідливий скрипт, він дасть змогу дивитися cookies. Тобто атака пройшла успішно.
Причина цьому — перенесення введених даних у тіло сторінки. Коли користувач переходить на цю сторінку, то одразу виконується шкідливий скрипт, і кукіс юзера відправляються до зловмисника.
Це і є збережена XSS-атака. Тут код зберігається на сервері. Тому щоразу, коли будь-яка людина заходить на цю сторінку, скрипт буде виконуватись. Процес не вимагає взаємодії з жертвою. Зловмиснику достатньо зробити ін’єкцію — змінити вміст сторінки, щоб під атаку потрапляли всі відвідувачі сайту.
Тестування захисту від XSS-атак — основні кроки
- Перевірити інпути на валідацію спецсимволів. Якщо зловмисник не зможе ввести в поля на сайті повноцінний JS-код скрипту, то й атаку здійснити важко або неможливо.
-
Перевірити підміну параметрів URL. Якщо на фронтенді неможливо ввести заборонені дані у вигляді спеціальних символів, зловмисники можуть спробувати змінити саме посилання. В такому випадку треба переконатися, що при внесенні даних в URL не виконується будь-який сторонній код.
-
Перевірити сек’юріті хедери. Це мають бути саме ті хедери, які відповідають за блокування XSS. До них відносяться Content Security Policy (CSP) та Х-XSS-Protection.
Security headers — це компоненти протоколу передачі гіпертексту, тобто HTTP-протоколу. Використовуються для передачі метаданих та інструкцій для клієнта та сервера. Ті зі свого боку завдяки цьому розуміють, як взаємодіяти з переданими даними. В нашому випадку найбільш важливими є Response headers. Вони задають правила обробки даних від сервера клієнтом.
Існує чимало інструкцій, які відповідають за безпеку:
- Content Security Policy;
- X-Frame-Options;
- X-XSS-Protection;
- X-Content-Type-Options;
- Referrer-Policy;
- Cache-Control.
Повний перелік security headers дивіться тут.
Для захисту від XSS важливими є два хедери:
- Content Security Policy. Дозволяє визначати, які скрипти будуть виконуватись. Для цього для скрипту генерується шифр із власним ID, і сервер запам’ятовує його. Пізніше сервер буде валідувати шифр і завдяки цьому розуміти: саме цей скрипт і треба виконувати. Сторонній скрипт не матиме такого шифру. Тож навіть якщо шкідливий код інтегрувати в тіло сторінки, він не виконається через відсутність ID шифру, який генерується при кожному запиті.
-
X-XSS-Protection. Цей хедер використовує внутрішні інструменти браузера для захисту від XSS-атак. Але цей хедер вже є застарілим, і його недостатньо. Адже деякі браузери не підтримують його. Більшість із них має суворе правило: для захисту від XSS використовувати саме CSP.
HTML-ін’єкція — що це
Якщо потрібні хедери блокують шкідливий код, який вносить зловмисник, він може перейти до іншої тактики — і спробувати здійснити HTML-ін’єкцію.
Уявімо той же сайт із коментарями, де введені дані передаються в тіло сторінки.
Якщо хедери заважають шкідливим скриптам виконуватися, зловмисник може спробувати ввести дані з HTML-тегами. Тег <b>, який відповідає за відображення тексту жирним шрифтом. У результаті браузер починає рендерити інформацію і врешті відображає текст жирним.
Зловмисник знаходить на сторінці тег <h1>, який відповідає за хедери. При цьому все, що можна ввести, знаходиться всередині таблиці із тегом <table>. Тож зловмиснику треба зробити так, аби шкідливий вміст виглядав максимально природно та адекватно. Тобто користувач не має запідозрити, що на сторінці щось змінилося.
Задля цього зловмисник генерує шкідливий вміст, який зображено на наступній ілюстрації. Він виходить з тегу таблиці, щоб контент не відображався саме в таблиці. Потім ставить тег хедера та додає шкідливе посилання для редиректу на сторонній сайт. І наостанок зловмисник прописує «Download New Version». Коли користувач заходить на сторінку, все виглядає ОК. Тому він може спокійно натиснути на посилання і потрапити на інший сайт. А там вже виконуються шкідливі дії.
Що таке SQL-ін’єкція
Такі ін'єкції спрямовані на бази даних. Зловмисник маніпулює даними користувача у запиті SQL.
Усе починається з логін-сторінки. Тут є два стандартні рядки для логіну та паролю. В один із цих інпутів зловмисник вводить спеціальний символ, який закриває запит у базу даних. Через це з’являється повідомлення про помилку. І саме це є підтвердженням вразливості логін-форми до SQL-ін’єкції. Тобто на цьому етапі ви можете репортити баг.
Ця помилка можлива тому, що введені дані передаються напряму в запиті до БД. Запит у логін-формі виглядає так, як на верхній частині наступної ілюстрації. Ми обираємо з таблиці всіх users, де логін відповідає веденому логіну і пароль відповідає веденому паролю. Якщо все збігається, повертається булеве значення true. Тобто логін пройшов успішно. Та в прикладі запит видозмінено, і знов йде запит до таблиці users. Але через одинарні лапки в запиті він ніби-то закритий. Тому все, що знаходиться поза лапками, SQL вже не розуміє і відображає помилку, що й викликає попередження.
Це відкриває для зловмисника простий сценарій подальших дій. Він може ввести в один з інпутів наступне твердження: ‘ OR 1=1 --. В цьому випадку два мінуси означають знак коментарів. Хоча в різних БД використовуються різні символи для коментарів. Тому для такої SQL-ін’єкції важливо знати, яка база використовується на сайті-жертві.
Втім, можна й просто перебрати всі можливі варіанти, їх буквально кілька. В будь-якому випадку це створює шкідливий вміст, адже запит після цього виглядає зовсім інакше. Завдяки цьому зловмисник вибирає з таблиці users, де логін відповідає порожньому місцю. Тут поставлені одинарні лапки та «або один дорівнює один». І один дійсно завжди дорівнює один, тому на запит і повернеться true. Врешті зловмисник успішно залогінився в системі.
Щоб протестувати захист від SQL-ін’єкції, потрібно...
- Перевірити загальні шаблони. Спробуйте ввести в інпути шаблони. Для цього пошукайте, які знаки коментарів і знаки відображення запиту використовуються в кожній БД. В нашому випадку це одинарні лапки (‘) або подвійний дефіс (--).
-
Замінити ID-параметр в URL. Текст посилання може змінюватися не тільки при відбитих XSS-атаках, але й під час SQL-ін’єкції. Щоб перевірити це, достатньо просто в URL замість скрипту написати ін’єкцію — та подивитися на результат.
-
Перевірити повідомлення про помилки. Це не завжди відображається на фронтенді, інколи це можна побачити у відповіді браузера. Тому треба зайти в DevTools та оцінити у відповіді на запит наявність помилок, пов’язаних із SQL.
Command-ін’єкція — що це
У цьому випадку зловмисник звертається до команд операційних систем сервера, на якому знаходиться застосунок. Для атаки потрібно мати досвід користування різними ОС.
У прикладі нижче зображено відповідь на введені дані. Ті, хто знайомий з Linux, зрозуміють, що під капотом виконується команда nslookup. Це дає привід замислитися про маніпуляції з іншими командами, які виконуються на сервері.
І чи не перше, що може зробити зловмисник — спробувати команду ls. Вона покаже всі файли на сервері, де знаходиться застосунок.
Також можна виконати команду cat /etc/passwd, аби сервер показав файл з інформацією про всіх користувачів. Ця інформація ніколи не повинна відображатися для сторонніх осіб.
Наостанок залишу основні кроки, які допоможуть вам провести базові перевірки захисту від основних типів ін'єкцій:
1. Протестуйте валідацію інпутів:
- для XSS перевірити скрипти та JavaScript-код;
- для HTML-ін’єкцій ввести HTML-теги;
- переконатися у валідації спеціальних знаків інпутами;
- оцінити реакцію на консольні команди: від ping до складніших.
2. Перевірте cookies:
- чи є атрибути Secure та HttpOnly;
- чи не зберігається в кукіс чутлива інформація.
3. Перевірте хедери:
- X-XSS-Protection для максимального захисту повинен мати вміст: 1; mode=block;
- переконайтеся в наявності Content Security Policy.
У наступних матеріалах ми продовжимо тему перевірки безпеки вебпроєктів та розглянемо інші різновиди загроз.
