XSS (Cross-site scripting, Міжсайтовий скриптинг) – це тип вразливостей, котрий зустрічається у web-додатках.
XSS атаки дають змогу зловмисникам впровадити шкідливий скрипт (також називають exploit) на сторінку додатку, в результаті чого у користувачів, котрі відвідують цю сторінку, можуть вкрасти такі дані як: cookie, сесійні токени, логіни з паролями, і просто особисту інформацію.
Впровадити шкідливий скрипт зловмисники можуть різними способами, наприклад, залишити коментар що містить скрипт під постом або товаром в онлайн магазині. І, якщо розробники web-додатку не подбали про валідацію даних, шкідливий скрипт запуститься у всіх користувачів, які відкрили коментарі на сторінці. Такий тип вразливості називається Stored XSS (докладніше про це далі).
Слід додати, що у web-додатках розроблених з використанням сучасних фреймворків (де переважно екрануються дані користувацького вводу), стає все менше можливостей здійснити XSS атаку.
Типи XSS атак
Нижче буде розглянуто три основні типи XSS:
Stored XSS (Збережений/Постійний XSS)
Шкідливий скрипт через користувацький ввід зберігається в БД (базі даних) web-додатку, після чого тим чи іншим способом запускається у клієнта який відвідав сторінку, котру згенеровано на основі даних з тієї самої БД.
Для прикладу уявімо додаток маркетплейс, в котрому розміщуються різноманітні товари, і в кожному товарі є розділ відгуків, де кожен користувач може залишити власний відгук. Якщо розробники не потурбувались про безпеку цього розділу, зловмисник може додати свій відгук з прихованим скриптом (наприклад JavaScript код, що зчитує cookie користувача, після чого відправляє їх на сервер зловмисника). Таким чином, під час перегляду цієї сторінки користувачами, їх дані будуть потрапляти до рук зловмисника.
Така вразливість спрямована на велику кількість користувачів, тому що вона поширюється звичайним способом, а скрипт запускається у всіх хто відвідує уражену сторінку. На відміну від “відображеного” XSS, для поширення якого часто потрібно застосовувати соціальну інженерію.
Reflected XSS (Відображений XSS)
У відображеному XSS реалізація доставки шкідливого скрипту виглядає інакше. Скрипт не повинен зберігатись на серверах додатку, він потрапляє до жертви через посилання. З цього випливає висновок, що кожному окремому користувачу на якого здійснюють атаку, потрібно дати таке посилання особисто, наприклад під час листування (також посилання може бути розміщене на сайті зловмисника, на який у той чи інший спосіб потрапила жертва й натиснула на нього).
Далі за цим посиланням (у якому в query параметрах зашитий скрипт) користувач потрапляє на цільову сторінку, яку сформував сервер (відштовхуючись від змісту посилання та параметрів). При цьому скрипт, який додав зловмисник до параметрів, теж потрапить у сформований HTML і запуститься у жертви. Тут вже зловмисник може переслати собі cookie або інші чутливі дані користувача зібрані зі сторінки.
Звісно, що скрипт не з будь-якого query параметру може потрапити на сторінку і запуститись. Для цього у самому додатку також має бути реалізована робота з цим параметром.
У порівнянні зі Stored XSS, ця вразливість має менше охоплення, оскільки атаці піддається тільки той, хто перейшов за посиланням що містить скрипт. В той час як збереженій XSS атаці, піддається будь-хто після переходу на сторінку де розміщено скрипт. Але і виявити таку вразливість складніше, оскільки це не можна зробити за допомогою статичного аналізу.
DOM-Based XSS (XSS на основі DOM)
Цей тип XSS атак націлений на впровадження скрипту в DOM дерево веб-сторінки, саме під час відпрацювання JavaScript. Наприклад, як і у випадку з Reflected XSS, зловмисник може прокинути шкідливий скрипт через query параметр посилання. Але на відміну від попереднього прикладу, додаток не додає шкідливий скрипт в HTML, і спочатку повертає користувачу сторінку без exploit.
Після того, як клієнт завантажив сторінку та всі необхідні для її роботи файли, у нього запускається JavaScript, котрий для певних цілей може звернутись до document.location, та дістати звідти дані з параметру query (в якому вже лежить шкідливий скрипт), щоб наприклад додати їх на сторінку користувача. В результаті шкідливий скрипт запускається вже маючи доступ до особистих даних користувача.
Враховуючи, що у сучасній веб індустрії багато додатків це SPA (Single Page Application), реалізовані на React, Angular, Vue та інших фреймворках, де більшу частину логіки перенесено на сторону клієнта і сторінки формуються саме на основі роботи JS у браузері, XSS вразливості на основі DOM є одними найбільш поширених.
Слід додати, що таку вразливість можна відстежити на стороні сервера. Якщо записуються логи всіх запитів, в них буде видно, що приходив підозрілий запит зі скриптом у значенні одного з query параметрів.