Проверка ввода пользователя?

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

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

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

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

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

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

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

Ваше здоровье!


person PHPLOVER    schedule 03.09.2010    source источник


Ответы (3)


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

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

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

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

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

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

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

person Borealid    schedule 03.09.2010

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

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

person Marc B    schedule 03.09.2010
comment
Вау, спасибо, Марк Б, никогда не знал, что получу такой быстрый ответ. Спасибо за ваш вклад, я собираюсь проверить эту ссылку, но также это все прояснило. К счастью, мой сайт очень маленький, поэтому не беспокойтесь, но, по крайней мере, теперь я могу изменить свой код там, где это необходимо, и делать в основном то, что, как я думал, мне нужно будет делать, как и с вашим подтверждением, теперь я чувствую себя уверенно, что я на пути к обряду :) Очевидно если кто-то еще хочет добавить какие-либо другие предложения, пожалуйста, сделайте. PS. Отличный сайт, жаль, что я не нашел его давным-давно, только что зарегистрировался :) - person PHPLOVER; 03.09.2010
comment
Никогда не рано начать работать над безопасностью и целостностью данных. На самом деле это не так уж и много, но чем раньше вы привыкнете относиться ко всему, что приходит извне, как к токсичным отходам, тем лучше. В качестве дополнительного уровня безопасности вы можете захотеть изучить использование PDO и подготовленных операторов, если только вам не нужно создавать запросы, которые не укладываются в его границы. - person Marc B; 03.09.2010
comment
Спасибо, Марк и все остальные, вы действительно ответили на все мои вопросы и даже больше, я многому научилась, написав этот пост, и сейчас чувствую себя расслабленно, если не сказать больше :) Вы все очень помогли, так что спасибо всем вам. - person PHPLOVER; 04.09.2010
comment
Привет, Марк, просто чтобы вы знали, что я взглянул на очиститель html, и он кажется намного выше моих потребностей, я также попробовал его, но не смог заставить его работать. Я обнаружил, что в документах нет конца, они перескакивают с одного на другое, я понял, как установить, но это все еще не работает, я знаю, что это не будет ошибкой htmlpurifie, но мне кажется, что это OTT, поэтому будет просто использовать htmlentities с ENT_QUOTES при выводе из базы данных. Спасибо PHPLOVER - person PHPLOVER; 04.09.2010
comment
Простой пример очистителя в действии на php здесь: dev.juokaz.com/ php/html-фильтрация-и-xss-защита - person Marc B; 04.09.2010

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

person Skilldrick    schedule 03.09.2010