XSS: Міжсайтові сценарії

У цій статті ми пояснимо, що таке міжсайтові сценарії (XSS), опишемо різновиди уразливостей XSS і роз'яснимо, як знайти та запобігти XSS.

Що таке міжсайтові сценарії (XSS)

Cross-site scripting/Міжсайтові сценарії (також відома як XSS) — вразливість веб-безпеки, що дозволяє зловмиснику скомпрометувати взаємодію користувачів із вразливою програмою. Це дозволяє зловмиснику обійти політику однакового джерела (same-origin policy), призначену для відділення різних веб-сайтів один від одного. Вразливість міжсайтових сценаріїв (XSS) дозволяє зловмиснику замаскуватися під користувача-жертву, виконувати будь-які дії, які може виконати користувач, та отримувати доступ до будь-яких даних користувача. Якщо користувач-жертва має привілейований доступ до програми, зловмисник може отримати повний контроль над усіма функціями та даними програми.

Як працює XSS/міжсайтові сценарії

Міжсайтові сценарії працюють маніпулюючи вразливим веб-сайтом, щоб він повертав користувачам шкідливий JavaScript. Коли шкідливий код виконується у браузері жертви, зловмисник може повністю скомпрометувати його (жертви) взаємодію з програмою.

Концепція підтвердження XSS

Більшість уразливостей XSS можна підтвердити за допомогою корисного навантаження, яке змусить ваш власний браузер виконувати довільний JavaScript код. Давно стало звичайною практикою використовувати для цього alert() , тому що це коротка і нешкідлива команда, і її складно не помітити при успішному виклику.

На жаль, є невелика затримка, якщо ви використовуєте Chrome.Починаючи з версії 92 (від 20 липня 2021 р.), фрейми з різних джерел не можуть викликати alert() . Оскільки вони використовуються для створення більш сучасних XSS атак, вам потрібно використовувати альтернативне корисне навантаження. У цьому випадку ми рекомендуємо функцію print(). Якщо вам цікаво дізнатися більше про цю зміну і про те, чому нам подобається print() , прочитайте статтю на цю тему alert() is dead, long live print() .

Які типи XSS атак існують

Існує три основні типи XSS атак. Це:

• Reflected XSS - Відбитий XSS, де шкідливий скрипт виходить з поточного HTTP-запиту.
• Stored XSS - Збережений XSS, де шкідливий тип береться з бази даних сайту
• DOM-based XSS - XSS на основі DOMде вразливість існує в коді на стороні клієнта, а не в коді на стороні сервера.

Відображений міжсайтовий сценарій / Reflected XSS

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

Ось найпростіший приклад відбитої XSS вразливості:

https://insecure-website.com/status?message=All+is+well.  
p>Status: All is well.p>

Програма не виконує жодної обробки даних, тому зловмисник може легко побудувати атаку таким чином:

https://insecure-website.com/status?message=script>/*+Bad+stuff+here. +*/script>

p>Status:  script>/* Bad stuff here. */script>p>

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

Збережений міжсайтовий сценарій / Stored XSS

Збережений XSS (також відомий як постійний або XSS другого порядку) виникає, коли програма отримує дані з ненадійного джерела і включає ці дані у свої пізніші HTTP-відповіді небезпечним способом.

Дані, що розглядаються, можуть бути відправлені в додаток через HTTP-запити; наприклад, коментарі до повідомлення у блозі, псевдоніми користувачів у чаті або контактні дані на замовлення клієнта. В інших випадках дані можуть надходити з інших ненадійних джерел; наприклад, програма веб-пошти, що відображає повідомлення отримані по SMTP, маркетинговий додаток, що відображає повідомлення з соцмереж, або додаток для моніторингу сет, що відображає пакетні дані з мережевого трафіку.

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

p>Hello, this is my message!p>

Програма не виконує жодної обробки даних, тому зловмисник може легко відправити повідомлення, що атакує інших користувачів:

p>script>/* Bad stuff here. */script>p>

Міжсайтові сценарії на основі DOM/DOM-based XSS

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

У наступному прикладі додаток використовує JavaScript для читання значення з полів введення та запису цього значення HTML елемент:

var search  = document.getElementById('search').value;

var results  = document.getElementById('results');

results.innerHTML  =
'You searched for: '
+ search;

Якщо зловмисник може контролювати значення поля введення, він може створити шкідливе значення, що призводить до виконання власного сценарію:

Ви знайшли:  img
src=1
onerror='/* Bad stuff here. */'>

