PHP Lang
  1. PHP Lang
  3. Исключение переменных
Intereting Posts
preg_split, как включить разделительный разделитель в результаты? Регулярное выражение PHP для удаления тегов в документе HTML Есть ли способ вернуть HTML в PHP-функцию? (без построения возвращаемого значения в виде строки) Подавление предупреждений PDO Прозрачная PNG над JPG в PHP Неустранимая ошибка: класс «PHPMailer» не найден Проверить несколько значений php array Как различать запросы http и cli? Почему мой короткий код выполняется перед другим контентом? Где найти php_printer.dll? Вычислить прошедшее время в php Как я могу решить кодировку языка PHP на веб-странице? Internet Explorer 8 не передает cookie сеанса для запроса ajax Неинтерминированная ошибка ссылки на объект в PHP 5.3.X Какие форматы даты поддерживает функция PHP strtotime ()?

Исключение переменных

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

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

Однако я не уверен, что делать со всеми пост-переменными. Если он не поступает из базы данных, поэтому, если это сырые входные данные, полное экранирование полностью необходимо. Но я использую PDO prepare / execute, чтобы избежать всех переменных. Вопросы сейчас:

  1. Можно ли использовать PDO для подготовки / выполнения как в операциях select и insert? Разве это не ускользает от переменных дважды?
  2. Предположим, что я получаю переменную через инструкцию exeute PDO – нормально ли отображать эту переменную просто с $ _POST ['variable'], не избегая ее (если она уже была выполнена в функции PDO)?
  3. Является ли htmlspecialchars () достаточно, чтобы избежать таких вещей, как переменные GET, которые не поступают из базы данных?

И самое главное – все это, PDO prepare / execute и htmlspecialchars (), достаточно, чтобы предотвратить все атаки XSS? Или я должен делать больше? Если да, то что это должно быть? Удаление всех html-тегов из ввода? Вместо использования BB-кода?

Solutions Collecting From Web of "Исключение переменных"

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

Как правило, вы хотите:

  • Подтвердите ввод и сохраните его с помощью подготовленных инструкций. Подготовленные утверждения будут защищать вашу базу данных от SQL-инъекций. Как правило, вы не хотите выделять HTML-теги для ввода, потому что это может привести к потере целостности данных.
  • При отображении пользовательских данных ( вывода ) вы можете защитить от XSS, используя комбинацию htmlentities и mb_convert_encoding.

Обратите внимание на функцию htmlspecialchars из другого вопроса :

Даже если вы используете htmlspecialchars ($ string) за пределами HTML-тегов, вы по-прежнему уязвимы для многобайтовых символов атаки набора символов.

Наиболее эффективным может быть использование комбинации mb_convert_encoding и htmlentities следующим образом. 

 $str = mb_convert_encoding($str, 'UTF-8′, 'UTF-8′); $str = htmlentities($str, ENT_QUOTES, 'UTF-8′);

escape-символы на выходе, а не на входе

Да.

легко применяется ко всем переменным get

Но $ _GET по определению вводит

Разве это не ускользает от переменных дважды?

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

Следовательно, если начать с 

 O'Reilly

Затем убегайте, чтобы объединить его в строку SQL. 

 O\'Reilly

Затем значение, хранящееся в базе данных и получаемое оператором SELECT, равно 

 O'Reilly

И когда вы хотите вывести его своим HTML, то вы передаете его, хотя htmlspecialchars (), чтобы получить 

 O"Reilly

Вы используете соответствующий метод для экранирования данных в зависимости от того, куда он идет – следовательно, вы используете mysql_real_escape () или привязку к параметру или аналогичную, когда кладете вещи в вашу базу данных, а htmlspecialchars () при размещении материала INTO html

  1. всякий раз, когда данные поступают от пользователя, дезинфицируйте его (обратите особое внимание на его сохранение в базе данных). Поэтому PDO с подготовленным заявлением является обязательным. Что еще вы делаете, добавляется бонус.

  2. Да (мнения будут отличаться от человека к человеку) для предотвращения внедрения sql (при условии, что вы используете подготовленный оператор). хотя я предпочитаю хранить необработанные данные в базе данных, даже если это означает жертвовать за какой-то вредоносный код XSS, может содержать его. Во время вывода, проявляйте максимальную осторожность.

  3. Нет. Используйте htmlpurifier (с представлением, которое вы выводите из базы данных).

Я использую mysqli_real_escape_string и preg_replace 

 $email = mysqli_real_escape_string($dbc, trim($_POST['email'])); $password = mysqli_real_escape_string($dbc, trim($_POST['password'])); $domain = preg_replace('/^[a-zA-Z0-9][a-zA-Z0-9\._\-&!?=#]*@/', '', $email);

Кроме того, здесь приведена ссылка на аналогичную запись о том, что PDO экранирует аргументы Escape для операторов PDO?