защиты от SQL Injection

[tolik777]

Скажите пожалуйста для защиты от SQL Injection достаточно ли везде в запросах использовать mysql_escape_string()?
Если нет, то можете привести пример, обходящий эту функцию?

 

[neko]

зачем эти все извращения
надо прослешить кавычки и все.

поскольку в mysql вообще любой тип суется в кавычки.

 

[camka]

[sql]
select password from user where id=mysql_escape_string("1 or 1");
[/sql]

 

[neko]

и?

 

[GeT]

Просто прослешить кавычки не всегда достаточно...
Скажем, если есть дырка на Injecion то юзера и хеш пароля можно узать и без всяких кавычек.
Вообще, если получаешь от юзера какие-либо данные, их надо проверять. Эсли это, скажем, целочисленные значения, их надо intval().
Если это строки, тут уже погеморней, ты должен сам знать что тебе должны передавать и исходя из этого отсекать все лишнее.

 

[tolik777]

neko
Ну кавычки понятно. Но все же я так понял что mysql_escape_string() достаточно. Правильно? Просто у меня уже везде используется ф-ия mysql_escape_string(). Защитит ли она или нет?
camka
пример непонятен.

 

[fixxxer]

кавычки не везде можно поставить. в LIMIT/OFFSET, например, нельзя.

 

[neko]

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

я это приму когда мне покажут пример.
все что до сих по по этому теме было высказанно это нагромождения бессмысленных конструкций для защиты от бог знает чего.

 

[camka]

Я привел пример, когда _одно_лишь_ экранирование не помогает от sql injection'ов.

 

[neko]

camka
это быссмысленный пример.
причем к теме он того, не относится

 

[camka]

Вопрос был - "достаточно ли одной функции mysql_escape_string для защиты от sql injection. И если нет, то пример, когда её может быть недостатьчно"

Мой пример и демонстрирует, когда при использовании сей функции возможна атака подобного типа.

 

[neko]

camka
sql injection это вставка в запрос sql конструкций которые там программистом, скажем так, не предпологались.
поэтому еще раз, твой пример к вопросу отношения не имеет.

чтобы было понятней, я приведу пример попроще.
допустим надо вернуть пользователю васе его пароль
select password from users where name = "{$_POST['myname']}"
вася конечно может испортить нашу форму и передать не свое имя.
но это не будет является sql injection.

это совсем другая проблема.

 

[camka]

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

 

[neko]

это где я такое предположил?
я ему это порекоммендовал.

просто потому что это mysql который все что угодно сьест в виде строки и потому что это проще всего.

 

[GeT]

neko
http://твой_сайт.ru/id=1+union+select+null,..,mysql.user.password,null,..,null+FROM+mysql.user+LIMIT+0,1/*

Количество null надо подобрать.
Данная конструкция объединяет результаты 2 запросов.
Соответственно, нужно узнать, какое из полей выводится на экран и вместо него вставить mysql.user и будет тебе щастье.
Как видишь, кавычки тут нигде не используются.
АХ ДА! Для тех, кто любит выводить строковые значения! Есть в MySQL функция char, которая ASCII-коды преобразует в символы. Работает вот так char(34,56,77).

P.S. Данная вещь работает в версиях MySQL выше 4ой.
P.P.S. Можешь не принимать сколько угодно, легче тебе от этого не станет.
P.P.P.S. Есть еще вариант, когда после запроса не происходит никакого вывода. Тогда можно просто подобрать (это уже более сложно, но тоже работает)

 

[camka]

Автор оригинала: neko
поскольку в mysql вообще любой тип суется в кавычки.

Это было рекомендацией? Больше похоже на утверждение, которое, причем, можно понять двояко: как "возможно заключить любой тип в кавычки и mysql не выдаст ошибку парсинга" или "програмист должен сувать все параметры, пришедшие от пользователя, в кавычки, прежде чем послать строку запроса mysql серверу"

И, кстати, когда я писал свой пост, твоего еще не было.

 

[Фанат]

tolik777
достаточно
не можем
читать PHP FAQ: \"Кавычки \". Cоставление запросов mysql, слеши, экранирование кавычек.

 

[neko]

> Как видишь, кавычки тут нигде не используются.

что значит кавычки не используется.
я же сказал уже, все брать в кавычки
добро пожаловать в mysql.

WHERE id = "{$_POST['id']}"

 

[camka]

Фанат
Не достаточно!!!
Для того, чтобы было достаточно, необходимо заключать все параметры, а не только строковых типов, в кавычки. Этого же нигде, включая и приведенный тобой ресурс, не указано. Есть лишь рекомендация

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

Прямого же указания, что так и только так надо делать вы нигде на встретите.

Итог:

Использование одной лишь функции myql_escape_string достаточно для защиты от sql_injection аттаки лишь в том случае, когда любые передаваемые пользователем параметры (где возможно) обособляются кавычками, и где невозможно, данные отдельно проверяются на опасность (как в описаной вами функции LIMIT).

P.S. Кроме всего прочего, (это не совсем про sql injection, но близко) в случае если в скрипте присутствует поиск типа LIKE и вы не желаете позволять пользователю самому определять шаблон поиска, необходимо удваивать специальные символы "%" и "_".
Например, если у вас доступен поиск по какому-то полю, учитывая заданный префикс ( WHERE some_field LIKE '{$preescaped_user_input}%' )
если пользователь введет специальный символ % в начало искомой фразы, то при определенный, но не невозможный условиях, запрос может затянуться на долго, чего бы вам, я полагаю, не хотелось.

 

[Falc]

tolik777
Если есть возможность использовать mysqli то лучше использовать его и bind переменных.
Если нет такой возможности, то числовые переменые приводим к числам ( (int),(float) ), а строковым делаем mysql_escape_string()

neko
>>WHERE id = "{$_POST['id']}"
Если кавычки не прослешены то такое не пройдет.