Защищают ли htmlspecialchars и реальная escape-строка mysql мой PHP-код от инъекций?

В дополнение к превосходному ответу Cheekysoft:

• Да, они обеспечат вам безопасность, но только в том случае, если они используются абсолютно правильно. Используйте их неправильно, и вы все равно будете уязвимы, и у вас могут возникнуть другие проблемы (например, повреждение данных)
• Пожалуйста, используйте вместо этого параметризованные запросы (как указано выше). Вы можете использовать их, например, через PDO или через оболочку, такую как PEAR DB
• Убедитесь, что magic_quotes_gpc и magic_quotes_runtime всегда отключены, и никогда случайно включиться, даже ненадолго. Это ранняя и глубоко ошибочная попытка разработчиков PHP предотвратить проблемы безопасности (которые уничтожают данные)

На самом деле нет серебряной пули для предотвращения внедрения HTML (например, межсайтового скриптинга), но вы можете добиться этого проще, если используете библиотеку или систему шаблонов для вывода HTML. Прочитайте документацию по этому вопросу, чтобы узнать, как правильно избежать этого.

В HTML все должно быть быть экранированным по-разному в зависимости от контекста. Это особенно верно для строк, помещаемых в Javascript.

Я бы определенно согласился с приведенными выше сообщениями, но у меня есть одна маленькая вещь, которую я должен добавить в ответ на ответ Cheekysoft, а именно:

Когда дело доходит до запросов к базе данных, всегда старайтесь использовать подготовленные параметризованные запросы. mysqli и Библиотеки PDO поддерживают это. Это бесконечно безопаснее, чем использование экранирующих функций, таких как mysql_real_escape_string.

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

Представьте себе следующий SQL:

$результат= "ВЫБЕРИТЕ поля ИЗ таблицы ГДЕ id= ".строка mysql_real_escape_string($_POST['идентификатор']);

Вы должны быть в состоянии видеть, что это уязвимо для использования. Представьте себе идентификатор параметр содержал общий вектор атаки:

1 ИЛИ 1=1

Там нет рискованных символов для кодирования, поэтому он пройдет прямо через выходящий фильтр. Уходя мы:

ВЫБЕРИТЕ поля ИЗ таблицы, ГДЕ id = 1 ИЛИ 1=1

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

function Numbers($input) {
  $input = preg_replace("/[^0-9]/","", $input);
  if($input == '') $input = 0;
  return $input;
}

Поэтому вместо использования

$результат = "ВЫБЕРИТЕ поля ИЗ таблицы, ГДЕ id =".mysqlrealescapestring("1 ИЛИ 1=1");

Я бы использовал

$результат= "ВЫБЕРИТЕ поля ИЗ таблицы, ГДЕ id =".Числа("1 ИЛИ 1=1");

И он безопасно выполнит запрос

ВЫБЕРИТЕ поля ИЗ таблицы, ГДЕ id = 111

Конечно, это просто помешало ему отобразить правильную строку, но я не думаю, что это большая проблема для тот, кто пытается внедрить sql на ваш сайт;)

Важной частью этой головоломки являются контексты. Кто-то, отправляющий "1 ИЛИ 1=1" в качестве идентификатора, не является проблемой, если вы цитируете каждый аргумент в своем запросе:

SELECT fields FROM table WHERE id='".mysql_real_escape_string($_GET['id'])."'"

Что приводит к:

SELECT fields FROM table WHERE id='1 OR 1=1'

Что неэффективно. Поскольку вы экранируете строку, входные данные не могут вырваться из контекста строки. Я протестировал это до версии 5.0.45 MySQL, и использование контекста строки для целочисленного столбца не вызывает никаких проблем.

$result = "SELECT fields FROM table WHERE id = ".(INT) $_GET['id'];

Работает хорошо, даже лучше на 64-битных системах. Однако остерегайтесь системных ограничений на адресацию больших чисел, но для идентификаторов баз данных это отлично работает в 99 % случаев.

Вы также должны использовать одну функцию/метод для очистки своих значений. Даже если эта функция является просто оболочкой для mysql_real_escape_string(). Почему? Потому что однажды, когда будет обнаружен эксплойт для вашего предпочтительного метода очистки данных, вам нужно будет обновить его только в одном месте, а не в общесистемный поиск и замена.

Почему, о, ПОЧЕМУ бы вам не включить кавычки вокруг пользовательского ввода в свой оператор sql? кажется довольно глупым не делать этого! включение кавычек в вашу инструкцию sql сделало бы "1 или 1=1" бесплодной попыткой, не так ли?

Итак, теперь вы скажете: "Что, если пользователь включит кавычку (или двойные кавычки) во входные данные?"

Ну, это легко исправить: просто удалите введенные пользователем кавычки. например: input =~ s/'//g;. теперь, мне все равно кажется, что пользовательский ввод будет защищен...