Понять валидацию данных пользователя для подготовленных выписок

Question

I прочитайте, что вам не нужно проверять или дезинфицировать ввод пользователя , если вы используете подготовленные операторы.

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

Пользователь дает свой адрес электронной почты.

Я обычно запускаю это

Код подтверждения

 // to validate data
 if (!filter_var($_POST['email'], FILTER_VALIDATE_EMAIL)) {
     header("Location: index.php");
     die("Wrong email-address");
 }

В заявлении говорится, что нам не нужно проверять данные, если мы используем подготовленные заявления, как указано ниже

Код без кода подтверждения

 // to get email-address nad passhash from the db
 $result = pg_prepare($dbconn, "query2", 'SELECT email, passhash_md5
     FROM users WHERE email = $1
     AND passhash_md5 = $2;');
 $result = pg_execute($dbconn, "query2", array($_POST['email'], $_POST['password']));
 if(!$result) {
     echo "An error occurred";
     exit;
 }

Я не уверен, нужен ли нам код проверки в последнем коде, так как мы используем pg_prepare и pg_execute.

Вам нужно рассмотреть вопрос о проверке и дезинфекции ввода пользователя, если вы используете подготовленные заявления?

Answer 1

Вам все еще нужно проверить свои данные, но вам не нужно их очищать.

Использование подготовленных операторов предотвращает вставку вредоносного кода, но не проверяет, имеет ли его форма смысл.

Answer 2

Важно разделить валидацию и дезинфекцию.

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

Обеззараживание гарантирует, что данные не причинят вреда при добавлении в базу данных (или последующем отображении на веб-сайте, вызывая атаку XSS или тому подобное). Запрос INSERT INTO people (names) VALUES('$name') завершится неудачей, если $name = "O'Reilly", но подготовленный оператор автоматически пропустит одинарную кавычку при привязке строки в качестве параметра. При использовании разных наборов символов это особенно важно, поскольку может быть больше, чем просто символы кавычек и косой черты, которые могут вызвать проблемы, возможно, разрешая атаку SQL-инъекцией.

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

Answer 3

Подготовленные заявления позаботятся о злонамеренных намерениях, но вам все равно нужно убедиться, что ваш пользователь вводит то, что вы ожидаете.

Например, если у вас есть форма, которая запрашивает номер телефона, пользователь, введя "jkl; asdgfjkladg", не причинит никакого вреда вашей базе данных, но данные бесполезны.

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