Вразливості та атаки як Cross-Site Scripting (XSS) не зникнуть найближчим часом, але можна знизити ризик успішних XSS атак.
JavaScript пройшов шлях від додавання динамічності до статичних HTML-сторінок до ключового компонента сучасних вебдодатків, роблячи XSS поширеною вразливістю безпеки. Атаки типу XSS стали більш впливовими через збільшення використання JavaScript не тільки на клієнтській, але і на серверній стороні за допомогою Node.js. Додавши до цього велику кількість зовнішніх залежностей, завантажених під час виконання, виходить заплутана мережа взаємопов’язаних скриптів. Деякі з яких можуть бути вразливими або навіть шкідливими.
Cross-Site Scripting – це складна і заплутана сфера безпеки вебдодатків, яка робить практично неможливим запобігти кожній окремій атаці. (JavaScript є найпопулярнішим засобом атаки, але XSS можливий і з іншими типами скриптів, включаючи XSS у CSS.) Більшість XSS вразливостей та атак можна запобігти, дотримуючись кількох практик у розробці та впровадженні.
Запобігання XSS атакам
Дотримуючись цих практик, можна запобігти більшості атак типу Cross-Site Scripting:
- Встановити заголовки безпеки HTTP: Потрібно визначити правильні заголовки Content Security Policy (CSP) у відповідях HTTP, щоб запобігти завантаженню шкідливих скриптів.
- Сприймати всі введення як ненадійні: Завжди перевіряти вхідні дані користувача (включаючи вхідні та вихідні дані API), виконувати валідацію вхідних даних та використовувати контекстно-залежне кодування вихідних даних.
- Використовувати безпечні практики кодування та інструменти: Уникати використання inline скриптів і правильно використовувати будь-які функції, стійкі до XSS, які надає фреймворк додатків, такі як автоматичні функції кодування.
- Проводити регулярне тестування на вразливості: Періодично перевіряти вебсайти та додатки за допомогою актуального сканера вебвразливостей, щоб вчасно виявляти їх.
(Важливо: фільтрація тут навмисно не згадується – далі описано, чому не можна довіряти фільтрації XSS.)
Вразливості типу Cross-Site Scripting
По суті, XSS є типом ін’єкційної атаки, як і SQL-ін’єкція, але впроваджується JavaScript код замість SQL-інструкцій. Але на відміну від SQL-ін’єкції, де завжди намагаються змінити SQL-запит, існує багато різних типів XSS, залежно від способу доставлення та виконання шкідливого коду. Основні типи XSS атак:
- Reflected XSS атаки: Класична XSS вразливість, коли значення параметра введення HTTP запиту безпосередньо використовується у відповіді, відображаючи шкідливий код з введення та виконуючи його в браузері користувача. Хоча це найпоширеніший тип XSS, його наслідки обмежуються одним користувачем і браузером.
- Stored XSS атаки: Щоб впровадити JavaScript у кілька браузерів, зловмисник може спробувати ввести XSS-атаку на внутрішній ресурс, до якого буде мати доступ багато користувачів. Якщо корисне навантаження зберігається як є і вебсервер не очищає його при завантаженні, один запис у базі даних або серіалізованому файлі може призвести до XSS у тисячах браузерів, коли вони завантажуватимуть цей запис.
- DOM-based XSS атаки: Багато вебдодатків переписують свій внутрішній документ об’єктної моделі (DOM) під час виконання без перезавантаження сторінки. Якщо зловмисник зуміє ввести шкідливий JavaScript код у DOM і запустити його, цей код існуватиме лише в браузері користувача. Такі атаки будуть невидимими (і неможливими для запобігання) на серверній стороні.
Єдине, що об’єднує всі XSS вразливості – це те, що вони дозволяють JavaScript коду існувати десь у введеннях або виведеннях додатка. Фільтри намагалися знайти цей код і блокувати його, проте в довгостроковій перспективі це не спрацювало.
Чому не можна довіряти XSS-фільтрації
Ранні підходи до запобігання XSS-атакам ґрунтувалися на видаленні тегів <script> із введених даних, починаючи з саморобних фільтрувальних функцій, які з часом переросли в потужні фільтри, вбудовані у веббраузери. Проблема полягала в тому, що, хоча надійно ідентифікувати та блокувати конкретний шкідливий код легко, створити загальні шаблони для зупинки шкідливих скриптів без втручання у легітимні виявилося майже неможливим.
XSS-фільтрація не працює і не може бути єдиним захистом від XSS-атак. Хоча більшість фаєрволів (WAF) мають вбудовані XSS-фільтри, які можуть зупинити основні атаки, уникнення XSS-фільтрів для обходу правил WAF є основою для будь-якого серйозного зловмисника. Тож, ніколи не варто покладатися лише на XSS-фільтр для забезпечення захисту від атак.
Cross-Site Scripting в API
Стереотипна XSS-атака – це коли хтось вводить у поле форми або параметр URL. Але як щодо XSS у сучасних додатках, керованих API? З бекендом, який тепер діє як окремий постачальник даних для будь-якої кількості фронтендів, що спілкуються з ним через API, неможливо централізовано запобігти XSS на сервері. Запити API, які включають чутливі дані, є привабливою ціллю для зловмисників. Це робить XSS дуже реальною загрозою, навіть без видимого поля форми.
Кращі практики багаторівневої безпеки для запобігання XSS
Не існує рішення, яке б повністю захистило додатки від XSS. Але, якщо дотримуватись кількох безпечних практик для створення кількох рівнів захисту, можна зробити успішні XSS-атаки вкрай малоймовірними.
Переможне поєднання полягає в значному обмеженні поверхні атаки за допомогою правильних заголовків CSP, а також використанні безпечних практик кодування та інструментів для мінімізації кількості XSS-вразливостей, які потрапляють у продакшн. Фінальним штрихом буде регулярне сканування на вразливості за допомогою якісного інструмента DAST.
