лучший способ предотвращения атаки xss

какой из двух является лучшим способом предотвращения атаки xss.

1. HTMLEntities при сохранении в db
2. HTMLEntities при отображении / эхом

2 – вы должны преобразовать в целевой формат в последний момент. Это избавит вас от проблем в будущем, если вы, например, решите, что хотите использовать один и тот же контент в электронном письме, в формате PDF, в качестве текста для пользователя для редактирования и т. Д. И т. Д.

я нахожу первый лучше, потому что вы можете забыть добавить это при показе

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

Кроме того, не все данные поступают в базу данных. например, предварительный просмотр данных, подлежащих вставке, или данных, возвращаемых в форму из-за ошибок, являются одновременно возможными векторами XSS. Вы не хотите иметь дело с такими вещами, как «Кодирование перед вводом в базу данных или повторное отражение в документе, если оно не было из базы данных». Исключения – лучший способ попасть в ситуацию, когда вы забудете кодировать.

Лучший способ (вариант № 3 ..), если вы спросите меня, использует последнее расширение фильтра для обработки фильтрации для вас (PHP5). Мне нравится ставить filter_input_array в верхней части моего php-файла, чтобы защитить себя, например, от POST XSS-атак

 $_POST = filter_input_array(INPUT_POST, FILTER_SANITIZE_STRING); 

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

Причины кодирования в коде дисплея (т. Е. После чтения текста из базы данных):

• База данных может быть просмотрена в графическом интерфейсе, отличном от HTML, который требует изменения. Модификация инструментов администрирования баз данных общего назначения для автоматического декодирования конкретного текста (в котором кодировка?) Для одного приложения не является ни осуществимой, ни желательной.
• Неправильное кодирование HTML означает, что вам нужно доверять базе данных, чтобы быть в безопасности. Если есть какая-либо уязвимость – непосредственно в базе данных или в другом веб-приложении, ваше приложение также станет уязвимым.
• Хранение закодированного HTML в базе данных предотвращает поиск; вы не можете напрямую использовать специальные библиотеки поиска, такие как Lucene. Кроме того, поскольку html-кодирование не может быть биективным, полнотекстовый поиск должен либо работать с декодированной копией базы данных, либо декодировать все записи в базе данных, что приводит к производительности O (размер базы данных).
• Будущие преобразования кодирования также легче, если весь код кодирования сконцентрирован в отображаемом коде.
• Кодировка увеличивает занимаемое пространство для хранения

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

Лучше всего было бы strip_tags() и htmlentities() перед сохранением в db (если вы не против некоторых дополнительных бит данных).

Однако убедитесь, что вы также приняли другие меры предосторожности, чтобы защитить от SQL-инъекции, используя mysql_real_escape_string() или подготовленный уровень абстракции доступа к данным, например PDO.