У типовому випадку поле введення заповнюється частиною HTTP-запиту, наприклад, параметром рядка запиту URL-адреси, що дозволяє зловмиснику здійснити атаку з використанням шкідливої ​​URL-адреси так само, як і Відбитий XSS.

Для чого використовується XSS

Зловмисник, який використовує вразливість міжсайтових сценаріїв, зазвичай може:

• Видавати себе за користувача-жертву або маскуватися під нього.
• Виконати будь-яку дію, яку може виконати користувач.
• Читати будь-які дані, до яких користувач може отримати доступ.
• Захопити обліковий запис користувача.
• Виконати віртуальний дефейс веб-сайту.
• Впровадження троянських функцій на веб-сайт.

Вплив XSS-уразливостей

Фактичний вплив XSS-атаки зазвичай залежить від характеру програми, його функціоналу та даних, а також статусу компрометованого користувача. Наприклад:

• У додатку, де всі користувачі анонімні, а вся інформація є загальнодоступною, вплив часто буде мінімальним.
• У додатку, який зберігає конфіденційні дані, такі як банківські транзакції, електронні листи або медичні записи, вплив буде дуже серйозним.
• Якщо скомпрометований користувач має підвищені привілеї в додатку, вплив, як правило, буде критичним.Дозволяючи зловмиснику отримати контроль над вразливим додатком та скомпрометувати всіх користувачів та їх дані.

Як знайти та протестувати XSS вразливості

Переважну більшість вразливостей можна знайти за допомогою веб-сканера вразливостей.

Ручне тестування Відбитих та Збережених XSS зазвичай включає відправлення деякого простого унікального введення (наприклад, короткого літерно-цифрового рядка) у кожну точку входу в додатку, ідентифікацію кожного місця, де надіслані дані повертаються в HTTP-відповідях, та тестування кожного розташування окремо для визначення чи можна використовувати правильно сформоване введення для виконання довільного JavaScript. Таким чином, ви можете визначити контекст, в якому відбувається XSS, і вибрати корисне навантаження для його використання.

Ручне тестування XSS на основі DOM, що виникає з параметрів URL, включає аналогічний процес: розміщення деякого простого унікального введення в параметр, використання інструментів розробника браузера для пошуку цих даних DOM і перевірка кожного розташування для визначення можливості його використання. Однак інші типи DOM XSS найважче виявити. Для пошуку вразливості на основі DOM у вхідних даних, не заснованих на URL (наприклад, document.cookie ) або приймачах не заснованих на HTML (наприклад setTimeout ), ніщо не замінить перегляду JavaScript коду, який може зайняти дуже багато часу. Сканери веб-уразливостей поєднують у собі статичний та динамічний аналіз JavaScript для надійної автоматизації вразливостей на основі DOM.

Політика безпеки контенту / Content security policy

Політика безпеки контенту (CSP) - механізм браузера, мета якого пом'якшення впливу міжсайтових сценаріїв та деяких інших уразливостей. Якщо програма, що використовує CSP, поводиться як XSS, то CSP може утруднити або запобігти використанню вразливості. Часто CSP можна обійти, щоб використовувати основну вразливість.

Використання висячої розмітки / Dangling markup injection

Використання висячої розмітки — це метод, який можна використовувати для захоплення даних між доменами в ситуації, коли повноцінний експлойт міжсайтового сценарію не можливий через вхідні фільтри або інші засоби захисту. Його часто можна використовувати для збирання конфіденційної інформації, доступної іншим користувачам, включаючи CSRF токени, які можна використовувати для виконання несанкціонованих дій від імені користувача.

Як запобігти атакам XSS

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

В цілому, ефективне запобігання XSS-уразливостей, ймовірно, буде включати поєднання наступних заходів:

• Фільтрувати вхідні дані. У момент отримання даних фільтруйте якомога суворо на основі очікуваного або валідного введення.
• Кодування даних на виході. У момент, коли дані, що керуються користувачем, виводяться в HTTP-відповідях, кодуйте вихідні дані, щоб запобігти їх інтерпретації як активний вміст. Залежно від контексту виводу може знадобитися комбінація HTML, URL, JavaScript та CSS кодування.
• Використовуйте відповідні заголовки відповідей. Для запобігання XSS у HTTP-відповідях, які не повинні містити будь-який HTML або JavaScript, ви можете використовувати заголовки Content-Type та X-Content-Type-Options для гарантії, що браузер інтерпретує відповіді так, як ви задумали.
• Політика безпеки контенту. В якості останньої лінії захисту ви можете використовувати політику безпеки контенту (CSP) для зменшення серйозності будь-яких уразливостей XSS, які все ще зустрічаються.

