Защита от SQL-инъекций

Быстрые рекомендации.
Правила составления запросов MySQL
Динамическое составление запросов
Правильная работа со спецсимволами при составлении запросов
Подготовленные выражения
SQL Injection
Особенности работы с оператором LIKE
О слешах. Как от них избавиться
Замечания
ОПС: очень полезные ссылки:
Примечание: формы
Комментарии (50)

Быстрые рекомендации.
Для предотвращения SQL инъекций следует соблюдать два простых правила:
1. Не помещать в БД данные без обработки.
Это можно сделать либо с помощью подготовленных выражений, либо обрабатывая параметры вручную.
Если запрос оставляется вручную, то
- все числовые параметры должны быть приведены к нужному типу
- все остальные параметры должны быть обработаны функцией mysql_real_escape_string() и заключены в кавычки.

2. Не помещать в запрос управляющие структуры и идентификаторы, введенные пользователем.
А заранее прописывать в скрипте список возможных вариантов, и выбирать только из них.

Два важных дополнения:
1. Используя изложенную в этой статье информацию, я написал Класс для безопасной и удобной работы с MySQL, который делает запросы безопасными и сокращает код в несколько раз.
2. Если вы не любите сторонние библиотеки, то пользуйтесь хотя бы PDO. Как работать с PDO? Полное руководство.

Правила составления запросов MySQL
Для начала - немного о том, почему вообще нужны эти слеши.
Если мы подставляем в запрос какие-либо данные, то, чтобы отличить эти данные от команд SQL, их надо брать в кавычки.
К примеру, если написать
SELECT * FROM table WHERE name = Bill
то база решит, что Bill - это имя другого поля, не найдёт его, и выдаст ошибку. Поэтому подставляемые данные (в данном случае имя Bill) надо заключать в кавычки - тогда база сочтет его строкой, значение которой надо присвоить полю name:
SELECT * FROM table WHERE name = 'Bill'
Однако, и в самих данных могут встречаться кавычки тоже. К примеру,
SELECT * FROM table WHERE name = 'Д'Артаньян'
Здесь база данных решит, что 'Д' - это данные, а Артаньян - команда, которую она не знает, и тоже выдаст ошибку. Поэтому и надо прослешивать все данные, чтобы объяснить базе, что встречающиеся в них кавычки (и некоторые другие спецсимволы) относятся к данным.
В результате мы получим правильный запрос, который ошибок не вызовет:
SELECT * FROM table WHERE name = 'Д\'Артаньян'

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

Следует специально отметить: добавленные слеши НЕ идут в базу. Они нужны только в запросе. При попадании в базу слеши отбрасываются. Соответственно, распространенной ошибкой является применение stripslashes при получении данных из базы.

Всё вышесказанное относится к данным строкового типа и датам. Числа можно вставлять не прослешивая и не окружaя кавычками. Если вы так делаете, то ОБЯЗАТЕЛЬНО! насильно приводите данные к нужному типу перед вставкой в запрос, например:
$id=intval($id);
Однако для простоты (и надёжности) можно и с числами работать, как со строками (проскольку mysql всё равно преобразует их к нужному типу). Соответственно, мы будем любые данные, вставляемые в запрос, прослешивать и заключать в кавычки.

Так же, есть ещё одно правило - необязательное, но его следует придерживаться во избежание появления ошибок:
Имена полей и таблиц следует заключать в обратные одинарные кавычки - "`" (клавиша с этим символом находится на стандартной клавиатуре слева от клавиши "1") Ведь имя поля может совпадать с ключевыми словами mysql, но если мы используем обратную кавычку, то MySQL поймёт всё правильно:
SELECT * FROM `table` WHERE `date` = '2006-04-04'
Следует различать эти кавычки и не путать одни с другими. Следует также помнить, что обратные кавычки слешами не экранируются.

