PHP Lang
  1. PHP Lang
  3. Когда нужно санировать код PHP и MySQL, прежде чем хранить его в базе данных или когда он отображается?
Intereting Posts
Защищенный паролем каталог и файлы в PHP GET данные json из файла php для угловой области как использовать imagik annotateImage для китайского текста? Допустимый размер памяти 134217728 байт исчерпан (пытался выделить 4294967296 байт) Создать zip с PHP, добавляющим файлы с url пользовательский файл php.ini в подпапке, вызывающий проблемы с переменными $ _SESSIONS Как обновить данные в базе данных SQL Вывод буфера вывода командной строки PHP независимо от настроек буфера Когда do / следует использовать __construct (), __get (), __set () и __call () в PHP? .htaccess RewriteRule изменить подчеркивание на тире Php, чтобы заменить @username ссылкой на аккаунт Twitter Mail возвращает false Доступ только AJAX ошибка парсера: ожидаемый стартовый тег, '<' не найден Что неожиданный T_VARIABLE в PHP?

Когда нужно санировать код PHP и MySQL, прежде чем хранить его в базе данных или когда он отображается?

Хорошо, мне было интересно, когда я должен дезинфицировать свой код, когда я добавляю его в базу данных или когда он отображается на моей веб-странице или и то, и другое?

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

Вот пример того, как я дезинфицирую свой код перед его хранением в базе данных. 

$title = mysqli_real_escape_string($mysqli, $purifier->purify(strip_tags($_POST['title']))); $content = mysqli_real_escape_string($mysqli, $purifier->purify($_POST['content']));

Related of "Когда нужно санировать код PHP и MySQL, прежде чем хранить его в базе данных или когда он отображается?"

Существуют различные угрозы, которые вы (возможно) говорите здесь:

  • Вам нужно дезинфицировать данные, которые вставляются в базу данных, чтобы избежать инъекций SQL .
  • Вы также должны быть осторожны с данными, которые отображаются пользователю, так как могут содержать вредоносные скрипты (если они были отправлены другими пользователями). См. Запись в Википедии для межсайтового скриптинга (иначе XSS)

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

В вашем примере:

  • Используйте mysqli :: real_escape_string () для данных, вставленных в ваш db (дезинфекция)

Вероятно, вы захотите использовать очиститель перед вводом данных – просто убедитесь, что он «очищен» к моменту получения пользователем.

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

Правило – большой палец для дезинфекции всего пользовательского ввода. Никогда не доверяйте пользователю.

Когда вы помещаете что-то в базу данных, вы убедитесь, что в базу данных можно безопасно.

Когда вы собираетесь отображать что-то в браузере, вы убедитесь, что его можно отобразить в браузере.

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

Я думаю, что вы захотите escape ввода (чтобы избежать инъекций SQL) и sanitize (чтобы избежать атак сценариев) одновременно с вставкой в ​​базу данных.
Таким образом, вам нужно только запустить sanitizer один раз при вставке, а не (потенциально) миллионы раз на дисплее.

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