Подтверждение ввода пользователя?

Question

Я очень смущен из-за чего-то, и мне было интересно, может кто-нибудь объяснить.

В PHP я проверяю пользовательский ввод, поэтому htmlentitiies, mysql_real_escape_string используется перед вставкой в ​​базу данных, а не на все, поскольку я предпочитаю использовать обычныевыражения, когда я могу, хотя мне трудно с ними работать.Теперь, очевидно, я буду использовать mysql_real_escape_string, когда данные поступают в базу данных, но не уверен, что я должен использовать htmlentities () только при получении данных из базы данных и отображении их на веб-странице, как это делается до того, как рука изменяет данные, введенные человеком, которыйне сохраняет свою первоначальную форму, которая может вызвать проблемы, если я захочу позже использовать эти данные для использования для чего-то другого.

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

Итак, после всего сказанного, мой вопрос: должен ли я принять тот факт, что некоторые данные в базе данных могут быть вредоносными, бесполезными данными и до тех пор, пока я использую htmlentities на выходе, все будет хорошо, или я должен делать что-то еще?aswell?.

Я прочитал так много книг, в которых говорится о фильтрации данных при их получении и экранировании их при выводе, чтобы сохранить исходную форму, но в них приводятся только примеры, например, обеспечение того, что поле является только целым с использованием уже используемых функций.встроенный в php и т. д., но я никогда не находил ничего в отношении обеспечения чего-то вроде гостевой книги, где вы хотите, чтобы пользователи печатали все, что они хотят, а также того, как вы будете фильтровать такие данные помимо mysql_real_escape_string (), чтобы гарантировать, что это не делаетне может разбить запрос к БД?

Может, кто-нибудь, наконец, закроет эту путаницу для меня и скажет мне, что я должен делать и каков наилучший метод?

Спасибо всем, кто может объяснить.

Ура!

Answer 1

Это длинный вопрос, но я думаю, что то, что вы на самом деле спрашиваете, сводится к:

«Должен ли я экранировать HTML-код перед его вставкой в ​​базу данных или при переходе к его отображению?»

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

Причина в следующем: база данных хранит данные. То, что вы вкладываете в него, - это то, что набрал пользователь. Когда вы вызываете mysql_real_escape_string, это не изменяет то, что вставлено в базу данных; он просто избегает интерпретации ввода пользователя как операторов SQL. htmlspecialchars делает то же самое для HTML; когда вы печатаете ввод пользователя, он не будет интерпретироваться как HTML. Если вам нужно было позвонить htmlspecialchars до вставки, вы больше не будете верны.

Вы всегда должны стремиться получить максимально точное представление, которое вы можете получить. Поскольку хранение «вредоносного» кода в вашей базе данных не причиняет вреда (на самом деле, оно экономит ваше пространство, поскольку экранированный HTML длиннее, чем неэкранированный!), И в будущем вы можете хотеть этот HTML (что если вы используете анализатор XML для комментариев пользователей или когда-нибудь разрешите доверенным пользователям иметь подмножество HTML в своих комментариях или что-то подобное?), почему бы не позволить этому быть?

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

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

Answer 2

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

htmlentities() и htmlspecialchars() вступают в игру, когда вы работаете с отправкой материала клиенту / браузеру. Если вы хотите очистить потенциально враждебный HTML-код, вам лучше использовать HTMLPurifier , который разделит данные на основу, скомбинирует их с отбеливателем и правильно восстановит.

Answer 3

Нет причин беспокоиться о наличии вредоносного кода JavaScript в базе данных, если вы выходите из HTML при его выходе.Просто убедитесь, что вы всегда избегаете всего, что выходит из БД.