Динамическое составление запросов
Если SQL запрос в скрипте написан целиком, и никак не меняется, например
SELECT * FROM `table`
то никаких проблем с ним и не будет.
Но вся сила наших скриптов именно в динамическом составлении запросов!
Вместо того, чтобы писать готовые запросы на все случаи жизни, мы составляем их на основании поступающих в скрипт данных.
И вот здесь нас подстерегает опасность.
Допустим, мы составляем запрос с использованием переменной:
SELECT * FROM table WHERE name = '$name'
Вроде бы - всё нормально?
А если $name у нас будет Д'Артаньян? Запрос выдаст ошибку!
То есть, переменную перед подстановкой в запрос надо прослешить.
Это можно сделать несколькими путями.
Самый простой (и неправильный) - положиться на волшебные кавычки. Как вы уже догадались, именно для этого случая они и были придуманы. Ради того, чтобы уберечь SQL запросы забывчивых программистов от ошибок, ВСЕ поступающие в скрипт данные прослешиваются без разбору.
Если вы используете чужой код, то лучше воспользоваться волшебными кавычками. Это может создавать некоторые неудобства и не гарантирует вас от ошибок или взлома (поскольку прослешиванием правила составления запросов не исчерпываются) но хотя бы снижает риск. Поэтому, при использовании чужого кода, обязательно убедитесь, что волшебные кавычки включены.
Если же вы пишете весь код самостоятельно, то следует научиться правильному составлению запросов.

Правильная работа со спецсимволами при составлении запросов
Итак. Как мы уже узнали выше, чтобы правильно составить запрос, надо заключать данные в кавычки и прослешивать их.
С первым всё понятно. При составлении динамических запросов мы никогда не забываем все данные заключить в кавычки:
$query="INSERT INTO `table` VALUES(NULL,'$name','$date','$price')";
Если переменная $price должна быть типа int и мы приведём её к этому типу, то можно её не заключать в кавычки. Однако, если заключим, то беды особой не будет, но зато можно будет сделать работу с данными единообразной.

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

Сначала отключим волшебные кавычки. Так, как это описано в самом начале.
Почему это следует сделать?
По многим причинам. Самая очевидная - логическая. "Волшебные кавычки" добавляют слеши не там, где они нужны - при составлении запроса, а еще до попадания в скрипт! Но ведь данные совсем не обязательно после этого будут вставляться в запрос. Может быть, их придётся выводить пользователю, и слеши будут только мешать. Плюс к тому, добавленные слеши помешают, к примеру, правильно проверить длину введённой строки. К тому же, прослешивать нам надо не только пришедшие от пользователя данные, а вообще любые, вставляемые в запрос - многим этот очевидный факт даже не приходил в голову! Список можно продолжать, но вывод один: добавлять слеши надо не автоматом, без разбору, до начала выполнения скрипта, а только там, где действительно надо – при составлении запроса.
Есть и ещё одна причина: при использовании кодировки Unicode, которая приобретает всё большую популярность, а со временем займёт доминирующее положение в веб, волшебные кавычки могут попросту испортить текст, приняв часть мультибайтной строки за спецсимвол.

Теперь займёмся добавлением слешей самостоятельно.
Во-первых, для прослешивания мы воспользуемся функцией mysql_real_escape_string()
Следует помнить, что применять её можно только после установления соединения с базой.
Эта функция делает гораздо больше, чем устаревшие addslashes и mysql_escape_string. Во-первых, она облегчает ведение и чтение логов mysql, заменяя, например, символ перевода строки на "\n" и некоторые другие символы на escape-последовательности. Во-вторых, и самое главное - она корректно работает с многобайтными кодировками, принимая во внимание текущую кодировку MySQL и не портит, таким образом, тексты в кодировке Unicode.
Во-вторых, не забываем, что прослешить надо все те данные, которые мы заключили в запросе в кавычки:



$name=mysql_real_escape_string($name);

$age=mysql_real_escape_string($age);

$query="INSERT INTO table (name,age,class) VALUES ('$name','$age',11)";

или:
$query="SELECT * FROM table WHERE name LIKE '".mysql_real_escape_string($_GET['name'])."%'";

Видно, что код получается довольно громоздким. Для облегчения составления запросов можно пуститься на разные ухищнения - сделать функцию для составления запросов из массива (очень удобно для запросов типа INSERT и UPDATE), прослешивать массив данных в цикле, и так далее.
Вы можете написать и свою библиотеку или функцию для составления запросов.
Главное - помнить, что только неукоснительное соблюдение правил составления запросов гарантирует вас от взлома БД, а так же сознавать, что применение "волшебных кавычек", при видимой лёгкости составления запросов, не даёт такой гарантии, а только мешает нормальной работе приложения.

