Какая общая защита от XSS?

Ответ 1

Вы должны сослаться на отличный сайт OWASP для сводки об атаках (включая XSS) и защиты от них. Вот простейшее объяснение, которое я мог бы придумать, что могло бы быть более читаемым, чем их веб-страница (но, вероятно, почти никуда не полна).

• Указание кодировки.. Прежде всего, убедитесь, что ваша веб-страница указывает кодировку UTF-8 в заголовках или в самом начале элемента head HTML кодирует все входы для предотвращения атаки UTF-7 в Internet Explorer (и более старых версиях Firefox), несмотря на другие усилия по предотвращению XSS.

• HTML-экранирование. Имейте в виду, что вам нужно вывести HTML-код из любого пользовательского ввода. Это включает замену < на <, > на >, & с & и " на ". Если вы когда-либо используете однокасканные HTML-атрибуты, вам нужно заменить ' на '. Типичные серверные языки сценариев такие как PHP предоставляют функции для этого, и я рекомендую вам расширить их, создав стандартные функции для вставки элементов HTML а не вставлять их специальным образом.

• Другие типы экранирования.. Тем не менее, вам все равно нужно быть осторожным, чтобы никогда не вводить пользовательский ввод в качестве некотируемого атрибута или атрибута, интерпретируемого как JavaScript (например, onload или onmouseover). Очевидно, что это также относится к элементам script, если входные данные не были надлежащим образом экранированы JavaScript, что отличается от экранирования HTML. Другой особый тип экранирования - это экранирование URL-адресов для параметров URL-адреса (сделать это до того, как HTML-экранирование будет правильно включать параметр в ссылку).

• Проверка URL-адресов и значений CSS. То же самое касается URL-адресов ссылок и изображений (без проверки на основе утвержденных префиксов) из-за схемы URL javascript:, а также URL-адресов стилей CSS и данные в атрибутах style. (Internet Explorer позволяет вставлять выражения JavaScript в качестве значений CSS, а Firefox аналогичным образом проблематичен с поддержкой XBL.) Если вы должны включить значение CSS из ненадежного источника, вы должны безопасно и строго проверить или CSS избежать его.

  /li >

• Не разрешать пользовательский HTML. Не разрешайте HTML-код, предоставленный пользователем, если у вас есть опция. Это простой способ решить проблему с XSS и написать "парсер" для собственного языка разметки на основе простых регулярных выражений. Я бы разрешил форматированный текст только в том случае, если вывод HTML был сгенерирован явно безопасным способом с помощью реального анализатора, который избегает любого текста из ввода с использованием стандартных функций экранирования и индивидуально создает элементы HTML. Если у вас нет выбора по этому вопросу, используйте валидатор/дезинфицирующее средство, например AntiSamy.

• Предотвращение XSS на основе DOM. Не включать ввод пользователя в JavaScript-код HTML и вставьте его в документ. Вместо этого используйте правильные методы DOM, чтобы убедиться, что они обрабатываются как текст, а не HTML.

Очевидно, я не могу охватить каждый случай, когда злоумышленник может вставить код JavaScript. В общем, cookie HTTP-only может использоваться, чтобы сделать атаку XSS немного сложнее (но ни в коем случае не предотвращать ее), а , обеспечивающей обучение программистам.

Ответ 2

Существует два типа атаки XSS. Один из них - это то, где ваш сайт позволяет каким-то образом вводить HTML-код. Это не так сложно защищать: либо избегать всех пользовательских входных данных, либо отбрасывать все теги < > и поддерживать что-то вроде UBB-кода. Примечание. URL-адреса могут по-прежнему открывать вам атаки типа rick-roll.

Более наглядным является то, что на каком-то стороннем сайте есть IFRAME, SCRIPT или IMG-тэг или тому подобное, который попадает на URL-адрес вашего сайта, и этот URL-адрес будет использовать любую аутентификацию, которую пользователь имеет в настоящее время на вашем сайте. Таким образом, вы никогда не должны предпринимать никаких прямых действий в ответ на запрос GET. Если вы получаете запрос GET, который пытается что-либо сделать (обновите профиль, проверьте корзину и т.д.), Вы должны ответить на форму, которая, в свою очередь, требует одобрения POST. Эта форма также должна содержать токен подделки запроса на межсайтовый запрос, так что никто не может размещать форму на стороннем сайте, настроенном для отправки на ваш сайт, используя скрытые поля (опять же, чтобы избежать маскарадной атаки).

Ответ 3

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

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

• перед отображением входных значений пользователя обратно в поля ввода формы, передайте их через htmlspecialchars или htmlentities. Это преобразует все процентные значения xss в символы, которые браузер может отображать, не будучи скомпрометированными.

Как только вы сделали это, вы на 95% безопаснее от атак xss. Затем вы можете продолжить и изучить передовые технологии на сайтах безопасности и применить дополнительную безопасность на своем сайте.

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

Ответ 4

Если вы разрабатываете .NET, одним из наиболее эффективных способов избежать XSS является использование Microsoft AntiXSS Library. Это очень эффективный способ дезинформировать ваш вход.

Ответ 5

В JSTL/JSP лучшим способом защиты от XSS является использование тега c: out без установки параметра escapeXml по умолчанию равным false.

<c:out value="${somePossiblyDangerousVar}"/>