Загальні питання про міжсайтові сценарії

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

Наскільки поширені атаки XSS?

Важко отримати надійні дані про реальні XSS-атаки, але, ймовірно, вони використовуються рідше, ніж інші вразливості.

У чому різниця між XSS та CSRF?

XSS змушує веб-сайт повертати шкідливий код JavaScript, а [CSRF](/articles/security/csrf/) спонукає користувача-жертву виконувати дії, які він не мав наміру вчиняти.

У чому різниця між XSS та SQL-ін'єкцією?

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

Як запобігти XSS в PHP?

Фільтруйте дані, що вводяться, за допомогою білого списку дозволених символів і використовуйте підказки типів або наведення типів. Екрануйте вхідні дані з htmlentities та ENT_QUOTES для HTML контекстів або екранування JavaScript Unicode для контексту JavaScript.

Як запобігти XSS Java?

Фільтруйте дані, що вводяться, за допомогою білого списку дозволених символів і використовуйте бібліотеку, наприклад Google Guava для HTML-кодування вихідних даних для HTML контексту або використовуйте escape-послідовності JavaScript Unicode для JavaScript контексту.

Міжсайтовий скриптинг – що це таке?

XSS (Cross-Site Scripting) - це тип вразливості, пов'язаної з веб-додатками та їх безпекою, яка дозволяє зловмиснику впровадити та виконати шкідливий скрипт (на Javascript) на стороні клієнта (веб-браузера) іншого користувача. Уразливість XSS виникає, коли веб-додаток недостатньо перевіряє або очищає введення, що надається користувачем, перед його відображенням на сторінці. У цій статті докладно розглянемо сценарії виявлення XSS-уразливостей та атак.

Як працює міжсайтовий скриптинг?

Міжсайтовий скриптинг (XSS-уразливість) працює шляхом виконання шкідливого коду http сайтів (зазвичай мовою JavaScript) на стороні клієнта (веб-браузера) іншого користувача. Процес зазвичай включає такі кроки:

1. Введення. Зловмисник вводить небезпечний код, наприклад, у текстове поле пошуку на веб-сторінці, посилання, коментар, форму зворотнього зв'язку або параметри пошуку URL та HTML.
2. Відображення. Веб-програма не виконує достатню обробку тексту або екранування введених даних і виводить їх на сторінку без перевірки безпеки.
3. Виконує шкідливий код. Коли інший користувач (жертва) завантажує сторінку, яка містить код, браузер жертви інтерпретує та виконує цей код. Шкідливий скрипт може мати доступ до сесійних cookie, він дозволяє змінювати вміст сторінки, текст, надсилати дані на зовнішній сервер або виконувати інші небезпечні дії від імені жертви.

Види XSS-уразливостей

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

1. Stored XSS (зберігається XSS). Шкідливий скрипт зберігається на сервері і виводиться на сторінку під час її завантаження. Це може статися, наприклад, якщо хакер вводить шкідливий код у поле коментаря або повідомлення на форумі. Під час перегляду сторінки іншими користувачами скрипт виконується у їхніх браузерах.
2. Reflected XSS (відбитий XSS). Будь-який небезпечний скрипт передається на сервер через параметри URL або форми та повертається на сторінку без збереження на сервері. Наприклад, зловмисник може створити фішингове посилання з кодом та відправити його жертві. При переході на посилання скрипт виконується в її браузері.
3. DOM-based XSS (XSS, пов'язані з моделлю об'єктів документа). Шкідливий скрипт маніпулює структурою DOM (Document Object Model) сторінки. На відміну від інших типів XSS, DOM-based XSS не вимагає доступу та надсилання даних на сервер. Хакер, наприклад, може застосовувати неправильно оброблені вхідні дані програми для зміни DOM та виконання небезпечного коду в контексті сторінки.
4. Blind XSS (сліпий XSS). Вразливість, коли хакер може впровадити скрипт на сторінку, але може побачити його безпосереднє виконання. Це може статися, якщо веб-додаток виконує достатню обробку інформації перед відображенням безпеки, але скрипт зберігається і може вплинути на інших користувачів та інстурменти або завдати шкоди системі.
5. XSS через зміну HTML-коду. Шкідливий скрипт впроваджується в HTML-елементи на сторінці, такі як теги , , та інші. Під час завантаження сторінки браузер виконує скрипт.

1. XSS через здійснення JavaScript-подій.Шкідливий код впроваджується в JavaScript-події, такі як onclick, onload, onmouseover і т.д. Коли користувач взаємодіє зі сторінкою та подія спрацьовує, виконується код.

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