Подготовленные выражения
Есть еще один способ отправлять запросы в БД, называемый "подготовленными выражениями" (prepared statements).
Суть его заключается в том, что подготавливается шаблон запроса, со специальными маркерами, на место которых будут подставлены динамические компоненты. Пример такого шаблона:
SELECT * FROM table WHERE name=?
Знак вопроса здесь - это тот самый маркер. По-другому он называетсй плейсхолдером (placeholder). Весь секрет в том, что данные на его место подставляет специальная функция, которая "привязывает" переменную к запросу.
Вот как выглядит код в таком случае:

$stmt = $mysqli->prepare("SELECT District FROM City WHERE Name=?");

$stmt->bind_param("s", $city);

$stmt->execute();

В первой строчке мы подготавливаем шаблон запроса.
Во второй - привязываем к маркеру значение переменной $city.
В третьей строчке выполняем подготовленный таким образом запрос.
При этом запрос и данные идут в базу не вместе, а по отдельности, исключая возможность какой-либо ошибки или злонамеренной манипуляции.

Понятно, что возникает много вопросов. Но ни объём, ни тематика данной статьи не позволяют остановиться на них более подробно. Рекомендую обратиться к документации по библиотекам mysqli и PDO, реализующим данный принцип.
Так же, можно использовать библиотеку DbSimple Дмитрия Котерова или PEAR::DB. Основное отличие этих двух состоит в том, что они реализуют механизм подготовленных выражений только внешне. А внутри работают по-старинке - составляя запрос и отправляя его в базу, беря на себя работу по обработке переменных. А PDO и mysqli работают, как было описано выше - то есть, шаблон запроса и данные уходят в базу по отдельности.

SQL Injection

Итак, мы научились правильно подставлять в запрос данные.
НО! Динамическое составление запросов не исчерпывается подстановкой данных. Часто нам приходится подставлять в запрос команды SQL и имена полей. И здесь мы уже переходим к теме безопасности:

SQL Injection - это способ хакерской атаки, когда передаваемые скрипту данные модифицируются таким образом, что запрос, формируемый в этом скрипте, начинает выполнять совсем не то, для чего он предназначался.
Правила защиты от таких атак можно разделить на два пункта:
1. Работа с данными.
2. Работа с управляющими элементами запроса.

Первый пункт мы подробно рассматривали выше. Он, можно сказать, и не является, собственно, защитой. Соблюдение правил добавления занных в запрос продиктовано, в первую очередь, требованиями СИНТАКСИСА SQL. А как побочный эффект мы имеем и защиту от взлома.

Второй пункт гораздо сложнее, поскольку не существует такого же единого универсального правила, как для данных - обратная кавычка никак не защитит имя поля от модификации хакером. Невозможно кавычками защитить имя таблицы, операторы SQL, параметры команды LIMIT, и другие операторы.
Поэтому основное правило при подстановке управляющих элементов в запрос такое:
Если требуется динамически подставлять в запрос операторы SQL или имена полей, баз данных, таблиц, то ни под каким видом не вставлять их в запрос напрямую.
Все варианты таких добавлений должны быть ЗАРАНЕЕ прописаны в вашем скрипте и выбираться на основании того, что ввёл пользователь.
К примеру, если надо передать имя поля в оператор order by, то ни в коем случае нельзя подставлять его напрямую. Надо сначала проверить его. К примеру, сделать массив допустимых значений, и подставлять в запрос только если переданный параметр в этом массиве присутствует:

$orders=array("name","price","qty");

$key=array_search($_GET['sort'],$orders));

$orderby=$orders[$key];

$query="SELECT * FROM `table` ORDER BY $orderby";

Мы ищем в массиве заранее описанных вариантов введённое пользователем слово, и, если находим, то выбираем соответствующий элемент массива. Если совпадения не будет найдено, то будет выбран первый элемент массива.
Таким образом, в запрос подставляется не то, что ввёл пользователь, а то, что было прописано у нас в скрипте.
Точно так же надо поступать и во всех остальных случаях
К примеру, если динамически формируется оператор WHERE:

if (!empty($_GET['price'])) $where.="price='".mysql_real_escape_string($_GET['price'])."'";

$query="SELECT * FROM `table` WHERE $where";

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

Особенности работы с оператором LIKE
При работе с оператором LIKE существуют некоторые нюансы.

