preg_match() для проверки запросов

@BaNdErOzZz · Регистрация: 04.05.2010

Студворк — интернет-сервис помощи студентам

Добрый день. Скажите пожалуйста, правильным ли будет и рационально ли это: проверять GET и POST ТОЛЬКО при помощи регулярных выражений, функцией preg_match(). Например:

PHP
1
if(!preg_match('/^[a-zA-Z0-9_\-\.]{3,30}$/',$_GET['login']) header('location: activate.php?err=1');

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

@shafl · 20.11.2012, 15:33

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

@alpex · 20.11.2012, 22:35

от sql иньекций нужно защищаться екранированием передаваемых в базу строковых данных функциями по типу mysql_real_escape_string, и приведением к типу числовых данных типа (int)

@BaNdErOzZz · 20.11.2012, 22:45 **[ТС]**

Спасибо. Уже привел и экранировал . Просто в связи с маленьким опытом в голове устоялось, что:
mysql_real_escape_string - проверка и
preg_match - тоже проверка. Поэтому и возникают такие вопросы.

@alpex · 20.11.2012, 22:47

mysql_real_escape_string это не проверка это экранирование обратным слешом \ опасных данных для БД типа ' , " и т.д

@BaNdErOzZz · 20.11.2012, 22:50 **[ТС]**

Да. Знал но вот почему-то стало интересно по поводу preg_match(). Эта же функция осуществляет проверку согласно шаблону. Вот и подумал, а безопасно ли будет проверять все данные при помощи preg_match. Как оказалось, что НЕТ. Поэтому все исправил, вопросов больше нет )))

@spyeye · 20.11.2012, 22:56

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

@alpex · 20.11.2012, 23:02

Сообщение от spyeye

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

дайте хоть одну ссылку на такую статью

Добавлено через 34 секунды
и что по вашему полезно от sql иньекций?

@r3ntg3n · 21.11.2012, 00:11

Сообщение от alpex

и что по вашему полезно от sql иньекций?

prepared-запросы с параметрами или плейсхолдерами:

PHP
1
2
3
4
5
6
7
8
9
$db = new PDO('mysql:host=localhost;dbname=database', 'user', 'password');
$query = $db->prepare('SELECT * FROM `keys` WHERE `key`=:key');
$query->bindParam(':key', $key, PDO::PARAM_STR);
$query->execute();
 
$db = new MySQLi('localhost', 'user', 'password', 'database');
$query = $db->prepare('SELECT * FROM `keys` WHERE `key`=?');
$query->bind_param('s', $key);
$query->execute();

Ну, и конечно же валидация данных.

@alpex · 21.11.2012, 00:40

ИМХО prepared-запросы с параметрами или плейсхолдерами: нужны для выполнения множества однотипных запросов, а по защите от sql-иньекций они не отличаются от правильно использованной функции mysql_real_escape_string, или у вас есть какое то документальное подтверждение что это не так?

Добавлено через 2 минуты
вы говорили что в нете очень много статей на эту тему, что escape_string не защищает от иньекции, так вот что я не нашел, может дадите ссылку на хоть одну подобную статью?

@Василий Макогон · 21.11.2012, 01:51

Сообщение от alpex

дайте хоть одну ссылку на такую статью

http://phpfaq.ru/slashes

@alpex · 21.11.2012, 02:21

Сообщение от Василий Макогон

http://phpfaq.ru/slashes

В этой статье нет ни слова о том что escape string не предотвращает sql иньекции

@Schtrich · 21.11.2012, 02:54

Сообщение от alpex

В этой статье нет ни слова о том что escape string не предотвращает sql иньекции

Как на счет PDO или MySQLi?

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

@Василий Макогон · 21.11.2012, 02:55

он не дырявый, его просто никто не поддерживает больше

@Schtrich · 21.11.2012, 03:00

Сообщение от Василий Макогон

он не дырявый, его просто никто не поддерживает больше

Ну...

@alpex · 21.11.2012, 03:01

я не говорю что mysql нужно использовать а pdo,mysqli нет, или что подготовленные запросы это плохо, просто здесь было высказано мнение что функции типа escape_string не могут в полной мере защитить от sql-иньекции, вот мне и интересно на основании чего сделаны такие выводы.

