Я очень смущен чем-то и задавался вопросом, может ли кто-нибудь объяснить.
В PHP я проверяю ввод пользователя так, что htmlentitiies, mysql_real_escape_string используется перед вставкой в базу данных, а не во все, так как я предпочитаю использовать регулярные выражения, когда могу, хотя мне трудно работать. Теперь, очевидно, я буду использовать mysql_real_escape_string по мере того, как данные будут поступать в базу данных, но не обязательно следует использовать htmlentities () только при получении данных из базы данных и их отображении на веб-странице, поскольку это делает так, что рука изменяет данные, введенные человеком, который не сохраняет его оригинальную форму, которая может вызвать проблемы, если я захочу использовать эти данные позже для использования для чего-то еще.
Так, например, у меня есть гостевая книга с тремя именами полей, темой и сообщением. Теперь очевидно, что поля могут содержать что-то вроде вредоносного кода в js-тегах, в основном, что-то, теперь меня путает, скажем, я злонамеренный человек, и я решил использовать теги js и некоторый malicous js-код и отправить форму, теперь в основном у меня есть злонамеренные бесполезные данные в моей базе данных. Теперь, используя htmlentities при выводе вредоносного кода на веб-страницу (гостевую книгу), это не проблема, потому что htmlentities превратила его в безопасный эквивалент, но в то же время у меня есть бесполезный вредоносный код в базе данных, который я бы предпочел не иметь.
Поэтому, сказав все это, мой вопрос заключается в том, должен ли я принять тот факт, что некоторые данные в базе данных могут быть злонамеренными, бесполезными данными и до тех пор, пока я использую htmlentities на выходе, все будет в порядке или я должен делать что-то еще ».
Я читал так много книг, рассказывающих об фильтрации данных при их получении и ускорении при его выводе, поэтому исходная форма хранится, но они только дают примеры, такие как обеспечение поля – это только int, использующий функции, уже встроенные в php и т. Д., Но я так и не нашел что-нибудь в плане обеспечения чего-то вроде гостевой книги, где вы хотите, чтобы пользователи вводили все, что захотят, а также как вы могли бы фильтровать такие данные, кроме mysql_real_escape_string (), чтобы гарантировать, что он не нарушит запрос БД?
Может кто-нибудь, пожалуйста, наконец, закроет эту путаницу для меня и скажет мне, что я должен делать и что лучше?
Спасибо всем, кто может объяснить.
Ура!
Это длинный вопрос, но я думаю, что вы на самом деле спрашиваете:
«Должен ли я избегать HTML, прежде чем вставлять его в свою базу данных или когда я его покажу?»
Общепринятый ответ на этот вопрос заключается в том, что вам следует избегать HTML (через htmlspecialchars ), когда вы отправляете его пользователю, а не перед его помещением в базу данных.
Причина в том, что база данных хранит данные. То, что вы вкладываете в это, – это то, что пользователь набрал. Когда вы вызываете mysql_real_escape_string , он не изменяет то, что вставляется в базу данных; он просто избегает интерпретации ввода пользователя в качестве операторов SQL. htmlspecialchars делает то же самое для HTML; когда вы печатаете вход пользователя, это позволит избежать интерпретации его как HTML. Если вы должны были вызвать htmlspecialchars перед вставкой, вы перестали быть верными.
Вы всегда должны стремиться к представлению о максимальной точности, которое вы можете получить. Так как сохранение «вредоносного» кода в вашей базе данных не наносит вреда (на самом деле это экономит вам некоторое пространство, поскольку экранированный HTML длиннее, чем неизолированный!), И вы можете в будущем захотеть этого HTML (что, если вы используете синтаксический анализатор XML по комментариям пользователей, или когда-нибудь пусть доверенные пользователи имеют подмножество HTML в своих комментариях или некоторые такие?), почему бы не позволить?
Вы также немного спрашиваете о других типах проверки ввода (целые ограничения и т. Д.). Ваша схема базы данных должна обеспечивать их соблюдение, и их также можно проверить на уровне приложения (желательно на входе через JS, а затем снова на стороне сервера).
В другой заметке, лучший способ выполнить mysql_real_escape_string базы данных с помощью PHP, вероятно, использовать PDO, а не напрямую обращаться к mysql_real_escape_string . PDO имеет более расширенные функциональные возможности, включая проверку типов.
mysql_real_escape_string() – это все, что вам нужно для операций с базой данных. Это гарантирует, что злоумышленник не сможет внедрить что-то в данные, которые «сломают» ваши запросы.
htmlentities() и htmlspecialchars() вступают в игру, когда вы работаете с отправкой материала клиенту / браузеру. Если вы хотите очистить потенциально враждебный HTML, вам будет лучше использовать HTMLPurifier , который будет линять данные на скале и выложить ее с помощью отбеливателя и восстановить его должным образом.
Нет причин беспокоиться о том, что в базе данных есть вредоносный код JavaScript, если вы избегаете HTML, когда он выходит. Просто убедитесь, что вы всегда избегаете всего, что выходит из БД.