Во-первых, следует обратить внимание на то, что у этого оператора есть два своих спецсимвола - _ и %. Если вы не хотите, чтобы они использовались, как маски, а хотите искать буквальное совпадение с символами % и _, то их надо прослешить. Это можно сделать командой
$data = addCslashes($data, '%_');
Внимание - это не addslashes! В имени этой функции есть дополнительная буква "c".

Во-вторых, в силу некоторых причин в подставляемых в LIKE (и REGEXP) даных, надо удваивать слеши.

Следовательно, перед тем, как подставлять некую переменную в like, её надо отдельно обработать:
либо прослешить только бэкслеш, если у нас уже стоят символы поиска по маске и мы хотим их использовать по назначению,
$data = addCslashes($data, '\\');
либо прослешить и символы поиска тоже, если мы хотим их добавить вручную,
$data = addCslashes($data, '\%_');

В итоге, код подготовки переменной для подстановки в LIKE может выглядеть так:
$data = '%'.addCslashes($data, '\%_').'%';
и полученное таким образом значение мы уже дальше можем подставлять в запрос, используя либо прослешивание, либо подстановку.

О слешах. Как от них избавиться
Слеш, или бэкслеш, от английского back slash - обратная косая черта ("\"), которая непонятным образом вдруг сама собой появляется в ваших переменных. Добавляется он к некоторым спецсимволам, но в основном его замечают из-за кавычек.
Происходит это из-за специальных настроек PHP, обычно включённых на хостинге по умолчанию. Теоретически, эти настройки могут повысить безопасность скриптов, работающих с БД. Практически же, от автоматического добавления слешей часто получается путаница и неудобство, как при работе с БД, так и при её отсутствии.
Ниже мы подробно разберём оба этих случая.

За автоматическое добавление слешей отвечают директивы php.ini, которые носят общее название "волшебные кавычки":
magic_quotes_gpc и magic_quotes_runtime
Если включена первая, то PHP автоматически добавляет слеши к данным, пришедшим от пользователя - из POST, GET запросов и кук (а так же - к логину и паролю, полученным через HTTP Authorisation).
Если вторая, то слеши добавляются к данным, полученым во время исполнения скрипта - например, из файла или базы данных.

Если вы работаете без базы данных, или же работаете с БД правильно (о чём будет написано ниже), лишние слеши вам только мешают, и от них надо избавляться. Проще и правильнее всего отключить автоматическое добавление, в настройках PHP.
Это можно сделать либо поправив соответствующие директивы в php.ini, если у вас есть к нему доступ, либо создав в коневом каталоге сайта файл .htaccess, и добавив в него строчки

php_flag magic_quotes_gpc 0

php_flag magic_quotes_runtime 0

Если отключить таким образом не получается, то придётся писать код разной степени сложности, чтобы очистить от слешей входящие данные. (Впрочем, если вы хотите написать переносимое приложение, не зависящее от настроек PHP, то написать его всё равно придётся. И включать отдельным блоком в начале ваших скриптов).

С данными, получаемыми во время работы, разобраться проще всего: достаточно в начале скрипта написать
set_magic_quotes_runtime(0);
Для данных, полученных от пользователя, всё гораздо сложнее. Для этого кода нам потребуется две функции:

проверить, добавил ли PHP, можно с помощью функции get_magic_quotes_gpc.

удаляет слеши функция stripslashes.
Соответственно, с помощью первой надо проверить, и, если PHP добавил, то перебрать все входящие переменные и очистить с помощью второй.
Если вы работаете правильно, при register_globals = off, то достаточно применить stripslashes ко всем массивам, содержащим данные, приходящие из браузера.
к примеру, можно включить во все скрипты сайта вот такой код:

function strips(&$el) { 

  if (is_array($el)) 

    foreach($el as $k=>$v) 

      strips($el[$k]); 

  else $el = stripslashes($el); 

} 

if (get_magic_quotes_gpc()) { 

  strips($_GET);

  strips($_POST);

  strips($_COOKIE); 

  strips($_REQUEST);

  if (isset($_SERVER['PHP_AUTH_USER'])) strips($_SERVER['PHP_AUTH_USER']); 

  if (isset($_SERVER['PHP_AUTH_PW']))   strips($_SERVER['PHP_AUTH_PW']);

}

В случае же неправильных настроек register_globals приемлемое решение и вовсе будет найти затруднительно, поэтому лучше - повторюсь - сразу работать при правильных настройках.

Замечания

Среди причин, по которым не стоит полагаться на "волшебные кавычки", есть ещё одна. Весьма маловероятная, но всё же. К "волшебным кавычкам" относится на самом деле не две директивы, а три. Третья - magic_quotes_sybase. Мало того, что она вместо слеша добавляет кавычку - так она ещё и отменяет действие magic_quotes_gpc. Если каким-то чудом обе эти директивы имеют статус 'on', то последняя не сработает! То есть, полагаясь на "волшебные кавычки", мы в этом случае получим все прелести неправильно составленных запросов. Вообще, чисто теоретически, надо учитывать наличие этой директивы, поскольку она преподносит ещё и такой сюрприз, как... изменение поведения функций addslashes и stripslashes! Если magic_quotes_sybase = on, то эти функции начинают вместо слеша добавлять и удалять одинарную кавычку соответственно.
Все приведенные примеры касаются только БД Mysql. Конкретные правила составления запросов могут отличаться для других СУБД, но общий принцип остается прежним:
- если API для работы с БД или сторонняя библиотека предоставляет специальные функции для составления запросов, и есть возможность их использования, то пользоваться в первую очередь надо ими.
- если таких функций нет, то следует искать в документации функции экранирования спецсимволов для этой СУБД.

ОПС: очень полезные ссылки:
Про волшебные кавычки на сайте PHP.NET
Про SQL-инъекции на сайте PHP.NET

Несколько материалов по SQL Injection:
http://www.securitylab.ru/45438.html
http://www.securitylab.ru/49424.html
http://www.nextgenss.com/papers/advanced_sql_injection.pdf

Примечание: формы
При выводе value в тегах input форм, слеши не помогают.
Чтобы текст в таком поле выводился целиком, value надо заключать в кавычки, а к выводимым данным применять функцию htmlspecialchars()
Пример:
<input type="text" name="name" value="<? echo htmlspecialchars($name,ENT_QUOTES)?>">
<textarea><? echo htmlspecialchars($text,ENT_QUOTES)?></textarea>

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

Анатолий Борисов, 29.06.18 18:34

А значения после ключевого слова AS тоже брать в обратные кавычки, т.е. objects.debt AS `sum `, users.id AS `from`

Ответ:
Здравствуйте, Анатолий!

На алиасы распространяются те же правила, что и на имена полей: для надежности лучше брать в обратные кавычки, но можно и без - если слово не явряется зарезервированным для mysql.
Виктор Андреевич, 14.08.17 19:22

Сейчас, немного поднаторев в этом вопросе, понимаю, какой глупый вопрос задал. Ведь JavaScript может быть изменен из панели, а значит есть вероятность того, что злоумышленник сможет крутить базой, как ему вздумается...
Виктор Андреевич, 14.08.17 18:31

Добрый день, уважаемый автор! Подскажите, возможна ли SQL-инъекция или другие угрозы при работе с базой через JavaScript и какие методы защиты использовать, если такие оасности существуют?
diagor, 24.06.17 18:06

привет зжелал вот так
$content=mysql_real_escape_string($_POST['cotent']);
mysqli_query($CONNECT, "INSERT INTO `news` VALUES ('', '$Info[id]', '".$content."', '', NOW(), '')");
ответ получаю пустой
проверка идет на добавления новости
шыто делать?
Дмитрий, 07.05.17 10:50

Добрый день!
Т.е. если использовать данный класс, то можно не обрабатывать запросы с помощью функций: htmlspecialchars(), trim() и тд?

Ответ:
Здравствуйте, Дмитрий!

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

Вообще, любую функцию всегда надо рассматривать отдельно от других, а не применять кучей, как будто это заговор от сглаза. Каждая функция имеет собственное назначение, по которому ее и надо применять.

Например trim() не имеет отношения к безопасности вообще.

А htmlspecialchars() защищает от xss, поэтому ее надо применять при выводе.

Если еще остались вопросы - пишите!
xss, 29.11.16 23:54

<script>alert('Hi')</script>

Ответ:
failed
Михаил, 29.03.16 18:32

Теоретически, эти настройки могут повысить безопасность скриптов, работаюющих с БД.

W: дабл-ю в слове "работаюющих".
Александр, 10.04.14 14:03

Хорошая статья.
Но придерживаюсь религии основывающейся на том, что данные нужно проверять сразу пока они ещё в $_GET и $_POST.

Ответ:
Это сильно устаревшая религия. "Проверка" данных не имеет никакого отношения к составлению SQL запросов. По десятку причин. Хотя бы потому, что данные могу т придти не только из GET. И вообще не из браузера. При этом данные могут иметь разную роль, которая неизвестна, "пока они ещё в $_GET и $_POST"
krogus, 26.02.14 00:03

случайно обнаружил наличие iframe кода на своем сайте - скачал сайт и базу на локальный сервер. Собственно говоря есть вопрос - в базе данных сайта из 20 страничек (joomla 2.5) -при открытии сохраненного дампа в блокноте обнаружилось 3020 ссылок такого вида: https:\\/\\/www.paypal.com - как это понимать, мне кажется большое количество слешей вначале неспроста.Ладно я понимаю - что есть два экранированных правильных слеша, а еще два? Кстати ссылки не закрыти от индексирования - RDS bar - их не видит.
Technobot, 31.01.14 04:48

Спасибо :)
Настя, 29.10.13 14:30

