Где лучшее место для дезинфекции пользовательского ввода, который будет выводиться на веб-странице?

Question

В способе работы MVC, где лучше всего запускать, например, htmlspecialchars() на любом входе? Должно ли это произойти в представлении (это имеет смысл делать здесь, так как я должен иметь дело с необработанным вводом в контроллере и модели?)

Я не совсем уверен ... Каковы преимущества этого в представлении или контроллере? Это просто относится к выводу на страницу ... чтобы минимизировать потенциальные эксплойты XSS.

Answer 1

Ну, это зависит, не так ли? Вы должны санировать все, что вы ВЫХОДИТЕ в поле зрения. Во-первых, потому что санация зависит от формата вашего вывода. Обеззараженный вывод в формате JSON отличается от отработанного вывода в формате HTML, верно? Во-вторых, потому что вы никогда не хотите доверять имеющимся у вас данным. Это могло быть скомпрометировано любым количеством способов.

Это не защитит от SQL-инъекций и тому подобного. Теперь вы никогда не захотите делать это в JavaScript на стороне клиента, потому что злоумышленник может легко заменить это. Опять же, мой совет - дезинфекция в месте использования. Если вы просто пишете в файл, это может не понадобиться. И некоторым библиотекам доступа к базе данных это тоже не нужно. Другие делают.

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

Answer 2

Вот почему мышление в шаблонах дизайна - отстой. То, что вы должны спросить, - это где эффективное место для этого? Если данные записываются один раз / много раз, то их очистка каждый раз, когда они выводятся (при просмотре страницы), приведет к ненужной нагрузке на сервер. Принимайте решение, основываясь на том, как будут использоваться данные, где вы можете настроить кэширование, как выполнять поиск и т. Д., А не на основе шаблона.

Из того, что вы сказали, я проведу санитарию прямо перед записью в БД. Тогда вы не только гарантируете безопасность данных для вставки, но и гарантируете, что никакие будущие ошибки не могут привести к отправке неанифицированных данных. Если по какой-то причине вам нужен оригинальный текст, просто инвертируйте исходное преобразование.

Вам не следует беспокоиться о хранении HTML-кодированного текста в вашей БД, поскольку ВСЕ текст кодируется в той или иной форме. Если вам нужно найти текст, вы просто закодируете строку поиска. Если вам нужен другой формат, тогда это другая история, но тогда вам придется оценивать ваши варианты на основе ваших потребностей.

Answer 3

Я думаю, что лучший способ - это выйти из режима просмотра и вывода и сохранить все в оригинале в вашей базе данных.

Почему? С помощью этого метода вы можете использовать записи БД для каждого варианта использования.

Answer 4

Зависит от типа пользовательского ввода и от того, какую проверку вы используете.

Если вы хотите очистить ввод, я бы поместил логику в контроллер, а также в представлении, когда вы выводите данные, которые поступают из базы данных (или любого другого источника).

Если вы проводите проверку данных, я бы сделал это как на стороне клиента с помощью javascript, так и в модели.

Answer 5

Я собираюсь уловить ответную тенденцию здесь и дать этот совет:

Ненадежный ввод должен быть ограничен настолько жестко, насколько это возможно - сокращая количество мест, с которыми вы взаимодействуете, до того, как его безопасность была оценена, вы уменьшаете подверженность угрозам, когда кто-то, кто думает об исправлении ошибки или улучшении функциональности, а не безопасность меняет обсуждаемую систему.

Answer 6

Я поместил его в «контроллер», как его определяет большинство современных фреймворков. (Не вдаваясь в дискуссию о том, насколько это чисто) Это не то, что принадлежит непосредственно шаблону представления, но это также не обязательно должно быть в модели, так как иногда вам могут потребоваться исходные данные, а не другие.

Поэтому, когда я загружаю данные из модели в контроллер и назначаю их представлению (в моем случае, шаблону smarty), я сначала запускаю его через Очиститель HTML .

Answer 7

Общее правило: толстая модель, тонкий контроллер.

Теперь, как вы применяете это правило, это другая история:)

По моему мнению, ваш контроллер должен просто контролировать поток, перенаправлять на страницы и т. Д. Любая проверка должна выполняться в вашей модели. Если вы хотите выполнить проверку на стороне клиента, вы, вероятно, поместите ее в представление. Любой разработчик, обеспокоенный безопасностью, может выполнить проверку на клиенте и на сервере.

Answer 8

У меня нет «лучшего» места для дезинфекции. В зависимости от варианта использования нам может потребоваться реализовать дезинфицирующую логику в нескольких уровнях.

Answer 9

Вы можете сделать это в представлении (посредством проверки javascript), но данные, поступающие из визуализированного представления в контроллер, все еще считаются ненадежными, поэтому вам все равно придется очистить их в контроллере.

В примерах, которые я видел (например, nerddinner ), код очистки является частью классов модели. Некоторые люди используют проверочные библиотеки .