Я использую HTML Purifier для защиты своего приложения от атак XSS. В настоящее время я очищаю контент от редакторов WYSIWYG, потому что это единственное место, где пользователям разрешено использовать разметку XHTML.
Мой вопрос: должен ли я использовать HTML Purifier также по имени пользователя и паролю в системе аутентификации входа (или в поля ввода страницы регистрации, такой как адрес электронной почты, имя, адрес и т.д.)? Есть ли там вероятность атаки XSS?
Вы должны очистить все, что когда-либо будет отображаться на странице. Поскольку при атаках XSS хакеры помещают теги <script> или другие вредоносные теги, которые могут ссылаться на другие сайты.
Пароли и письма должны быть в порядке. Пароли никогда не должны отображаться, а электронные письма должны иметь свой собственный валидатор, чтобы убедиться, что они находятся в правильном формате.
Наконец, всегда помните, что вы добавляете htmlentities() в контент.
Ох.. и посмотри filter_var. Очень хороший способ фильтрации переменных.
Риски XSS существуют там, где когда-либо данные, введенные одним пользователем, могут просматриваться другими пользователями. Даже если эти данные в настоящее время недоступны для просмотра, не предполагайте, что необходимость в этом не возникнет.
Что касается имени пользователя и пароля, вы никогда не должны отображать пароль или даже хранить его в форме, которая может отображаться (т.е. encyrpt с помощью sha1()). Для имен пользователей есть ограничение на юридические символы, такие как [A-Za-z0-9_]. Наконец, как следует из другого ответа, используйте функцию кодирования сущности языка html для любых введенных данных, которые могут содержать зарезервированные или специальные html-символы, что предотвращает появление этих синтаксических ошибок при отображении.
Нет, я бы не использовал HTMLPurifier для имени пользователя и пароля во время аутентификации входа. В моих приложениях я использую буквенно-цифровые имена пользователей и фильтр проверки ввода и показываю их с помощью htmlspecialchars с ENT_QUOTES. Это очень эффективно и чертовски быстрее, чем HTMLpurifier. Я еще не видел атаку XSS с использованием буквенно-цифровой строки. И BTW HTMLPurifier бесполезен при фильтрации буквенно-цифрового контента в любом случае, поэтому, если вы принудительно вводите строку ввода через буквенно-цифровой фильтр, нет смысла отображать его с помощью HTMLpurifier. Когда дело доходит до паролей, они никогда не должны отображаться никому, в первую очередь, что исключает возможность XSS. И если по какой-то извращенной причине вы хотите отображать пароли, то вы должны проектировать свое приложение таким образом, чтобы оно позволяло только владельцу пароля видеть его, иначе вы сильно закручиваетесь, а XSS является наименьшим из ваше беспокойство!
HTML Purifier берет HTML как входной файл и выводит HTML как результат. Его цель - позволить пользователю вводить html с некоторыми тегами, атрибутами и значениями, а также отфильтровывать другие. Это использует белый список для предотвращения любых данных, которые могут содержать скрипты. Поэтому это полезно для чего-то вроде редактора WYSIWYG.
Имена пользователей и пароли, с другой стороны, не являются HTML. Это простой текст, поэтому очиститель HTML не является вариантом. Пытаться использовать HTML Purifier здесь приведет к повреждению данных или разрешению атак XSS.
Например, он позволяет следующее без изменений, что может вызвать проблемы XSS при вставке в качестве значения атрибута в некоторые элементы:
" onclick="javascript:alert()" href="
Или, если кто-то попытался использовать специальные символы в своем пароле и ввел:
<password
то их пароль станет пустым, и сделать его гораздо легче угадать.
Вместо этого вы должны закодировать текст. Необходимая кодировка зависит от контекста, но вы можете использовать htmlentities при выводе этих значений, если придерживаетесь правила # 0 и правила # 1, на Защитный чехол OWASP XSS