Розібратися з кодом та прокачати навички програмування можна на онлайн-курсах. Зібрали найкращі з сайту tutortop:

• «Професія Fullstack-розробник JavaScript» від Mathshub
• «Fullstack-розробник JavaScript» від Нетології
• Курс «Мідл фронтенд-розробник» від Яндекс Практикума
• "Frontend-розробник з нуля до middle" від Нетології
• «Фронтенд-розробник» від Яндекс Практикуму

Приклади міжсайтового скриптингу

Приклад Stored XSS

Припустимо, ми маємо веб-додаток, де користувачі можуть залишати коментарі. Якщо веб-додаток не фільтрує або екранує введені дані, можна просто впровадити наступний коментар:

Коли інші користувачі переглядають сторінку з цим коментарем, скрипт буде виконано у їхніх браузерах.

Приклад Reflected XSS

Припустимо, що у нас є сторінка пошуку, яка приймає пошуковий запит як параметр URL. Якщо веб-додаток не перевіряє або екранує цей параметр, то результат буде такий - противник створює спеціальну URL-адресу з кодом:

http://example.com/search?query=

Коли користувач через пошук знаходить сторінку і переходить по цій URL-адресі, скрипт буде виконаний у його браузері і виведе спливаюче вікно з повідомленням «XSS».

Приклад DOM-based XSS

Припустимо, що веб-додаток динамічно вставляє значення з URL-параметрів до HTML-елементів без належної перевірки. URL з кодом може виглядати так:

http://example.com/page#

Коли користувач завантажує цю сторінку, скрипт буде виконаний у його браузері та виведе спливаюче вікно з повідомленням «XSS».

Всі ці приклади демонструють, як недостатня обробка та екранування введених даних користувача може призвести до успішної XSS-атаки. Для запобігання XSS-уразливостей рекомендується застосовувати відповідні заходи безпеки, такі як фільтрація, правильна діагностика даних, використання заголовків Content Security Policy (CSP) і регулярне тестування на вразливості.

Захист від випадку міжсайтового скриптингу включає правильну фільтрацію даних, використання механізмів захисту, таких як Content Security Policy (CSP), і забезпечення оновлень і патчів для веб-додатків, щоб закрити відомі вразливості.

Як зловмисник запроваджує шкідливий код?

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

1. Введення через форми користувача. Можна вводити вразливий код у текстові поля, поля коментарів, форми зворотного зв'язку або інші інтерактивні елементи на веб-сторінці. Якщо веб-додаток не виконує належну фільтрацію та екранування введених даних користувачів, то результат такий - код буде збережений на сервері і відображений іншим користувачам.
2. Установки URL. Зловмисник може здійснити атаку за допомогою додавання шкідливого коду до параметрів URL, які будуть передані на сервер і повернуті на сторінку. Якщо веб-програма не перевіряє або не екранує ці параметри, код буде виконано у браузері користувача.
3. Шкідливі cookie-файли та скрипти.Зловмисник може завантажити на сервер шкідливі файли, такі як зображення, документи або скрипти, що містять небезпечний код. Потім створити посилання або використовувати теги. , , та інші для виклику цих файлів.
4. Міжсайтові запити (Cross-Site Request Forgery, CSRF) Зловмисник може здійснити атаку на сайт або додаток за допомогою створення спеціально сформованого запиту, який буде виконано від імені авторизованого користувача на веб-додатку. код, який автоматично здійсниться під час завантаження в браузері користувача. несанкціонованих дій від імені користувача.
5. Уразливості в сторонніх бібліотеках або плагінах додатків. вразливості для введення шкідливого коду.

Однак всі ці методи виконання шкідливого коду мають на увазі, що веб-додаток не проводить достатньої фільтрації та валідації даних, що вводяться користувачем. параметризованих запитів, оновлення сторонніх компонентів та ретельне тестування на вразливості.

Наслідки XSS-атаки

XSS-атаки можуть мати різні наслідки для самого користувача, так і власника веб-додатку.

