Лучший подход - не доверять вводу пользователя в ваш код.Например, никогда не отправляйте пользовательские данные обратно в браузер, не запустив их через htmlspecialchars или аналогичные.Это относится к той же категории, что и атаки с использованием SQL-инъекций, за исключением того, что внедрение направлено на сгенерированный HTML-код, а не на SQL-запрос.
Предоставленные пользователем данные - это все данные, которые могут быть подделаны со стороны клиента.,Сюда входят: $ _POST, $ _GET, загрузка файлов, файлы cookie и заголовки HTTP (например, User-Agent и Referer).Такие данные всегда должны рассматриваться как ненадежные и должны быть защищены для каждого контекста.Собираетесь ли вы вставить данные в базу данных?Избегайте данных, прежде чем вводить их в свой запрос (или использовать подготовленные операторы)!Вы собираетесь вывести его в браузер пользователя?Побег с htmlspecialchars!Это должен быть адрес электронной почты?Убедитесь, что это на самом деле, прежде чем вставлять в сообщение электронной почты!
Обратите внимание, что данные могут быть небезопасными для некоторых контекстов, даже если вы сохраните их в базе данных.Например, данные $ _POST, должным образом экранированные SQL, могут по-прежнему содержать теги HTML или другие данные XSS, поэтому их необходимо экранировать, прежде чем они будут отправлены в браузер (здесь я пытаюсь сказать, что метка user-providedне исчезает только потому, что вы сохраняете данные в базе данных или в файл).Хороший способ защиты от этого - сделать экранирование для каждого контекста как позднее , насколько это возможно (например, htmlspecialchars непосредственно перед тем, как вы просмотрите эхо), чтобы убедиться, что используемый метод экранирования является правильнымодин для этого контекста, но также для выполнения проверки как раннего , насколько это возможно (в первую очередь не принимайте неверные данные, например, проверяйте адреса электронной почты и выдавайте ошибку, еслиэто недопустимо).
Существует также расширение ModSecurity для Apache, которое отлавливает большинство этих атак, но не является надежным, потому что существует почти бесконечные способы создания инъекции.Поэтому ModSecurity следует использовать только тогда, когда вы уже защитили код своего приложения, но боитесь, что вы можете что-то упустить из-за ошибок в будущем (что может случиться с большинством из нас так или иначе).