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