Только для читателей Lifeexample возможно открыть интернет-магазин на Moguta.CMS со скидкой в 15%

<<< Прием webmoney на сайте || PHP Singleton (Синглтон) >>>

XSS уязвимость и защита от XSS

18.07.2012
XSS уязвимость и защита от XSS

Здравствуйте, уважаемые читатели блога LifeExample, однажды я уже писал статью о SQL инъекциях и о том, как защитить от них сайт, теперь пришло время продолжить тему защиты сайта и раскрыть вам еще один излюбленный хакерами, способ инъекции вредоносного кода.

В данной статье я бы хотел познакомить вас с понятием xss уязвимость, а также с методами защиты сайта от xss атак.

Что такое XSS

XSS – это сокращение понятия расшифровываемое как "межсайтовый скриптинг". В задачи межсайтового скриптинга и главной целью XSS является получение cookies пользователей атакуемого сайта путем встраивания вредоносного кода в тело HTML страницы.

В отличии от SQL инъекции , данный вид атак, с одной стороны безопасен для сервера и опасен для пользователей сайта. С другой стороны если будут украдены cookies админа, то получив доступ к панели администрирования, у хакера будет больше вероятности добраться и до БД.

Для того чтобы межсайтовый скриптинг сработал, хакеру необходимо выявить хотябы одну xss уязвимость.

Как защититься от xss

Если ваш сайт подвергается XSS атаке, вероятнее всего вы об этом узнаете не скоро, а может, и вовсе не узнаете. Поэтому для защиты от xss атак, нужно предотвращать все подобные попытки, хакеров, на корню.

Чтобы придумать метод защиты от какой либо атаки, нужно знать как эти атаки проводятся и по какому принципу работают, поэтому давайте разбираться с теорией взлома через xss уязвимости.

Как найти xss уязвимость на сайте

Процесс поиска уязвимых мест очень прост и сводится к банальному отбору страниц с формами ввода. После того как вы нашли все страницы с которых пользователи отправляют информацию на сервер, можно начинать выявление xss уязвимости.

Допустим, найденная нами форма ввода является поиском по сайту. Определить является ли эта форма xss уязвимой, можно несколькими способами, подставив в поле одну из следующих инъекций:

  • <script>alert("cookie: "+document.cookie)</script>
  • "><script>alert("cookie: "+document.cookie)</script>
  • ‘><''>"><script>alert("cookie: "+document.cookie)</script>

Если в результате вы увидели нечто подобное:

Проверка на xss уязвимость

Значит вы нашли xss уязвимость, и в дальнейшем нужно будет ее защитить от атак.

Если ни один из вариантов не сработал, попробуйте вставить следующие подборки кода:

  • <body onload=alert(‘xss Уязвимость’)>
  • <img src=javascript:alert(‘Защита от XSS не работает’)>
  • <body background="javascript:alert(‘эй админ закрой xss уязвимости’)" >
  • <style type="text/javascript">alert(‘Бум бум!’);</style>

Опять ничего не вышло? Тогда можете считать, что данная форма не уязвима к XSS атакам и уже защищена.

Кстати тестировать сайт на уязвимости для XSS , лучше в IE, поэтому если ранее вы подставляли вышеперечисленные действия в другом браузере попробуйте сделать тоже самое теперь в Interner Explorer.

Запомните все найденые XSS уязвимости, и не спешите завершать этап поиска слабых мест.

Кроме форм и полей ввода, XSS уязвимыми могут быть страницы обрабатывающие GET параметры.

Например, страница такого типа http://yourdomain.ru/catalog?p=3 Может оказаться большой дырой в защите сайта.

Подобно действиям проделанным ранее в поле ввода, попробуте подставить в параметр вышеперечисленные строки кода.

http://yourdomain.ru/catalog?p="><script>alert("cookie: "+document.cookie)

Вполне вероятно что вы вновь получите сообщение

Защита от xss

Выводящее на показ идентификатор сессии пользователя.

Защита от XSS атак

Теперь вы имеете представление о том как проводятся XSS инъекции , и конечно же понимаете что вместо вывода сообщения, информация будет уходить в руки злоумышленника.

Внимание: кульминационный момент!

Для того чтобы защититься от XSS атак и устранить все возможные XSS уязвимости вашего сайта, достаточно перед работой с входными данными пропустить их через фильтр и заменить все опасные спец символы безопасными:

1
2
$filter = array("<", ">");
$_GET['q']=str_replace ($filter, "|", $_GET['q']);

Этих двух маленьких строчек кода достаточно для избежание больших проблем. Теперь если попытаться внедрить инъекцию через адресную строку или форму ввода

http://yourdomain.ru/searh?q=»><script>alert(«cookie: «+document.cookie)</script>

Никаких сообщений мы больше не увидим, поскольку все скобки в переменной $_GET[‘q’] будут заменены на безопасные символы «|», и JS код станет невыполнимым.

В этом примере показан способ защиты только одной переменной, на практике необходимо будет пропускать через подобный фильтр все входные параметры на всех страницах с XSS уязвимостями.

Для массовой проверки входящих данных, методами POST и GET можно использовать такую функцию:

1
2
3
4
5
6
7
8
9
function defender_xss($arr){
    $filter = array("<", ">"); 
     foreach($arr as $num=>$xss){
        $arr[$num]=str_replace ($filter, "|", $xss);
     }
       return $arr;
}
//используйте  функцию перед обработкой входящих данных:
$_REQUEST=defender_xss($_REQUEST);

Кроме того будет не лишним дополнить фильтр другими символами для фильтрации:

1
$filter = array("<", ">","="," (",")",";","/");

Альтернативным способом защиты будет использование штатных PHP функций:

  • strip_tags() — удаляет из строки все HTML-теги, кроме разрешённых.
  • htmlspecialchars() — заменяет все спецсимволы на их HTML-аналоги.

Будьте аккуратны, strip_tags() можно обойти, используя инъекции подобного рода:

1
2
3
4
5
<body onload=alert('xss')>
<img src=javascript:alert('xss')>
<body background="javascript:alert('xss')" >
<meta http-equiv="refresh" content="0;url=javascript:alert('xss');">
<style type="text/javascript">alert('xss');</style>

Каким образом воруются cookie пользователей?

Не всем сразу может быть ясно, как происходит процесс получения cookie пользователей.

Все дело в том, что после выявления XSS уязвимостей, хакер создает ссылку с вредоносным кодом. В этом коде данные из куков передаются на сторонний сервер, на котором обрабатываются и сохраняются, затем пользователь перенаправляется на страницу обратно. Все это происходит незаметно для человеческого глаза, и поэтому атака остается необнаруженной.

Зараженные ссылки несущие в себе XSS атаки, попадают пользователям разнообразными способами, путем передачи ссылок в соц сетях , атах форумах и др местах скопления юзеров.

Атаки построенные по принципу межсайтингового скриптинга делятся на два типа:

  • Активные XSS атаки – подразумевают внедрение ссылки в саму страницу ресурса, сделать это можно путем вставки вредоносного кода в запись БД, или загрузив картинку на сайт указав в ней ссылку с вредоносным кодом.
  • Пассивные XSS атаки – пользователь сам должен вставить ссылку в адресную строку или просто кликнуть по ней.

Конечно ссылки предоставляемы хакерами, не выглядят таким образом:

http://yourdomain.ru/searh?q=»><script>alert(«cookie: «+document.cookie)</script>

Существует множество способов закодировать содержание ссылки, таким образом скрыв смысл от жертвы. Кодировать можно в base64, hex, или использовать сторонний сервер для маршрутизации.

  • http://hakerserver.com/82qdm6k
  • data:text/html;base64,aHR0cDovL2luZm9zZXJ2aWNlNjozMDAwL2luZm8vc2VhcmNoLmh0bWw/cT0iPjxzY3JpcHQ+YWxlcnQoJycpPC9zY3JpcHQ+
  • http://infoservice6:3000/info/search.html?q=%22%3E%3Cscript%3Ealert(»)%3C%2Fscript%3E

Согласитесь теперь сложно догадаться о том, что внутри ссылки зашифрован зловредный код. А если снабдиться ссылку красивыми вешанием лапши на уши пользователям и рассказать какая полезна эта ссылка то единицы не перейдут по ней. Но это уже из области социальной инженерии…

В дополнение к вышеприведенному способу защиты, можно использовать и защиту от XSS на сервере, прописав в .htaccess такой код:

1
2
3
4
5
6
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%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 уязвимости на своем сайте, создали фильтр не допускающий внедрения XSS инъекций, и защитились от XSS атак.

Чтобы не пропустить публикацию следующей статьи подписывайтесь на рассылку по E-mail или RSS ленту блога.

Нравится

Комментарии

  • Дмитрий

    Спасибо. Вполне доходчиво. Как раз с этой проблемой парюсь.
    Заходи и на мой блог, вдруг найдешь и для себя что-нибудь полезное.

  • Верю

    А .htaccess с такими записями где разместить лучше?

    • В корне сайта, но надо хорошо понимать его смысл и при необходимости подправить под движок сайта. Если просто скопировать, то скорее всего сайт просто сломается.

  • Серега

    чета php не срабатывает. Все равно из адресной строки работает js

  • frrfr

    alert(«cookie: «+document.cookie)
    тест 🙂

  • sina

    Спасибо, очень интересная и нужная статья. Занесу адрес сайта в закладки. Подписался бы на рассылку новостей (не RSS), но не вижу ссылки.

    • Даже не знаю куда еще виднее ее поместить))) В сайдбаре прямо под RSS есть поле для ввода email и кнопка подписаться.

    • Евгений

      Действительно хреново видно. если б не сказал не нашел бы. кнопочку повыразительнее надо

    • Куда уж еще виднее? ))

  • Вадим

    А можете расшифровать все эти команды, чтобы понять как изменить все это для своего сайта?

    1
    2
    3
    4
    5
    6
    Options +FollowSymLinks
     RewriteEngine On
     RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%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]
  • TomAlko

    QUERY_STRING — запрос
    (\|%3E) — чё смотрим
    [NC,OR] — правело
    RewriteRule ^(.*)$ index.php [F,L] замена индекса чтения
    Так будет понятно

  • Оставить комментарий

    Подписаться на комментарии к этой статье по RSS

    Яндекс.Метрика