Отличная статья! Спасибо =)
игорь, 25.04.13 17:53

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

Ответ:
Боюсь, здесь не автор виноват, а читатель.
1. Специально в тексте выделено курсивом: Следует специально отметить: добавленные слеши НЕ идут в базу. Они нужны только в запросе. При попадании в базу слеши отбрасываются. Соответственно, распространенной ошибкой является применение stripslashes при получении данных из базы.

2. ответил раньше

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

4. ЦЕЛЫЙ РАЗДЕЛ в тексте, http://www.phpfaq.ru/slashes#prepared
игорь, 20.04.13 19:56

здравствуйте Автор, 4 простых вопроса: я вношу в базу запись состоящую из кавычки ' используя mysqli_real_escape_string($link... далее через командную строку в базе собственно и вижу только саму кавычку, я так понимаю что слыш просто не виден, но он там есть и я защищен от инъекции? 2 вопрос, надо ли вносить php_flag magic_quotes_runtime 0 в .htacess(версия php 5.4.0) или эта директива отрабатывает только на стороне сервера, а если уже отключена, то и отключать вручную не надо? 3 вопрос: мне нужно пользоваться mysqli_real_escape_string если я хочу помещать в базу кавычку, но использую для помещения в базу данных хранимую процедуру. и 4 вопрос: я так понимаю подготовленый запрос это то, который содержит в себе хранимая процедура, например (кусок кода:) insert в данном случае CREATE PROCEDURE...BEGIN
INSERT INTO`user`(`name`)
VALUES(userName);END ?

