Является ли преобразование специальных символов в объекты 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']; ?
Ваша путаница довольно распространена, потому что информация и примеры в книгах и в Интернете, включая php.net, являются вводящими в заблуждение или неоднозначными. Самое главное, что вы можете узнать при разработке веб-приложений, – это вход фильтра, выход выхода .
Ввод фильтра Это означает, что для любого ввода данных, предоставленного пользователем в форме или предоставленного файлом из другого источника, отфильтровывайте все, что не принадлежит. Например, если вы ожидаете числовое значение, отфильтруйте любые нечисловые символы. Другим примером может быть ограничение / обеспечение максимальной длины данных. Однако вам не нужно сходить с ума от этого. Например, если вы ожидаете строку текста, которая может содержать буквально любую комбинацию символов, то попытка создать фильтр будет, вероятно, только сорвать ваших пользователей.
Таким образом, вы, как правило, сохраняете входные данные в своей базе данных, как это предусмотрено опциональной фильтрацией.
Выход Escape. Что подразумевается под выходным выходом – это правильно делать данные для данного носителя. В большинстве случаев этот носитель представляет собой веб-страницу (html). Но он также может быть простым текстом, xml, pdf, изображением и т. Д. Для html это означает использование htmlspecialchars() или htmlentities() (вы можете прочитать о различиях здесь ). Для других типов носителей вы избегаете / конвертируете по необходимости (или вообще не при необходимости).
Теперь, ваш вопрос заключается в том, следует ли использовать htmlspecialchars() для входных данных, которые будут использоваться в качестве параметров запроса sql. Ответ – нет. Вы не должны каким-либо образом изменять данные.
Да, данные, содержащиеся в $ _POST, следует считать опасными . Именно поэтому вам следует: 1) защититься от SQL-инъекции, используя подготовленные операторы и связанные параметры, как вы это делаете, и 2) правильно вывести / конвертировать данные, найденные в $ _POST, если вы поместите его в html.
Существует много фреймворков для PHP, которые обрабатывают эти данные для вас, и я рекомендую вам выбрать и использовать их. Однако, если вы этого не сделаете, вы все равно можете создать безопасное и безопасное приложение. Независимо от того, используете ли вы рамки или нет, я настоятельно рекомендую вам ознакомиться с рекомендациями, предложенными OWASP . Несоблюдение этого требования приведет только к кошмару безопасности для вашего веб-приложения.
Вы должны использовать htmlspecialchars когда у вас есть простой текст (например, пользовательский ввод или пользовательский ввод, который вы ранее хранили в базе данных и просто извлекли из него с помощью SELECT или текст, полученный через HTTP от третьего лица и т. Д. И т. Д.). и вы хотите вставить его в HTML-документ . Это защищает вас от XSS.
В общем, вы не должны использовать его при вставке данных в базу данных (база данных не является документом HTML). Возможно, вы захотите использовать его в некоторых формах, отличных от HTML.
По-моему, пользователь имеет право добавлять любого персонажа, такого как пароль. И в этом нет необходимости ограничивать его.
Ответ на ваш вопрос о htmlspecialchars ():
Параметры для подготовленных операторов не обязательно должны указываться; драйвер автоматически обрабатывает это. Если приложение использует исключительно подготовленные операторы, разработчик может быть уверен, что SQL-инъекция не произойдет (однако, если другие части запроса создаются с несвязанным вводом, SQL-инъекция по-прежнему возможна).
Подготовленные отчеты и хранимые процедуры
Надежда помогла. Удачи