KOPOJI · 21.11.2012, 09:27

единственное что возможно, что mysql_real_escape_string() не экранируют символы % и _
Все остальное они успешно экранируют. Возможно обойти addslashes(), подставляя символы из другой кодировки. Но в UTF-8 эта уязвимость отсутствует, по причине того что символ должен иметь значение больше 128 в десятичном виде, а эти символы получатся меньше

@r3ntg3n · 21.11.2012, 15:11

Сообщение от alpex

ИМХО prepared-запросы с параметрами или плейсхолдерами: нужны для выполнения множества однотипных запросов, а по защите от sql-иньекций они не отличаются от правильно использованной функции mysql_real_escape_string, или у вас есть какое то документальное подтверждение что это не так?

Хм, интересно, а что вы скажете об этом

KOPOJI · 21.11.2012, 15:51

r3ntg3n, а где же использование плэйсхолдеров в мускуле самом? В mysqli и PDO вы их используете, а тут что-то забыли.. в старом мускуле "заместо этого" mysql_real_escape_string() ( в PDO аналог $dbh->quote() )

Добавлено через 7 минут
тогда и проверяйте одинаково везде

PHP
1
2
$res = $db->prepare('SELECT * FROM `keys` WHERE `key`=\'\' OR 1');
$res->execute();

@r3ntg3n · 21.11.2012, 15:52

KOPOJI, да, функция "оборачивает" кавычками и экранирует символы, но вот что говориться в мануале:

If you are using this function to build SQL statements, you are strongly recommended to use PDO:

repare() to prepare SQL statements with bound parameters instead of using PDO::quote() to interpolate user input into an SQL statement. Prepared statements with bound parameters are not only more portable, more convenient, immune to SQL injection, but are often much faster to execute than interpolated queries, as both the server and client side can cache a compiled form of the query.

Not all PDO drivers implement this method (notably PDO_ODBC). Consider using prepared statements instead.

Новые блоги и статьи Все статьи Все блоги /
Thinkpad X220 Tablet — это лучший бюджетный ноутбук для учёбы, точка. Programma_Boinc 23.12.2025 Thinkpad X220 Tablet — это лучший бюджетный ноутбук для учёбы, точка. Рецензия / Мнение Это мой обзор планшета X220 с точки зрения школьника. Недавно я решила попытаться уменьшить свой. . .	PhpStorm 2025.3: WSL Terminal всегда стартует в ~ and_y87 14.12.2025 PhpStorm 2025. 3: WSL Terminal всегда стартует в ~ (home), игнорируя директорию проекта Симптом: После обновления до PhpStorm 2025. 3 встроенный терминал WSL открывается в домашней директории. . .	Как объединить две одинаковые БД Access с разными данными VikBal 11.12.2025 Помогите пожалуйста !! Как объединить 2 одинаковые БД Access с разными данными.	Новый ноутбук volvo 07.12.2025 Всем привет. По скидке в "черную пятницу" взял себе новый ноутбук Lenovo ThinkBook 16 G7 на Амазоне: Ryzen 5 7533HS 64 Gb DDR5 1Tb NVMe 16" Full HD Display Win11 Pro	Музыка, написанная Искусственным Интеллектом volvo 04.12.2025 Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .
От async/await к виртуальным потокам в Python IndentationError 23.11.2025 Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .	Поиск "дружественных имён" СОМ портов Argus19 22.11.2025 Поиск "дружественных имён" СОМ портов На странице: https:/ / norseev. ru/ 2018/ 01/ 04/ comportlist_windows/ нашёл схожую тему. Там приведён код на С++, который показывает только имена СОМ портов, типа,. . .	Сколько Государство потратило денег на меня, обеспечивая инсулином. Programma_Boinc 20.11.2025 Сколько Государство потратило денег на меня, обеспечивая инсулином. Вот решила сделать интересный приблизительный подсчет, сколько государство потратило на меня денег на покупку инсулинов. . . .	Ломающие изменения в C#.NStar Alpha Etyuhibosecyu 20.11.2025 Уже можно не только тестировать, но и пользоваться C#. NStar - писать оконные приложения, содержащие надписи, кнопки, текстовые поля и даже изображения, например, моя игра "Три в ряд" написана на этом. . .	Мысли в слух kumehtar 18.11.2025 Кстати, совсем недавно имел разговор на тему медитаций с людьми. И обнаружил, что они вообще не понимают что такое медитация и зачем она нужна. Самые базовые вещи. Для них это - когда просто люди. . .

