Защита от скули

Вот решил углубится в тему защиты MySQL. Всегда просто делал так при каких либо запросах в MySQL:

PHP:

$vvodimye_dannye = $_POST['dannye'];
$vvodimye_dannye = str_replace("'","&!#39;",$vvodimye_dannye);
$primer_zaprosa = "INSERT INTO blabla (pole) VALUES ('".$vvodimye_dannye."')";

Это корректно? Или есть способы обойти?

p.s. &!#39; - bez vosklicatelnogo znaka, a to bulka ego perevodit v simvol

 

Используйте mysql_escape_string() или mysql_real_escape_string()
Ваша защита никчемная.

 

скажи обход плс

 

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

 

В хелпе на php.net написано, какие сомволы экранируют функции, которые я указал.

Еще один из вариантов (пример):
Есть запрос "select name from users where id = $id". Предположим, что в $id нет символа одинарной кавычки. Тогда можно сделать $id = "-1 union select pass from admin", и, так как пользователя с id = -1 не существует, будет выведен пароль администратора. В этом случае необходимо проверять, число ли передано, например, так:

PHP:

if(!preg_match('/^\d+$/', $id) || $id == 0)
  die('incorrect id');


 

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

 

https://forum.antichat.ru/thread30641.html

 

походу надо реал юзать...

 

Достаточно, эти функции не меняют содержимого строк, т.е. одинарная кавычка в поле таблицы БД так и будет одинарной кавычкой. Просто она будет экранирована только перед добавлением строки в базу.

Да, эта функция может обрабатывать строку с учетом кодировки соединения с MySQL.

 

Советую еще обратить внимание на magic_quotes_gpc. Если эта директива включена, некоторые символы (одинарная кавычка, обратный слеш, нулбайт) будут уже экранированы при получении строки скриптом. Чтобы убрать лишний обратный слеш, нужно воспользоваться stripslashes():

PHP:

if(function_exists('get_magic_quotes_gpc') && get_magic_quotes_gpc())
{
  $my_string = stripslashes($my_string);
}

//далее - добавление $my_string в базу


В PHP 6 эта директива убрана и символы не экранируются, пример выше это также учитывает.

 

А еще запросы можно по длине резать,например айдишники больше 9 символов я слабо представляю, также как и инъекцию меньше 9 символов.

 

Ну тогда

PHP:

 if(!preg_match('/^\d{1,9}$/', $id) || $id == 0)
  die('incorrect id');


 

Чего вы советуете какую то чушь.
Для числовых значений int или intval, для строковых mysql_real_escape_string, и экранировать % и _ в случае использования like, вот и все.

 

int и intval пропустят 0 и отрицательные значения. Приведенная выше регулярка не пропустит.

 

mysql_real_escape_string() зачем велосипед?

 

И что, что она пропустит эти значения, как ты с помощью этого проэксплуатируешь уязвимость?

 

Не проэксплуатируешь, но тем не менее, реализовывать проверку через регулярку или использовать intval - какая разница? Кому как нравится, тот так и делает, и оба решения чушью не являются. Если предварительно проверять id, то можно выплюнуть пользователю ошибку еще до выполнения запроса.

Мы говорим о числовых значениях.

 

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

 

Прочитай посты, об этом речь шла

 

zachem?