Лучший способ защиты от внедрения mysql и межсайтового скриптинга

Если вы просто делаете много вещей, которых вы не понимаете, это вам не поможет. Вы должны понимать, что такое инъекционные атаки и как именно и где что делать.

В маркированном списке:

• Отключить волшебные цитаты. Это неадекватное решение, и они запутывают дела.
• Никогда не вставляйте строки непосредственно в SQL. Используйте связанные параметры или экранирование (используя mysql_real_escape_string).
• Не отменяйте экранирование (например, stripslashes) при извлечении данных из базы данных.
• Когда вы встраиваете строки в html (например, когда вы echo), вы должны по умолчанию экранировать строку (используя htmlentities с ENT_QUOTES).
• Если вам нужно встроить html-строки в html, вы должны учитывать источник строки. Если он ненадежный, вы должны пропустить его через фильтр. strip_tags теоретически то, что вам следует использовать, но он ошибочен; Вместо этого используйте HtmlPurifier.

См. Также: Какой лучший метод очистки пользовательского ввода с помощью PHP?

Лучший способ противодействия SQL-инъекции - привязать переменные, а не «вставлять» их в строку. http://www.php.net/manual/en/mysqli-stmt.bind-param.php

Не! Использование mysql_real_escape_string достаточно, чтобы защитить вас от SQL-инъекции, а stropslashes, которое вы делаете после, делает вас уязвимым для SQL-инъекции. Если вы действительно этого хотите, поместите его перед, как в:

function madSafety($string)
{
    $string = stripslashes($string);
    $string = strip_tags($string);
    $string = mysql_real_escape_string($string);
    return $string;
}

stripslashes бесполезен, если вы делаете mysql_real_escape_string.

strip_tags защищает от внедрения HTML / XML, но не от SQL.

Важно отметить, что вы должны экранировать свои строки по-разному в зависимости от того, как вы его используете непосредственно.

Когда вы выполняете запросы MYSQL, используйте mysql_real_escape_string. При выводе веб-страниц используйте htmlentities. Для создания веб-ссылок используйте urlencode…

Как заметил vartec, если вы можете использовать заполнители, обязательно сделайте это.

Это такая неправильная тема!

Вы НЕ должны фильтровать ввод пользователя! Это информация, которую он ввел. Что вы собираетесь делать, если я хочу, чтобы мой пароль был таким: '"'>s3cr3t<script>alert()</script>

Отфильтровать символы и оставить меня с измененным паролем, чтобы я даже не смог войти в систему в первый раз? Это плохо.

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

Напомню, что Интернет - это лишь один из способов представления информации, введенной пользователем. Вы бы согласились с такой зачисткой, если бы ее делали какие-нибудь настольные программы? Надеюсь, ваш ответ - НЕТ, и вы поймете, почему это неправильный путь.

Обратите внимание, что в другом контексте разные символы должны быть экранированы. Например, если вам нужно отобразить имя пользователя как всплывающую подсказку, вы будете использовать что-то вроде:

<span title="{$user->firstName}">{$user->firstName}</span>

Однако, если пользователь установил свое имя как '"><script>window.document.location.href="http://google.com"</script>, что вы собираетесь делать? Убрать цитаты? Это было бы так неправильно! Вместо того, чтобы делать это бессмысленно, подумайте о том, чтобы избегать кавычек при рендеринге данных, а не при их сохранении!

Другой контекст, который вы должны учитывать, - это при рендеринге самого значения. Рассмотрим ранее использованный html-код и представьте, что имя пользователя выглядит как <textarea>. Это обернуло бы весь следующий html-код в этот элемент textarea, разбив, таким образом, всю страницу.

Еще раз - рассмотрите возможность экранирования данных в зависимости от контекста, в котором вы их используете!

P.S Не совсем уверен, как реагировать на эти отрицательные голоса. Вы действительно читаете мой ответ?