1. Крадіжка та використання сесійних cookie. XSS-атаки можуть бути використані для крадіжки сесійних cookie користувачів. Зловмисник може впровадити скрипт, який перехоплює cookie, які містять дані автентифікації користувача. Потім зловмисник може використовувати ці cookie для підробки сеансу та отримання несанкціонованого доступу до облікового запису користувача.
2. Ухиляння від автентифікації. Зловмисник може використовувати XSS-атаку для обходу механізмів автентифікації. Наприклад, скрипт може підробити форму входу або запит скидання пароля, щоб отримати доступ до облікового запису користувача без необхідності введення правильних облікових даних.
3. Фішинг та перенапрямок. XSS-атаки можуть бути використані для перенаправлення користувачів на фішингові сайти або прості підроблені сторінки, які можуть спробувати зібрати їх прості особисті дані, такі як паролі, номери кредитних карток та іншу чутливу інформацію.
4. Зміна вмісту. Зловмисник може застосовувати XSS-атаку для зміни вмісту веб-сторінки, що відображається користувачам. Наприклад, скрипт може впровадити фальшиві оголошення, прості редиректи або шкідливі посилання, що може призвести до завантаження вірусного програмного забезпечення на комп'ютер користувача. Сторінка може стати небезпечною.
5. Розкриття конфіденційної інформації. XSS-атаки можуть бути використані для розкриття конфіденційної інформації користувачів або власників веб-програми. Наприклад, зловмисник може впровадити скрипт, який перехоплює дані із простої форми введення (такі як номери кредитних карток, адреси електронної пошти тощо) і надсилає їх далі.
6. Репутаційні збитки. XSS-атаки можуть завдати шкоди репутації веб-сайту або власника програми.Якщо користувачі стикаються зі шкідливим вмістом або активністю на веб-сторінці, це може призвести до втрати довіри та клієнтів.

Захист від XSS-атак

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

Для захисту від XSS-атак рекомендується застосовувати такі заходи безпеки та кілька простих способів збереження системи від атак:

1. Фільтрування. Веб-додаток повинен проводити перевірку та фільтрацію всіх даних, що вводяться користувачем перед їх відображенням. Це допоможе запобігти виконанню вірусного коду, використаного користувачем. Використовуйте відповідні функції або необхідні бібліотеки для екранування даних, включаючи HTML- та JavaScript-екранування та інші.
2. Вимкнення виконання скриптів із ненадійних джерел. Встановіть правильні заголовки CSP (Content Security Policy), які визначають потрібні дозволені джерела скриптів, стилів та інших ресурсів на сторінці. Це допоможе запобігти виконання скриптів із зовнішніх джерел та зменшити ризик XSS-атак.
3. Перевірка даних, що вводяться. Інший також важливий спосіб. Проводьте ретельну перевірку та валідацію всіх даних, що вводяться користувачем на стороні сервера. Знайдіть усі некоректні коди. Відхиляйте або очищайте потрібне введення, що містить потенційно небезпечні символи або скрипти. Така перевірка може тривати час.
4. Використання параметризованих запитів. При формуванні запитів до бази або інших джерел використовуйте параметризовані запити або вирази, що готуються, щоб запобігти роботі шкідливого коду через якийсь час.
5. Відновлення сторонніх компонентів. Регулярно оновлюйте всі бібліотеки, фреймворки та потрібні плагіни, що використовуються у веб-додатку. Уразливості XSS можуть бути виправлені у нових версіях компонентів.
6. Навчання та обізнаність користувачів. Навчайте користувачів про потенційні загрози XSS-атак і методи запобігання їх виникненню, наприклад, про акуратне відкриття посилань та незнайомих веб-сайтів.
7. Тестування на вразливості. Регулярно використовуйте цей спосіб та проводьте тестування на вразливості, включаючи тестування XSS-атак. Це дозволить виявити можливі вразливості веб-програми та вжити відповідних заходів щодо потрібного усунення.

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

Підсумки

• XSS (Cross-Site Scripting) - міжсайтовий скриптинг, використання шкідливого коду на веб-сторінку.
• Основна небезпека XSS-уразливостей - можливість доступу зловмисника до даних користувача.
• Види XSS-уразливостей: збережені, відбиті, DOM-модель.
• Способи впровадження небезпечного коду: інтерактивні елементи сайту, помилки у браузері, cookie, підміна кодування у заголовку, SiXSS.
• Наслідки XSS-атак: крадіжка даних користувача, доступ до потрібного управління сайтом.
• Захист від XSS-атак: виявлення простих уразливостей, автоматична перевірка, ручна перевірка, налаштування потрібної фільтрації, використання SSL, діагностика сайту на вразливості, оновлення браузера та використання розширень.
• Неможливо повністю захиститися від XSS-атак та вразливостей, але використання найактуальніших заходів та простих способів знижує ризик до прийнятного мінімуму.

Спеціально для вас ми зібрали окрему добірку найкращих онлайн-курсів з вивчення інформаційної безпеки на ринку та порівняли їх за ціною, тривалістю та відгуками студентів.