Для тих, хто є досвідченим користувачем інтернету, напевно, вже доводилося чути про XSS уразливість на сайті, до чого це може призвести. Якщо ж ні, то давайте спробуємо трохи внести ясність у це питання. XSS — одна з різновидів атак на сайт, а якщо бути точним на користувачів сайту. XSS-уразливість може бути використана по-різному, від дрібного хуліганства, до доступу до облікового запису користувача. Наслідки при цьому вже залежать від ситуації.
Так що ж таке XSS?
XSS – міжсайтовий скриптінг, за допомогою якого можна виконувати код на стороні клієнта, а це значить мати можливість отримати cookies користувачів, публікувати їх особи повідомлення, ну або що-небудь ще, що вбредет в голову. Суть в тому, що через вразливе місце на сайті впроваджується певний код, який підвантажується у інших користувачів у браузері. При цьому зловмисник може елементарно висмикнути cookies з браузера, і відправити їх на свій сервер-накопичувач, після чого ви ризикуєте втратити свій аккаунт. XSS — штука досить гнучка, і може бути використана по-всякому, на формі, де вводяться дані, у разі якщо зловмисникові вдалося впровадити шкідливий код, ці дані можуть бути скомпрометовані. А тепер задумайтеся, які це можуть бути дані. Думаю, у вас в загальних рисах з’явилося уявлення про те, що це взагалі, тепер давайте розглянемо, що можна зробити.
Що ж можна зробити?
Якщо ви власник сайту, то природно є бажання що-небудь зробити, і це гарне бажання. Потрапити шкідливий код на сайт може по-всякому. У більшості випадком це поля введення даних на формі, які відправляються на сервер, після чого показуються іншим користувачам. Знайти поля введення на сайті думаю, вам не складе праці. Після цього, спробуйте ввести наступні рядки, наведені нижче.
alert(“cookie: “+document.cookie)
“>alert(“cookie: “+document.cookie)
‘>”>alert(“cookie: “+document.cookie)
Надішліть форму, і якщо є уразливість в тому місці, де показуються дані, з’явиться вікно щось на зразок цього:
Особливість XSS в тому, що атака проводиться не на базу даних, а на клієнтську частину. Таким чином, сама база даних може виявитися зберігачем шкідливого коду. Виявити шкідливий код в базі куди складніше, т. к. кордон етапу перевірки даних з полів форми вже пройдено, і по-хорошому їх потрібно перевіряти перед записом в базу.
Фільтрація XSS
Щоб убезпечити дані від XSS ін’єкції, доцільно екранувати все спец. символи, які можуть бути використані для впровадження коду. Якщо ви використовуєте PHP, то там є спеціальні функції, які досить непогано справляються з цим завданням. Одна з них це htmlspecialchars(), вона краща.
Друга – strip_tags(), але її використовувати не рекомендується, оскільки є способи оформлення коду, які дозволять впровадити код навіть через функцію, ось приклад:
alert(‘xss’);
Так само, якщо ви використовуєте в якості веб-сервера Apache, то у файлі .htaccess ви можете прописати наступні правила:
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{QUERY_STRING} (\|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
RewriteRule ^(.*)$ index.php [F,L]
Насправді наявність XSS уразливості — проблема більш серйозна, ніж здається, і отримала розвиток в цьому напрямку, з більш хитрощами методами атаки. У зв’язку з цим, побудова атаки, засновані на XSS можна розділити активні і пасивні XSS атаки. Активні – ті, що впроваджуються в код сторінки атакується сайту, пасивні – це може бути посилання, по якому потрібно клікнути, або вставити посилання в адресний рядок браузера, далі справа техніки. При цьому, посилання може бути закодована, і не завжди зрозуміла людському оку.
Додав: htmaker, 01.03.2017 р.
(Ще не оцінили)
Завантаження…
Діліться з друзями:
См. також:
Небезпека використання атрибуту target=”_blank”
Рубрика: Html, CSS, Javascript, Інф. безпека
Налаштування SELinux, включення, відключення
Рубрика: Linux, Інф. безпека
Не працює вебвізор, що робити?
Рубрика: Nginx, Інструменти, Деталі. безпека
Блокування ботів в Nginx
Рубрика: Nginx, Інф. безпека
HTTP авторизація
Рубрика: Apache, Інф. безпека
