Будет ли HTML-кодирование предотвращать все виды атак XSS?

Если вы систематически кодировать все входные данные пользователя перед отображением тогда да, вы в безопасности вы все еще не на 100 % безопасным.
(См. сообщение @Avid для получения более подробной информации)

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

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

Это поможет, если вы последуете совету Джоэла Неправильный Код Выглядит Неправильно или ваш язык помогает предупреждая / не компилируя, когда вы выводите необработанные пользовательские данные (статический ввод).

Если вы все так и будет. (в зависимости от вашей платформы и реализации htmlencode), но любое полезное веб-приложение настолько сложно, что легко забыть проверить каждую его часть. Или, может быть, компонент 3rd party небезопасен. Или, может быть, какой-то кодовый путь, который вы хотя и кодировали, не сделал этого, поэтому вы забыли его где-то еще.

таким образом, вы можете проверить вещи на стороне ввода тоже. И вы, возможно, захотите проверить то, что Вы читаете из базы данных.

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

As упомянутые Пэт иногда вы захотите отобразить некоторые теги, но не все теги. Одним из распространенных способов сделать это-использовать язык разметки, как текстильной, уценка или BBCode. Однако даже языки разметки могут быть уязвимы для XSS, просто имейте в виду.

# Markup example
[foo](javascript:alert\('bar'\);)

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

Я второй совет metavida, чтобы найти стороннюю библиотеку для обработки фильтрации вывода. Нейтрализация HTML-символов-хороший подход к остановке атак XSS. Однако код, используемый для преобразования метасимволов, может быть уязвим для атак уклонения, например, если он неправильно обрабатывает Юникод и интернационализацию.

классическая простая ошибка homebrew выходные фильтры сделать, чтобы поймать только , но пропустить такие вещи, как", который может сломать контролируемый пользователем выход в атрибутивное пространство HTML-тега, где Javascript может быть присоединен к DOM.

нет, просто кодирование общих токенов HTML не полностью защищает ваш сайт от атак XSS. См., например, эту уязвимость XSS, обнаруженную в google.com:

http://www.securiteam.com/securitynews/6Z00L0AEUE.html

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

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

Я хотел бы предложить очиститель HTML (http://htmlpurifier.org/) он не просто фильтрует html, он в основном токенизирует и повторно компилирует его. Это действительно промышленная сила.

оно имеет дополнительное преимущество позволять вам обеспечить действительный выход html/xhtml.

также n'thing textile, его отличный инструмент, и я использую его все время, но я бы запустил его, Хотя очиститель html тоже.

Я не думаю, что вы поняли, что я имел в виду жетоны. ФОРМАТ HTML Очиститель не просто "фильтрует", он фактически восстанавливает html. http://htmlpurifier.org/comparison.html

Я так не думаю. Html Encode преобразует все функциональные символы (символы, которые могут быть интерпретированы браузером как код) в ссылки на сущности, которые не могут быть проанализированы браузером и, следовательно, не могут быть выполнены.

<script/>

нет никакого способа, которым вышеуказанное может быть выполнено браузером.

* * если только это не ошибка в браузере, конечно.*