💡Сама ідея вразливості дуже проста: це всього-навсього виконання чужого JavaScript коду на веб сторінці.
🪲 Оскільки в JS немає жодних рівнів привілегій, то, фактично, код виконується від імені сторінки з усіма її можливостями і зловмисник може творити що завгодно, від логування всіх дій користувача до передачі відео з камери куди треба. Як ви розумієте, сценаріїв експлуатації безліч тому XSS вважається досить небезпечною вразливістю.
❗️Виникає XSS тоді, коли ви виводити на сторінку дані від користувача або з інших систем як є, без їх "знешкодження", або з не повним знешкодженням.
До прикладу уявіть собі форум пасічників на якому ви пишете наступний пост:
Бджоли рулять!!!✍️ Якщо виводити цей контент як є (доприкладу через
<script>alert('ТАК!');</script>
.innerHTML=), станеться наступне: текст з'явиться як текст, а от script секція буде додана саме як script. Браузер цей скрипт виконає і користувач побачить вікошко з текстом десь з 2004 року.Звичайно всі адекватні фреймоврки про цю проблему знають і біль-менш успішно її успішно її вирішують. Але є три моменти
1️⃣ По-перше, не завжди ми використовуємо фреймворки взагалі, іноді в проді лежать самописки або якісь екзоти. Та й element.innerHTML = USER_INPUT_PLEASE_NO ніхто не відміняв, навіть в тому ж React. (не робіть так)
2️⃣ По-друге, фреймворки не святі. В React-і була проблема з серіалізованим стейтом сторінки під час server-side-rendering. Особливо не пояснюю, бо проблема давно вирішена, але це чудова ілюстрація того, що навіть стабільні фреймворки бувають вразливі.
3️⃣ По-третє, всі фреймворки мають спосіб як обійти санітанізацію (тобто знешкодження) контенту, тому що це буває потрібно. Уявіть собі що вам потрібно рендерити якийсь HTML з бази даних або з іншого сервісу. Ось тут без обходу знешкодження ніяк. І якщо ви зробите її некоректно, або хтось отримає доступ до джерела цієї розмітки - ви в повній дупі і цей вираз навіть на половину не передає рівень ваших проблем.
❓А от як з цим боротися - наступному пості.
@reactbeginners