Согрешить очень легко: Web–приложение принимает от пользователя какие–то данные, например, в виде строки запроса, и, не проверяя их, выводит на страницу. Вот и все! Но входные данные могут оказаться сценарием, написанным, например, на языке JavaScript, и он будет интерпретирован браузером, на котором эта страница просматривается.

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

XSS–атака организована следующим образом:

1) противник находит сайт, в котором есть одна или несколько XSS–ошибок, например в результате эхо–копирования сервером строки запроса;

2) противник подготавливает специальную строку запроса, включающую некоторую HTML–разметку и сценарий, например на языке JavaScript;

3) противник намечает жертву и убеждает ее щелкнуть по ссылке, содержащей злонамеренную строку запроса. Это может быть ссылка на какой–то другой Web–странице или в письме, отформатированном в виде HTML;

4) жертва щелкает по ссылке, и ее браузер отправляет уязвимому серверу GET–запрос, содержащий злонамеренную строку;

5) уязвимый сервер отправляет эту строку назад браузеру жертвы, и браузер исполняет содержащийся в ней сценарий.

Поскольку сценарий исполняется на компьютере жертвы, он может получить доступ к хранящимся на нем кукам, которые относятся к домену уязвимого сервера. Кроме того, сценарий может манипулировать объектной моделью документа (Document Object Model – DOM) и изменить в ней произвольный элемент, например переадресовать все ссылки на порносайты. Теперь, щелкнув по любой ссылке, жертва окажется в некоей точке киберпространства, куда вовсе не собиралась попадать.

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

Опасайтесь таких Web–приложений, как блоги (онлайновые дневники) или страницы обратной связи, поскольку они зачастую принимают от пользователя произвольный HTML–код, а затем выводят его на страницу для всеобщего обозрения. Если приложение написано без учета безопасности, это может стать причиной XSS–атаки. Рассмотрим примеры.Греховное ISAPI–расширение или фильтр на C/C++Ниже приведен фрагмент ISAPI–расширения, которое читает строку запроса, добавляет в начало слово «Hello,» и возвращает результат браузеру. В этом коде есть и другая ошибка с куда более серьезными последствиями, чем XSS–атака. Сможете ли вы ее найти? Взгляните на обращение к функции sprintf(). В ней может произойти переполнение буфера (грех 1). Если результирующая строка окажется длиннее 2048 байтов, то буфер szTemp переполнится.