Xss атака навчання. XSS уразливість - що це? Приклади XSS уразливостей. Дані із заповнюваних форм
Міжсайтовий скриптинг (XSS) - це вразливість, яка полягає у впровадженні коду, що виконується на стороні клієнта (JavaScript) в веб-сторінку, яку переглядають інші користувачі.
Уразливість виникає через недостатню фільтрації даних, які користувач відправляє для вставки в веб-сторінку. Набагато простіше зрозуміти на конкретному приклад. Згадайте будь-яку гостьову книгу - це програми, які призначені для прийняття даних від користувача і подальшого їх відображення. Уявімо собі, що гостьова книга не відчуває і не фільтрує дані, що вводяться, а просто їх відображає.
Можна накидати свій найпростіший скрипт (Немає нічого простішого, ніж писати погані скрипти на PHP - цим дуже багато займаються). Але вже більш ніж достатньо готових варіантів. Наприклад, я пропоную почати знайомство з Dojo і OWASP Mutillidae II. Там є схожий приклад. В автономній середовищі Dojo перейдіть в браузері за посиланням: http: //localhost/mutillidae/index.php? Page \u003d add-to-your-blog.php
Якщо хтось із користувачів ввів:
Те веб-сторінка відобразить:
Привіт! Подобається твій сайт.
А якщо користувач введе так:
Привіт! Подобається твій сайт.
Те відобразитися це так:
Браузери зберігають безлічі кукіз великої кількості сайтів. Кожен сайт може отримати кукіз тільки збережені їм самим. Наприклад, сайт example.com зберіг в вашому браузері деякі кукіз. Ви заши на сайт another.com, цей сайт (клієнтські та серверні скрипти) не можуть отримати доступ до кукіз, які зберіг сайт example.com.
Якщо сайт example.com вразливий до XSS, то це означає, що ми можемо тим чи іншим способом впровадити в нього код JavaScript, і цей код буде виконуватися від імені сайту example.com! Тобто цей код отримає, наприклад, доступ до кукіз сайту example.com.
Думаю, всі пам'ятають, що виповнюється JavaScript в браузерах користувачів, тобто при наявності XSS, впроваджений шкідливий код отримує доступ до даних користувача, який відкрив сторінку веб-сайту.
Впроваджений код вміє все те, що вміє JavaScript, а саме:
- отримує доступ до кукіз проглядається сайту
- може вносити будь-які зміни у зовнішній вигляд сторінки
- отримує доступ до буферу обміну
- може впроваджувати програми на JavaScript, наприклад, ки-логери (перехоплювачі натиснутих клавіш)
- підчіплювати на BeEF
- та ін.
найпростіший приклад з кукіз:
Насправді, alert використовується тільки для виявлення XSS. Реальна шкідлива корисне навантаження здійснює приховані дії. Вона приховано зв'язується з віддаленим сервером зловмисника і передає на нього вкрадені дані.
види XSS
Найголовніше, що потрібно розуміти про види XSS то, що вони бувають:
- Збережені (Постійні)
- Відбиті (Непостійні)
Приклад постійних:
- Введене зловмисником спеціально сформований повідомлення в гостьову книгу (коментар, повідомлення форуму, профіль) яке зберігається на сервері, завантажується з сервера кожного разу, коли користувачі запитують відображення цієї сторінки.
- Зловмисник отримав доступ до даних сервера, наприклад, через SQL ін'єкцію, і впровадив в видаються користувачеві дані зловмисний JavaScript код (з ки-логери або з BeEF).
Приклад непостійних:
- На сайті присутній пошук, який разом з результатами пошуку показує щось на зразок «Ви шукали: [рядок пошуку]», при цьому дані не фільтруються належним чином. Оскільки така сторінка відображається тільки для того, у кого є посилання на неї, то поки зловмисник не відправить посилання іншим користувачам сайту, атака не спрацює. Замість відправки посилання жертві, можна використовувати розміщення зловмисного скрипта на нейтральному сайті, який відвідує жертва.
Ще виділяють (деякі в якості різновиду непостійних XSS уразливостей, дехто каже, що цей вид може бути і різновидом постійної XSS):
- DOM-моделі
Особливості XSS заснованих на DOM
Якщо сказати зовсім просто, то це шкідлива програма «звичайних» непостійних XSS ми можемо побачити, якщо відкриємо HTML код. Наприклад, посилання сформована подібним чином:
Http://example.com/search.php?q\u003d "/\u003e
А при відкритті вихідного HTML коду ми бачимо щось на зразок такого:
А DOM XSS змінюють DOM структуру, яка формується в браузері на льоту і побачити зі шкідливим кодом ми можемо тільки при перегляді сформувалася DOM структури. HTML при цьому не змінюється. Давайте візьмемо для прикладу такий код:
То в браузері ми побачимо:
Вихідний код сторінки:
Давайте сформуємо адреса наступним чином:
Http: //localhost/tests/XSS/dom_xss.html#input\u003dtokenAlex;
Тепер сторінка виглядає так:
Але давайте заглянемо в вихідний код HTML:
Там абсолютно нічого не змінилося. Про це я і говорив, нам потрібно дивитися DOM структуру документа, щоб виявити це шкідлива програма:
Тут наведено робочий прототип XSS, для реальної атаки нам потрібна більш складна корисне навантаження, яка неможлива через те, що додаток зупиняє читання відразу після крапки з комою, і щось на зразок alert (1); alert (2) вже неможливо. Проте, завдяки unescape () в повертаються даних ми можемо використовувати корисне навантаження на зразок такої:
Http: //localhost/tests/XSS/dom_xss.html#input\u003dtokenAlex;
Де ми замінили символ ; на кодований в URI еквівалент!
Тепер ми можемо написати шкідливу корисне навантаження JavaScript і скласти посилання для відправки жертві, як це робиться для стандартного непостійного міжсайтового скриптинга.
XSS Auditor
В Google Chrome (А також в Opera, яка тепер використовує движок Google Chrome), на мене чекав ось такий сюрприз:
dom_xss.html: 30 The XSS Auditor refused to execute a script in "http: //localhost/tests/XSS/dom_xss.html#input\u003dtoken \u003cscript\u003e alert (1); "Because its source code was found within the request. The auditor was enabled as the server sent neither an" X-XSS-Protection "nor" 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\u003dеё пошуковий запит
2.2 З нормальним пошуковим запитом на зразок слова « собачки»Сторінка просто відображає« собачки , не знайдено »і url http://bobssite.org?q\u003d собачки, Що є цілком нормальною поведінкою.
2.3 Проте, коли в пошук відправляється аномальний пошуковий запит на кшталт :
2.3.1 З'являється повідомлення з попередженням (яке говорить "xss").
2.3.2 Сторінка відображає не знайдено поряд з повідомленням про помилку з текстом "xss".
2.3.3 url, придатний для експлуатації http://bobssite.org?q\u003d
3. Мелорі конструює URL для експлуатації уразливості:
3.1 Вона робить URL http://bobssite.org?q\u003dpuppies
3.2 Вона відправляє e-mail деяким нічого не підозрюють членом сайту Боба, кажучи: «Зацініть кльових собачок».
4. Аліса отримує лист. Вона любить собачок і клацає по посиланню. Вона переходить на сайт Боба в пошук, вона не знаходить нічого, там відображається «собачки, не знайдено», а в самій середині запускається тег зі скриптом (він невидимий на екрані), завантажує та виконує програму Мелорі authstealer.js (спрацьовування XSS атаки). Аліса забуває про це.
5. Програма authstealer.js запускається в браузері Аліси так, ніби-то її джерелом є веб-сайт Боба. Вона захоплює копію куки авторизації Аліси і відправляє на сервер Мелорі, де Мелорі їх витягує.
7. Тепер, коли Мелорі всередині, вона йде в платіжний розділ веб-сайту, дивиться і краде копію номера кредитної карти Аліси. Потім вона йде і змінює пароль, тобто тепер Аліса навіть не може більше зайти.
8. Вона вирішує зробити наступний крок і відправляє сконструйовану подібним чином посилання самому Бобу, і таким чином отримує адміністративні привілеї сайту Боба.
Атака з постійним XSS
- Мелорі має аккаунт на сайті Боба.
- Мелорі зауважує, що веб-сайт бобу містить постійну XSS уразливість. Якщо ви переходите в новий розділ, Розміщуєте коментар, то він відображає що б в нього не надрукували. Але якщо текст коментаря містить HTML теги, ці теги будуть відображені як є, і будь-які теги скриптів запускаються.
- Мелорі читає статтю в розділі Новини та пише коментар в розділі Коментарі. У коментар вона вставляє текст:
- У цій історії мені так сподобалися собачки. Вони такі славні!
Звертайте увагу, в які саме теги HTML коду потрапляє ваш впроваджений код. Ось приклад типового поля введення ( input):
Наша корисне навантаження потрапить туди, де зараз слово «наволочка». Тобто перетворитися в значення тега input. Ми можемо цього уникнути - закриємо прямі подвійні лапки, а потім і сам тег за допомогою "/>
"/>
Давайте спробуємо її для якогось сайту:
Відмінно, вразливість є
Програми для пошуку і сканування XSS уразливості
Напевно, все сканери веб-додатків мають вбудований сканер XSS уразливостей. Ця тема неохватна, краще знайомитися з кожним подібним сканером окремо.
Міжсайтовий скриптинг (скорочено 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\u003d
Існує два типи XSS уразливостей - пасивна та активна.
активна вразливість більш небезпечна, оскільки зловмисникові немає необхідності заманювати жертву по спеціальному посиланню, йому досить впровадити код в базу або який-небудь файл на сервері. Таким чином, всі відвідувачі сайту автоматично стають жертвами. Він може бути інтегрований, наприклад, за допомогою впровадження SQL-коду (SQL Injection). Тому, не варто довіряти даним, що зберігаються в БД, навіть якщо при вставці вони були оброблені.
приклад пасивної уразливості можна подивитися в самому початку статті. Тут вже потрібна соціальна інженерія, наприклад, важливий лист від адміністрації сайту з проханням перевірити налаштування свого облікового запису, після відновлення з бекапа. Відповідно, потрібно знати адресу жертви або просто влаштувати спам-розсилку або розмістити пост на якомусь форумі, та ще й не факт що жертви виявляться наївними і перейдуть по вашому посиланню.
Причому пасивної уразливості можуть бути схильні як POST так і GET-параметри. З POST-параметрами, зрозуміло, доведеться йти на хитрощі. Наприклад, переадресація з сайту зловмисника.