@shafl 258 / 147 / 37 Регистрация: 24.01.2011 Сообщений: 427
	20.11.2012, 15:33
	рационально не проверять, а экранировать пользовательские данные, так как проверку можно обойти при большом желании. 1

@alpex 603 / 578 / 103 Регистрация: 16.07.2012 Сообщений: 1,762
	20.11.2012, 22:35
	от sql иньекций нужно защищаться екранированием передаваемых в базу строковых данных функциями по типу mysql_real_escape_string, и приведением к типу числовых данных типа (int) 1

@BaNdErOzZz 0 / 0 / 1 Регистрация: 04.05.2010 Сообщений: 12
	20.11.2012, 22:45 [ТС]
	Спасибо. Уже привел и экранировал . Просто в связи с маленьким опытом в голове устоялось, что: mysql_real_escape_string - проверка и preg_match - тоже проверка. Поэтому и возникают такие вопросы. 0

@alpex 603 / 578 / 103 Регистрация: 16.07.2012 Сообщений: 1,762
	20.11.2012, 22:47
	mysql_real_escape_string это не проверка это экранирование обратным слешом \ опасных данных для БД типа ' , " и т.д 0

@BaNdErOzZz 0 / 0 / 1 Регистрация: 04.05.2010 Сообщений: 12
	20.11.2012, 22:50 [ТС]
	Да. Знал но вот почему-то стало интересно по поводу preg_match(). Эта же функция осуществляет проверку согласно шаблону. Вот и подумал, а безопасно ли будет проверять все данные при помощи preg_match. Как оказалось, что НЕТ. Поэтому все исправил, вопросов больше нет ))) 0

@spyeye 31 / 31 / 2 Регистрация: 06.08.2012 Сообщений: 155
	20.11.2012, 22:56
	В любой более менее практичной статье будет написано, что экранирование бесполезно при SQL иньекциях. 0

@alpex 603 / 578 / 103 Регистрация: 16.07.2012 Сообщений: 1,762
	21.11.2012, 00:40
	ИМХО prepared-запросы с параметрами или плейсхолдерами: нужны для выполнения множества однотипных запросов, а по защите от sql-иньекций они не отличаются от правильно использованной функции mysql_real_escape_string, или у вас есть какое то документальное подтверждение что это не так? Добавлено через 2 минуты вы говорили что в нете очень много статей на эту тему, что escape_string не защищает от иньекции, так вот что я не нашел, может дадите ссылку на хоть одну подобную статью? 0

@Василий Макогон 270 / 226 / 11 Регистрация: 20.04.2012 Сообщений: 817
	21.11.2012, 02:55
	он не дырявый, его просто никто не поддерживает больше 0

@alpex 603 / 578 / 103 Регистрация: 16.07.2012 Сообщений: 1,762
	21.11.2012, 03:01
	я не говорю что mysql нужно использовать а pdo,mysqli нет, или что подготовленные запросы это плохо, просто здесь было высказано мнение что функции типа escape_string не могут в полной мере защитить от sql-иньекции, вот мне и интересно на основании чего сделаны такие выводы. 0

KOPOJI Почетный модератор 16844 / 6724 / 880 Регистрация: 12.06.2012 Сообщений: 19,967
	21.11.2012, 09:27
	единственное что возможно, что mysql_real_escape_string() не экранируют символы % и _ Все остальное они успешно экранируют. Возможно обойти addslashes(), подставляя символы из другой кодировки. Но в UTF-8 эта уязвимость отсутствует, по причине того что символ должен иметь значение больше 128 в десятичном виде, а эти символы получатся меньше 0