Использование функции htmlspecialchars с подготовкой и выполнением PDO

Question

Преобразование специальных символов в объекты HTML в форме проверки и запроса базы данных с использованием PHP PDO с использованием функции htmlspecialchars() действительно необходимо?

К примеру, у меня есть веб-сайт с простой системой авторизации более или менее, как:

$username = (string) htmlspecialchars($_POST['user']); 
$password = (string) htmlspecialchars($_POST['pass']); 

$query = $dbh->prepare("select id where username = ? and password = ?") 
$query->execute($username, $password); 

Обратите внимание, что я также использовать приведение типов, кроме функции в вопросе .. Так что, нужно ли это? Или я могу безопасно использовать $username = $_POST['user'];?

Answer 1

Ваше замешательство довольно распространено, потому что информация и примеры в книгах и в Интернете, включая php.net, являются вводящими в заблуждение или двусмысленными. Самое главное, что вы можете узнать при разработке веб-приложений: filter input, escape output.

Фильтр входного Это означает, что для любого ввода данных ли предоставленного пользователем в форме или предоставленный файлом из другого источника, отфильтровать все, что не принадлежит. Например, если вы ожидаете числовое значение, отфильтруйте любые нечисловые символы. Другим примером может быть ограничение/обеспечение максимальной длины данных. Однако вам не нужно сходить с ума от этого. Например, если вы ожидаете строку текста, которая может содержать буквально любую комбинацию символов, то попытка создать фильтр будет, вероятно, только сорвать ваших пользователей.

Таким образом, вы обычно храните входные данные в своей базе данных, как предусмотрено с опцией фильтрации.

побег Выход Что подразумевается под выхода побега является правильно сделать безопасными данные для данного средства массовой информации. В большинстве случаев этот носитель представляет собой веб-страницу (html). Но это также может быть простой текст, xml, pdf, изображение и т. Д. Для html это означает использование htmlspecialchars() или htmlentities() (вы можете прочитать об отличиях here).Для других типов носителей вы избегаете/конвертируете по необходимости (или вообще не при необходимости).

Теперь, ваш вопрос заключается в том, следует ли использовать htmlspecialchars() для ввода данных, которые будут использоваться в качестве параметров запроса sql. Ответ - нет. Вы не должны каким-либо образом изменять данные.

Да, данные, содержащиеся в $ _POST, считаются опасными. Именно поэтому вам следует: 1) защититься от SQL-инъекции, используя подготовленные операторы и связанные параметры, как вы это делаете, и 2) правильно вывести/конвертировать данные, найденные в $ _POST, если вы поместите его в html.

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

Answer 2

Вы должны использовать htmlspecialchars, если у вас есть простой текст (например, ввод пользователя или пользовательский ввод, который вы ранее храните в базе данных, и только что извлеченный из него с помощью SELECT или текст, полученный через HTTP от третьего лица, etc и т. д.), и вы хотите вставить его в HTML-документ. Это защищает вас от XSS.

В общем, вы не должны использовать его при вставке данных в базу данных (база данных не является документом HTML). Возможно, вы захотите использовать его в некоторых формах, отличных от HTML.

Answer 3

По моему мнению, пользователь имеет право добавить любого персонажа, такого как пароль. И в этом нет необходимости ограничивать его.

Ответ на ваш вопрос о htmlspecialchars():

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

Prepared statements and stored procedures

Надежда помогла. Удачи