Ответ:
Ответ практически на все вопросы отрицательный. Я думаю, стоит перечитать статью ещё раз - на большую часть прямые ответы даны прямо в тексте. Для версии php 5.4.0 откючать волшебные кавычки не требуется - эта функциональность полностью удалена из языка в этой версии.
Иван, 15.12.12 23:18

Спасибо за статью
Виталий, 15.08.12 09:16

Статья очень помогла. Спасибо большое автору. Как уже писали до меня, побольше бы таких статей!
Хорошая статья, 09.08.12 13:05

Спасибо!
Когда уже мануал будете дописывать ?
сочувствующий, 02.11.11 19:59

>$mass = "SELECT title, keywords, description, text FROM categories WHERE id=\"$net\";

$mass = "SELECT title, keywords, description, text FROM categories WHERE id='".$_GET['net']."' ";
Koik, 10.10.11 19:38

Хотелось бы понять, использовании плейсхолдеров даёт 100%ю защиту и фильтровать данные больше никак не надо?
RNM, 15.07.11 13:14

HELP! HELP! Мне нужна помощь! Я тут новичок в PHP и у меня возникли сложности: я хочу, чтобы в этой строке $MessageToFile = "document.write($name)\n"; переменная name была в кавычках, но не получается браузер вводить ошибку. Что мне делать?! Хоть кто-то может помочь?!?!?
Андрей, 12.07.11 13:22

После использования mysql_escape_string() в дазу записываются все добавленные слеши... Почему?

Ответ:
потому что где-то в коде они добавляются ещё раз.
огород, 16.06.11 11:13

жесть девка хохотушка)))
Андрей, 04.06.11 12:25

