Если вы вставляете текстовое содержимое в документ в месте, где ожидается текстовое содержимое 1 , , вам обычно нужно экранировать только те же символы, что и в XML .Внутри элемента это просто включает в себя экранированный объект амперсанд &
и разделитель элементов со знаками меньше и больше <
>
:
& becomes &
< becomes <
> becomes >
Внутри значений атрибутов вы также должныэкранируйте символ кавычки, который вы используете:
" becomes "
' becomes '
В некоторых случаях может быть безопасно пропустить экранирование некоторых из этих символов, но я рекомендую вам избегать всех пяти во всех случаях, чтобы уменьшить вероятность созданияошибка.
Если кодировка вашего документа не поддерживает все символы, которые вы используете, например, если вы пытаетесь использовать эмодзи в документе в кодировке ASCII, вам также необходимо их избежать.Большинство документов в наши дни кодируются с использованием полностью поддерживающей Unicode кодировки UTF-8, где в этом нет необходимости.
В общем, вы не должны выходить из пробелов как
.
- это не обычный пробел, это неразрывный пробел .Вы можете использовать их вместо обычных пробелов, чтобы предотвратить вставку разрыва строки между двумя словами или для вставки лишнего пробела без его автоматического свертывания, но обычно это редкий случай.Не делайте этого, если у вас нет конструктивного ограничения, которое требует его.
1 Под "местом, где ожидается текстовое содержимое", я имею в виду внутри элемента или в кавычкахзначение атрибута, где применяются обычные правила синтаксического анализа.Например: <p>HERE</p>
или <p title="HERE">...</p>
.То, что я написал выше , не применяется к содержимому, которое имеет специальные правила синтаксического анализа или значение, например внутри скрипта или тега стиля, или в качестве имени элемента или атрибута.Например: <NOT-HERE>...</NOT-HERE>
, <script>NOT-HERE</script>
, <style>NOT-HERE</script>
или <p NOT-HERE="...">...</p>
.
В этих условиях правила более сложны, и гораздо проще внедрить уязвимость безопасности. Я настоятельно не рекомендую вам когда-либо вставлять динамический контент в любое из этих мест. Я видел, как команды компетентных разработчиков, обеспечивающих безопасность, вводили уязвимости, предполагая, что они правильно закодировали эти значения, но пропустили крайний случай.Обычно существует более безопасная альтернатива, например, добавление динамического значения в атрибут и последующая обработка его с помощью JavaScript.
Если необходимо, прочитайте Правила предотвращения XSS проекта безопасности Open Web Application Project , чтобыпомогите понять некоторые проблемы, о которых вам нужно помнить.