Авторка: Катерина Іваненко, Invicti Brand Manager
Міжсайтовий скриптинг (XSS) – це клас недоліків, що дозволяють зловмисникам виконувати шкідливий JavaScript у браузері цілі. Це відбувається, коли ненадійні дані включаються у вебсторінки без належної обробки, що надає можливості для захоплення сесій користувачів, дефейсу або подальших атак.
Фундаментальною причиною XSS є неправильна нейтралізація ненадійних вхідних даних під час генерації вебсторінки або маніпуляцій DOM (CWE-79). Варіанти XSS є різними вираженнями однієї й тієї ж основної проблеми, але в цьому є багато нюансів.
Три типи XSS та причини їх виникнення
Збережений XSS
Вхідні дані, контрольовані зловмисником, зберігаються застосунком (наприклад, у базі даних, CMS або коментарі) та пізніше відображаються на сторінках для інших користувачів. Першопричиною зазвичай є змішування ненадійних даних з HTML-відповідями без кодування або очищення виводу.
Відображений XSS
Ненадійні дані (наприклад, з форми) одразу відображаються у відповіді. Це часто виникає, коли шаблони на стороні сервера включають параметри запиту без кодування на основі контексту.
XSS на основі DOM
JavaScript на стороні клієнта зчитує дані, контрольовані зловмисником (наприклад, location.search або document.referrer), та записує їх у приймачі (sinks), такі як innerHTML, document.write або eval() без будь-яких безпечних практик. Дефект існує суто в браузері, що ускладнює його виявлення.
Основні причини, чому розробники все ще допускають XSS
1) Змішування даних та коду без кодування на основі контексту
XSS процвітає, коли програми інтерполюють ненадійні дані безпосередньо в HTML, атрибути, JavaScript, CSS або URL-адреси, не використовуючи правильне кодування для цього контексту. Одного підходу “екранування всього” недостатньо; його правила повинні відрізнятися залежно від контексту. Незастосування правильного кодувальника є однією з головних причин, чому XSS продовжує існувати.
2) Небезпечні API та приймачі на стороні клієнта
Сучасний фронтенд часто маніпулює DOM під час виконання вебсайту. Використання приймачів, таких як innerHTML, outerHTML, insertAdjacentHTML, document.write або встановлення атрибутів обробника подій on* з неочищеними рядками, впроваджує HTML/JS безпосередньо в документ. Навчальні матеріали з безпеки постійно позначають їх як високоризикові, коли вони надходять з даними, контрольованими зловмисником.
3) Довіра до джерел URL/DOM без перевірки
Код на стороні клієнта часто використовує значення з джерел, на які має вплив зловмисник (параметри URL, ідентифікатори фрагментів, document.referrer). Передача цих джерел безпосередньо в контексти HTML або скриптів без перевірки або безпечних API уможливлює XSS на основі DOM.
4) Недостатня або неправильно застосована перевірка вхідних даних
Хоча вихідне кодування є основною практикою, відсутність надійної перевірки білого списку для даних, які мають стати HTML, збільшує ризик. Розробники можуть спробувати використовувати фільтри на основі чорного списку, які не справляються з обфускацією та новими методами корисного навантаження, дозволяючи небезпечним токенам прослизати в контексти сторінок.
5) Рендеринг користувацького HTML без перевіреного санітайзера
Такі функції, як коментарі, контент CMS або профілі користувачів, можуть навмисно дозволяти розмітку (markup). Використання застарілих або кастомних санітайзерів – це поширений шлях до XSS. Якщо HTML має бути прийнятий, йому потрібен активно підтримуваний санітайзер та суворі політики щодо дозволених тегів/атрибутів/схем URL-адрес.
6) Впровадження шаблонів (templates) та небезпечні практики шаблонування
Шаблони на стороні сервера або клієнта, які працюють з вхідними даними користувача без безпечних практик, можуть призвести до виконання коду або XSS на сторінці.
7) Покладання виключно на CSP
Політика безпеки контенту (CSP) – це додатковий рівень захисту, а не заміна контекстно-залежного кодування. Слабкий CSP створює хибне відчуття безпеки, і навіть суворі CSP мають обмеження.
8) Сторонні скрипти та ризики ланцюга постачання
Якщо віджети, аналітика, реклама та інші сторонні скрипти небезпечно обробляють дані, контрольовані зловмисником, або якщо ланцюг постачання скомпрометовано, вони можуть давати проявитися XSS незалежно від якості власного коду сайту.
9) Застарілий код та фреймворки
Старіші бази коду та бібліотеки часто не мають сучасних стандартних налаштувань (наприклад, шаблони автоматичного екранування). Без рефакторингу застарілі шаблони, такі як об’єднання рядків HTML або вбудовані атрибути подій, зберігаються, постійно повторно впроваджуючи вразливість XSS.
10) Відсутність тестування безпеки
Навіть з урахуванням вищезазначених практик єдиний спосіб точно перевірити, чи є вебсайт вразливим до XSS, – це провести тестування безпеки. Крім того, багато інструментів надають поради щодо виправлення та корисні ресурси у тікетах, що допомагає розробникам з часом впроваджувати безпечні практики написання коду.
Для цієї мети можна використовувати різні інструменти.
- DAST: безпечна імітація дій хакера, яка виявляє вразливості вебзастосунку під час його виконання.
- SAST: статичний аналіз, який знаходить проблеми безпеки в коді «як у тексті».
Найкращий спосіб сканувати вебсайт – це використовувати обидва підходи, оскільки DAST виявляє більше реальних вразливостей завдяки тестуванню під час виконання, а SAST здатен сканувати всю базу коду та може бути інтегрований на більш ранніх стадіях CI/CD (DAST можна впроваджувати на дещо пізніших етапах).
Якщо ви хочете безкоштовно протестувати Invicti (DAST) на основі Acunetix та Netsparker з функцією підтвердження вразливостей, а також Mend.io (SAST, SCA, Container Security), будь ласка, залиште свою контактну інформацію у формі нижче:
Запит на безкоштовне тестування Invicti/Mend.io
Залиште контакти і ми з вами зв’яжемось