Вопрос к автору статьи либо к людям которые знают наверняка.. Насчет особенностей работы с оператором LIKE и добовления к запросу дополнительных слэшей .. Представим ситтуацию что поиск может вестись по строке содержащей только буквы (т.е. только по словам без всяких символов) - не проще ли тогда не добовлять лишние слеши а просто перед прогоном искомого слова через mysql_real_escape_string(); прогонять его так же через preg_replace(); чтоб последний убирал все кроме букв ???? Спасибо за инфо.
Андрей, 03.06.11 17:12

Отличная статья , автору отдельное спасибо за нее , я бы сказал одна из самых понятных , внятных в инете . Побольше таких статей , побольше информации о защите БД и сайтов в частности .. СПАСИБО .
Николай %Drovocek%, 25.05.11 17:20

А не могли бы подробней рассказать про использование символа "%" как им пользоваться?
Сергей Теплов, 27.03.11 17:06

Спасибо за статью. Просмотрел несколько видео курсов по PHP. В каждом этой темы касаются. Но не встретил пока еще такого, как у вас развернутого описания. Для начинающего разбираться с PHP очень интересно. Первый раз встретил про обратные одинарные кавычкм.
Михаил, 18.02.11 17:11

я так понимаю, что с php 5.3 все magic_quotes всегда в off и тема медленно, но верно перестает быть актуальной как когда-то, да? :)

Ответ:
Тема "вредных" кавычек - да, по мере распространения новой версии РНР (что может занять до 10 лет :)
Тема экранирования символов в строках SQL тоже отходит в прошлое, с ростом популярности подготовленных выражений, но не совсем. многие предпочитают не использровать встроенные плейсхолдеры, а собирать запрос обычным порядком, применяя плейсхолдеры своей собственной разработки, результатом которых является всё равно экранирование в итоге. Так что тему рано списывать со счетов :)
1px, 31.01.11 16:35

Данная запись как-то влияет на что-то?

$net = $_GET["net"];

$mass = "SELECT title, keywords, description, text FROM categories WHERE id=\"$net\"";

Можно ли использовать кавычки в начале запроса и и в конце одни, как показано ниже.

$net = $_GET["net"];

$mass = "SELECT title, keywords, description, text FROM categories WHERE id=\"$net\";

Если да, а в моём примере ошибка то как правильно?

Ответ:
Очень невнятный вопрос.
Как правильно, написано в тексте статьи и мануале по синтаксису строк в РНР.
MIV, 09.11.10 23:04

Классная сатья, спасибо
Julliet, 08.10.10 17:52

как полная лохушка написала три echo)))

echo '<img src="'; echo $img; echo '">';

