Предотвращает XSS и Внедрение SQL, столь легкое, как делает это
Вопрос: предотвращает XSS (сценарии перекрестного сайта) как простое использование strip_tags на любых сохраненных полях ввода и выполнении htmlspecialchars на отображенном выводе... и предотвращении Внедрения SQL при помощи PHP PDO подготовил операторы?
Вот пример:
// INPUT: Input a persons favorite color and save to database
// this should prevent SQL injection ( by using prepared statement)
// and help prevent XSS (by using strip_tags)
$sql = 'INSERT INTO TABLE favorite (person_name, color) VALUES (?,?)';
$sth = $conn->prepare($sql);
$sth->execute(array(strip_tags($_POST['person_name']), strip_tags($_POST['color'])));
// OUTPUT: Output a persons favorite color from the database
// this should prevent XSS (by using htmlspecialchars) when displaying
$sql = 'SELECT color FROM favorite WHERE person_name = ?';
$sth = $conn->prepare($sql);
$sth->execute(array(strip_tags($_POST['person_name'])));
$sth->setFetchMode(PDO::FETCH_BOTH);
while($color = $sth->fetch()){
echo htmlspecialchars($color, ENT_QUOTES, 'UTF-8');
}
6 ответов
Это еще проще. Достаточно только htmlspecialchars() (со стилем кавычек и набором символов) на управляемом пользователем входе. Функция strip_tags() полезна только в том случае, если вы уже хотите дезинфицировать данные перед их обработкой/сохранением в базе данных, которая часто не используется в реальном мире. HTML-код не вредит исходным текстам PHP, но PHP-код может это сделать, если вы используете eval() на несанифицированном пользовательском вводе или что-то в этом роде зла.
Это, однако, не спасет вас от SQL-инъекций, но это уже другая история.
Обновление: чтобы получить чистый пользовательский ввод из запроса, чтобы избежать магических кавычек в пользовательском вводе, вы можете использовать следующую функцию:
function get_string($array, $index, $default = null) {
if (isset($array[$index]) && strlen($value = trim($array[$index])) > 0) {
return get_magic_quotes_gpc() ? stripslashes($value) : $value;
} else {
return $default;
}
}
, которая может быть использована в качестве:
$username = get_string($_POST, "username");
$password = get_string($_POST, "password");
(можно сделать simliar для get_number, get_boolean, get_array и т.д.)
Для подготовки SQL-запроса во избежание SQL-инъекций, do:
$sql = sprintf(
"SELECT id FROM user WHERE username = '%s' AND password = MD5('%s')",
mysql_real_escape_string($user),
mysql_real_escape_string($password)
);
Для отображения управляемого пользователем входа во избежание XSS, do:
echo htmlspecialchars($data, ENT_QUOTES, 'UTF-8');
Это зависит от того, где и как вы хотите использовать пользовательские данные. Вам необходимо знать контекст, в который вы хотите вставить свои данные, и мета-символы этого контекста.
Если вы просто хотите позволить пользователю размещать текст на вашем сайте, htmlspecialchars достаточно, чтобы избежать мета-символов HTML. Но если вы хотите разрешить определенный HTML или хотите вставить пользовательские данные в существующие HTML элементы (например, URL в элемент A/IMG), htmlspecialchars не достаточно, так как вы уже не в HTML-контексте, а в URL-контексте.
Итак, ввод в поле URL изображения даст:
<img src="<script>alert("xss")</script>" />
Но ввод javascript:alert("xss") будет успешным:
<img src="javascript:alert("xss")" />
Здесь вы должны взглянуть на сказочный XSS (Cross Site Scripting) Cheat Sheet, чтобы увидеть, в какой контекст могут быть введены ваши пользовательские данные.
. strip_tags не требуется. В большинстве случаев strip_tags просто раздражает, так как некоторые из ваших пользователей могут захотеть использовать < и > в своих текстах. Просто используйте htmlspecialchars (или htmlentities, если хотите) перед тем, как вы повторите тексты в браузере.
(Не забудьте mysql_real_esacpe_string перед тем, как вставлять что-либо в свою базу данных!)
.Простой ответ: нет
Более длинный ответ: Есть способы внедрить xss, которые PHP strip_stags не может избежать.
Для лучшей защиты попробуйте HTML очиститель
Общее правило / мем - «Фильтр ввода, выход для выхода». Использование strip_tags в вашем вводе для удаления любого HTML - хорошая идея для фильтрации ввода, но вы должны быть как можно более строгими в том, какой ввод вы разрешаете. Например, если входной параметр должен быть только целым числом, принимайте только числовой ввод и всегда преобразуйте его в целое число, прежде чем делать что-нибудь с ним. Здесь вам очень поможет хорошо проверенная библиотека входной фильтрации; тот, который не является специфическим для конкретной структуры, - это Inspekt (который я написал, поэтому я немного предвзято).
Для вывода htmlspecialchars должны ускользать от XSS-атак, , но только если вы передадите правильные параметры . Вы должны передать стиль экранирования кавычек и кодировку.
В общем, этот должен удалять атаки XSS:
$safer_str = htmlspecialchars($unsafe_str, ENT_QUOTES, 'UTF-8');
Без передачи ENT_QUOTES в качестве второго параметра, символы в одинарных кавычках не кодируются. Кроме того, были продемонстрированы атаки XSS, когда правильная кодировка не передана (обычно UTF-8 будет адекватным). htmlspecialchars должен всегда вызываться с ENT_QUOTES и параметром набора символов.
Обратите внимание, что PHP 5.2.12 содержит исправление для многобайтовой XSS-атаки .
Вы можете найти порт OWASP ESAPI PHP интересным и полезным, хотя версия PHP не является полной AFAIK.
Да, используя полуконные заявления PDO, защищает от инъекции SQL. Атака для инъекций SQL основана на том факте, что данные, представленные злоумышленником, рассматриваются как часть запроса. Например, злоумышленник представляет строку «A» или «A» = «A» как его пароль. Вместо всей строки сравнивают с паролями в базе данных, он включен в запрос, поэтому запрос становится «выбирать * от пользователей, где вход в систему =« Joe »и Password = 'A' или« A '=' A » ". Часть ввода злоумышленника интерпретируется как часть запроса. Однако в случае подготовленных утверждений вы рассказываете SQL Engine специально, какую часть является запрос, и какая часть есть данные (установив параметры), поэтому такое путаница не возможно.
Нет, использование Strip_tags не всегда будет защищать вас от скриптов на сайт. Рассмотрим следующий пример. Давайте скажем, ваша страница содержит:
<script>
location.href='newpage_<?php echo strip_tags($_GET['language']); ?>.html';
</script>
злоумышленник представляет запрос с «языком», установленным на «»; что-либо (); ». strip_tags () Возвращает эти данные как есть (в нем нет тегов). Произведенный код страниц становится:
<script>
location.href='newpage_';somethingevil();'.html';
</script>
Что-то делается (). Замените что-либо () с фактическим кодом эксплуатации XSS.
Ваш последний пример с HTMLspecialChars () защитит от этого, потому что он избежит отдельных кавычек. Однако я видел даже временные случаи данных поставляемых пользователем данных внутри кода JavaScript, где он даже не в цитированной строке. Я думаю, что это было в имени переменной или функции. В этом последнем случае никакого выхода, вероятно, не поможет. Я верю, что лучше избегать использования пользовательского ввода для генерации кода JavaScript.