PHP: лучшие методы безопасности для отображенной информации?
В PHP я знаю, что использование параметризированных запросов является лучшим способом предотвратить Внедрение SQL.
Но что относительно того, чтобы санировать ввод данных пользователем, который будет использоваться для других целей, таких как:
- Отображение назад пользователю (потенциальный вектор сценариев перекрестного сайта)
- Обращение к электронному письму или заполнение тела сообщения
htmlentities() лучший способ санировать для использования небазы данных? Что считается лучшей практикой здесь?
4 ответа
В php лучший xss-фильтр:
htmlspecialchars($_POST['param'],ENT_QUOTES);
Причина, по которой вам также необходимо кодировать кавычки, заключается в том, что вам не нужно использовать <> для использования некоторые xss.например, это уязвимо для xss:
print('<A HREF="http://www.xssed.com/'.htmlspecialchars($_REQUEST[xss]).'">link</a>');
В этом случае вам не нужен <> для выполнения javascript, потому что вы можете использовать onmouseover, вот пример атаки:
$_REQUEST[xss]='" onMouseOver="alert(/xss/)"';
ENT_QUOTES заботится о двойные кавычки.
Электронная почта немного отличается, javascript не должен выполняться почтовым клиентом, и если это так, то ваш сайт не пострадает из-за той же политики происхождения. Но на всякий случай я бы все равно использовал htmlspecialchars ($ var, ENT_QUOTES); . ОДНАКО функция PHP mail () может стать жертвой другого типа уязвимости, называемого CRLF-инъекцией. Вот пример уязвимости против PHP-Nuke . Если у вас есть такой вызов функции: mail ($ fmail, $ subject, $ message, $ header); Тогда вы должны убедиться, что пользователь не может вводить \ r \ n в $ header.
Код уязвимости:
$header="From: \"$_GET[name]\" <$ymail>\nX-Mailer: PHP";
исправлено:
$_GET[name]=str_replace(array("\r","\n"),$_GET[name]);
$header="From: \"$_GET[name]\" <$ymail>\nX-Mailer: PHP";
Вы также можете проверить HTML Purifier, который удалит любой опасный HTML и оставит безопасный ввод . Вы также можете создать свои собственные правила того, какой HTML разрешать / запрещать.
Ну, вы можете сначала создайте правила для определенных полей, таких как электронная почта, единственное, из чего он должен состоять, это буквы, числа, @ (символ at? как он на самом деле называется) и точка, поэтому вы не можете сформировать XSS из этого, поэтому нет необходимости тратить ресурсы впустую с помощью htmlentities () или htmlspeicalchars () .
Нет,
1) подготовленные операторы не являются решением проблемы внедрения SQL. В большинстве случаев подготовленные операторы подразумевают привязку переменных и, следовательно, прозрачное экранирование, которое является эффективным способом предотвращения SQL-инъекции.
2) вы НЕ дезинфицируете ввод - вы дезинфицируете вывод . Обязательно проверяйте ввод (например, убедитесь, что дата начала предшествует дате окончания), но представление данных должно изменяться только в том месте, где оно покидает ваш PHP-код. Метод очистки данных, записанных непосредственно в HTML, отличается от того, как вы дезинфицируете данные, записанные в URL-адрес, отличается от того, как вы дезинфицируете данные для записи их в строковую переменную javascript, отличается от того, как вы дезинфицируете данные для вставки в оператор SQL, отличается от того, как вы дезинфицируете данные перед их отправкой на модем, это ...
... что вы собираетесь делать? создать всевозможное представление данных? Создать универсальное представление данных?
C.