В этом руководстве почему он говорит нам возиться с $ _POST ['email']?

#php #mysql #security

#php #mysql #Безопасность

Вопрос:

http://php.about.com/od/finishedphp1/ss/php_login_code_4.htm

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

 if (!get_magic_quotes_gpc()) {

        $_POST['email'] = addslashes($_POST['email']);

    }

Почему она возится со значением $ _POST [’email’], когда его даже нет в поле ввода?

Редактировать:

Я все еще не могу найти поле ввода для электронной почты, я даже скопировал и вставил весь сайт. Я все еще не могу найти ни одного окна с надписью email.

1. должно быть, скопировали код откуда-то .. : D

2. Это из поля ввода (прочитайте комментарии на этой странице, они говорят ` //если форма входа отправлена`). И, кстати, это ужасный код. Действительно ужасно.

3. Я все еще не вижу, откуда приходит электронное письмо, страница регистрации не использует электронную почту, и вход в систему также не использует электронную почту… У кого-нибудь есть идея получше для лучшего руководства по входу в систему?

4. На этом сайте ужасное кодирование и ужасный формат для изучения. Попробуйте это. phpeasystep.com/phptu/6.html

Ответ №1:

Во-первых, не имеет значения, откуда на странице берется контент. Любой пользовательский контент (т. Е. Что-либо в $_GET , $_POST или $_COOKIE суперглобальных) следует рассматривать как небезопасный. Не думайте, что единственный способ, которым пользователь может отправить вредоносный контент, — это ввести его в текстовое поле.

Во-вторых, этот код, ИМО, тупой. В основном это говорит «если волшебные кавычки отключены, сделайте то, что они сделали бы, если бы были включены, добавив косые черты, чтобы избежать SQL-инъекции». Это ленивый способ заставить ваш код работать. Правильный способ — построить свой код так, чтобы не было необходимости в магических кавычках, используя параметризованные запросы (например, используя PDO или mySqli).

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

Ответ №2:

Когда форма отправлена (через POST ), вы можете получить доступ к данным на стороне сервера с помощью специальной переменной $_POST . Каждый элемент вашей формы будет проиндексирован в этом массиве, укажите его DOM-имя.

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

Смотрите: супер глобалы, внедрение sql в owasp, и волшебные кавычки.

Ответ №3:

email вероятно, задается формой на другой странице, которая ссылается на эту страницу. Что касается записи непосредственно в _POST, я не думаю, что в этом есть что-то неправильное само по себе, но я думаю, что это странно, и мне не нравится это делать. На самом деле, я бы поступил наоборот и удалил косые черты, если включены магические кавычки, и обработал бы их экранирование позже (а не с помощью mysql_real_escape_string). Перед обработкой _POST, значения я бы сделал что-то вроде $email = $_POST['email'] … и т.д. И просто сохранял _POST в качестве необработанных данных _POST все время.