кто будет код читать - умрёт со смеху(((

Ответ:
Ну, в общем, да, это вопрос синтаксиса PHP.
Всего-то надо было заменить echo на точки:
echo '<img src="'.$img.'">';
или можно еще так
echo "<img src='$img'>";
или вот так - как раз со слешами
echo "<img src=\"$img\">";
а сам я пишу вот так
<img src="<?=$img?>>
предварительно закрыв PHP тег, поскольку весь вывод у меня идет только в шаблонах, которые представляют собой чистый HTML с небольшой примесью PHP кода.
Julliet, 08.10.10 17:48

Проблем с SQL-запросами не возникает. Уперлась сейчас в другое, но тоже с кавычками. а именно : надо вывести <img src="$img">, где $img - путь к изображению, типа "images/1.jpg". Самой смешно! А вот не получается и все. Простейшие вещи забыла.

Ответ:
Бывает :)
Путь, кстати, лучше писать абсолютный, например /images/1.jpg
Kellerman, 15.08.10 16:20

Спасибо за четкий материал!
adben, 25.07.10 19:12

СПАСИБО!!!!
Евгений, 20.01.10 17:44

Инъекция была бы невозможна, если бы в MySQL за столько лет додумались бы сделать параметры запросов, каковые существуют во всех остальных sql-серверах.

Ответ:
Не пробовали читать текст целиком?
"Параметры", во-первых, существуют и в MySQL, а во-вторых - они не панацея от инъекций.
Ghoul, 15.01.10 19:33

http://phpclub.ru/talk/showthread.php?postid=884473#post884473

IMHO, корректнее так:
<?php
$var = addCslashes($var, '_%\\');
$var = mysql_real_escape_string($var);

Ибо сначала мы должны экранировать спец. символы паттерна для LIKE, а уже потом — строковое значение.
WowanxXx5, 09.01.10 22:03

Спасибоза статью,вот может не в тему спрошу, но за что отвечает функция sqlesc
Дмитрий, 19.12.09 20:28

Спасибо, много почерпнул! Но остался вопрос. ОЧЕНЬ для меня важный. Можно ли использовать в шаблоне запроса несколько плейсхолдеров? Если не сложно, покажите пример, пожалуйста!
Заранее спасибо!
serg, 25.10.09 13:04

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

Ответ:
спасибо, поправил
DmAnsager, 30.09.09 00:33

Спасибо, помогло =)
Miclooha, 25.09.09 20:09

Господа, не бросайте работу над сайтом. Пожалуйста. Огромный Вам респект.
slogan, 28.02.09 10:35

Сделал вот такую штуку:
*****************************************8
$q_beg='"SELECT * FROM equip ';

if($equip_type!=''){$q_mid=" equip_type='".$equip_type."' ";}
if($work_field!=''){
if($q_mid!=''){$q_mid.="AND work_field='".$work_field."' ";}
else{$q_mid=" equip_field='".$work_field."' ";}
}
if($q_mid!=''){$q_str=$q_beg.' WHERE '.$q_mid.'"';}
else{$q_str=$q_beg.'"';}
echo($q_str.'<br>');

$q = mysql_query($q_str);
*************************************
Вот там где echo она правильно строку пишет со всеми нужными кавычками. но из MySQLя ничего не возвращает...

Ответ:
значит, в базе нет записей, удовлетворяющих запросу
slogan, 28.02.09 09:57

Хорошее изложение, пасиба!
Вот еще один вопрос важный:
Если у меня динамический запрос по нискольким переменым, некоторые из которых могут иметь пустое значение, как тогда?
Сейчас она у меня пытается выбрать те поля, где значение переменной ""(пусто), а должна выбирать все...

Ответ:
Динамически не добавлять незаполненные поля.
Dren, 24.01.09 03:40

изложено очень доступно, спасибо
rjcnbr, 16.12.08 16:05

Огромное спасибо за статью!
Действительно сильно помогла :)
"кавычки эти'
ыц, 05.12.08 02:23

Блин, стаж работы пхп рпограммером 1,5 года, не тупой и не валенок, сегодня с кавычками имел хороший секс. спасибо за magic_quotes_sybase ))))))
Иван, 17.10.08 20:02

Хорошая тема, но можно исправлять свои ошибки методом проб и ошибок.
Daniil, 06.10.08 12:48

Йо) амне НЕпомогла(
по последнему - ФОРМЫ.. Мне нада Наоборот .принять Значение с Кавычками...оно ловит до кавычек(( Подскажите!!

Ответ:
Надо сделать так, как здесь написано.
UpLinK, 04.10.08 21:41

Спасибо.
Demon, 28.08.08 09:28

Спасибо, я как раз искал подробную информацию по этой теме.
petr, 11.07.08 13:55

ОЧЕНЬ ПОМОГЛА!!!
Phobos, 15.06.08 03:03

Замечательная статья.
Большое спасибо!

19.10.24 14:08 Денис
Класс для безопасной и удобной работы с MySQL:
Очень удачный класс, частенько использую
read more

07.06.24 17:05 Юрий
Решение проблемы "Cannot add header information - headers already sent":
спасибо за ответы , помогло )))
read more

14.03.24 02:23 evgen_dev
Самые основы. Как работает PHP.:
"можете посоветовать хорошие php редактори/компилятори"

PhpStorm
read more

19.11.23 23:20 ALex
Класс для безопасной и удобной работы с MySQL:
Как доработать класс, чтобы осуществлялось переподключение при падении сервера Мускл? Типа...
read more

Написать комментарий

Пожалуйста, воздержитесь от посылки спама.
Сообщения, содержащие гиперссылки, проходят премодерацию.

Защита от SQL-инъекций

Не нашли ответ на свой вопрос?

Смотри также

Последние комментарии

Написать комментарий

Комментарии

Ответ:

Ответ:

Ответ:

Ответ:

Ответ:

Ответ:

Ответ:

Ответ:

Ответ:

Ответ:

Ответ:

Ответ:

Ответ:

Ответ:

Ответ:

Ответ: