PHP+MySQL и SQL-Injection

← →
ProgRAMmer Dimonych © (2007-07-29 18:25) [0]

Знаю, что об этом много написано в интернете, прочитал всё, что нашёл. Но хотелось бы более по-человечески, что ли.

1. Достаточно ли экранировать тольком кавычки, если данные, передаваемые пользователем, используются только в виде

WHERE FieldName="Что-то там и полученные данные"

или

LIMIT <Числа, которые проверяются перед использованием>

2. Правда ли, что регулярные выражения тормозят интерпретатор PHP?

Надеюсь на Ваше понимание.

P.S. Хочется найти решение, позволяющее безопасно работать с БД, но так, чтобы при этом нужно было как можно меньше обрабатывать после чтения из БД.

P.P.S. Пробовал пользовать HTMLSpecialChars() с параметром ENT_QUOTES, но наткнулся в интернете на то, что есть ещё всякие # -- и прочие радости. Следует ли их бояться в указанном мной случае?

← →
ya00011 (2007-07-29 18:40) [1]

mysql_escape_string как раз экранирует все что надо
числа полученные от пользователя тоже экранируй им и вписывай в запрос в кавычка (<"4"), либо как вариант можно так: $id=(int)$_POST["id"]; mysql_query("SELECT * FROM `t` WHERE `id`=$id")

Регулярные выражения, если они грамотно составлены, наоборот быстрее работают, чем ручной анализ строки.

ЗЫ... Всегда экранируй полученные данные от пользователя, даже те, которые он выбирает с помощью поля <select>...</select>

← →
ProgRAMmer Dimonych © (2007-07-29 20:00) [2]

> ya00011 (29.07.07 18:40) [1]
> mysql_escape_string как раз экранирует все что надо
> числа полученные от пользователя тоже экранируй им и вписывай
> в запрос в кавычка (<"4"), либо как вариант можно так: $id=(int)$_POST["id"];
> mysql_query("SELECT * FROM `t` WHERE `id`=$id")

Понятно, значит, это в большом интернете написано правильно. Возвращать БД всё будет в нужном виде, так ведь? Т.е. без экранирования?

> Регулярные выражения, если они грамотно составлены, наоборот
> быстрее работают, чем ручной анализ строки.

Понял.

> ЗЫ... Всегда экранируй полученные данные от пользователя,
> даже те, которые он выбирает с помощью поля <select>...
> </select>

Учту.

← →
ProgRAMmer Dimonych © (2007-07-29 20:06) [3]

В продолжение темы, так сказать, для общего развития...

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

Т.е. не имея ничего против MySQL_Real_Escape_String() (она в отличие от той, что без Real, с правильной кодировкой пашет), я хотел бы узнать о том, насколько теоретически возможно обойтись не-MySQL функциями. Блин, да что ж такое: всё как-то сложно говорю :(

Короче говоря, если получаемые от пользователя данные используются только с WHERE или LIMIT (в последнем случае - заранее подготовленные), хватит ли экранирования только кавычек?

← →
antonn © (2007-07-29 21:30) [4]

я экранирую \x00, \n, \r, \, ", " and \x1a

← →
ya00011 (2007-07-29 21:30) [5]

MySQL_Real_Escape_String и MySQL_Escape_String, насколько я знаю выполняются Native кодом на стороне php. Тоесть не используют для своей работы MySQL сервер, а значит работают быстрее любых твоих функций написанных на PHP. непонятно, почемуто такое отвращение к ним.

По идее экранируются только кавычки и символ экранирования: " " \

Если ты хочешь использовать константу в запросе, то не стоит заранее ее экранировать, а поступить примерно так:
$cText="o"key";
...
...
...
$my_text=mysql_escape_string( empty($_POST["text"])?$cText:$_POST["text"] );
mysql_query("SELECT * FROM `texts` WHERE `text`="$my_text" ");

Кстати, еще один подвох который тебя ожидает. PHP может быть так сконфигурирован, что все входные параметры (Get, Post и Cookie) автоматически экранируются (т.е. подвергаются выполнению функции addslashes()). Поэтому это дело нужно присекать!

← →
DillerXX © (2007-07-29 22:20) [6]

> Поэтому это дело нужно присекать!

Как узнать что он сконфигурирован именно так?

Так что на счёт шарпа (#)? Получается его не стоит опасаться, а всего лишь юзать функцию MySQL_Escape_String ?

← →
ProgRAMmer Dimonych © (2007-07-30 00:51) [7]

> ya00011 (29.07.07 21:30) [5]
> MySQL_Real_Escape_String и MySQL_Escape_String, насколько
> я знаю выполняются Native кодом на стороне php. Тоесть не
> используют для своей работы MySQL сервер, а значит работают
> быстрее любых твоих функций написанных на PHP. непонятно,
> почемуто такое отвращение к ним.

Real просит идентификатор соединения с БД и учитывает настройки кодировки.

> Кстати, еще один подвох который тебя ожидает. PHP может
> быть так сконфигурирован, что все входные параметры (Get,
> Post и Cookie) автоматически экранируются (т.е. подвергаются
> выполнению функции addslashes()). Поэтому это дело нужно
> присекать!

Об этом предупреждён. Но хостер, вроде, нормальный, Денвер - тоже матом не кроет.

> DillerXX © (29.07.07 22:20) [6]
> > Поэтому это дело нужно присекать!
> Как узнать что он сконфигурирован именно так?
> Так что на счёт шарпа (#)? Получается его не стоит опасаться,
> а всего лишь юзать функцию MySQL_Escape_String ?

Точно. Этот вопрос остаётся.

И ещё два. Позволю себе снова понаглеть и затребовать ответ на такой вопрос.

1. Есть запрос типа

SELECT <Чего-то там> FROM <Откуда-то там> WHERE <Чего-то там>="<Выражение с переменной>"

где <Выражение с переменной> содержит строку-переменную, полученную от пользователя. Достаточно ли заэкранировать кавычки, чтобы не работали другие спецсимволы SQL?

2. Тот же вопрос, но для случая

<Куча слов> LIMIT <Какой-нибудь лимит, заданный заранее вычисленной переменной>

где заранее вычисленная переменная - однозначно число и число правильное. Стоит ли в этом случае опасаться инъекций.

← →
antonn © (2007-07-30 01:23) [8]

имхо, стоит везде опасаться вторжения - проще все перепроверить и не бугать в случае чего перепроверять все с начала...

← →
_XXX_ (2007-07-30 03:42) [9]

> Кстати, еще один подвох который тебя ожидает. PHP может
> быть так сконфигурирован, что все входные параметры (Get,
> Post и Cookie) автоматически экранируются (т.е. подвергаются
> выполнению функции addslashes()). Поэтому это дело нужно
> присекать!

Для этого есть функция - get_magic_quotes_gpc(). Если true - то настроено автоматически экранировать.

← →
VirEx © (2007-07-30 12:33) [10]

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

← →
_XXX_ (2007-07-30 12:47) [11]

> [11] _XXX_ (30.07.07 12:47)
>
> > VirEx © (30.07.07 12:33) [10]
>
> error_reporting(0)
> ?

ну естественно путей много, из которых 99 я не знаю :)

> [12] Юрий © (30.07.07 12:48)
> > [10] VirEx © (30.07.07 12:33)
>
> Ага, display_errors, собственные обработчики ошибок - всё
> это сделано для красоты.

ну так и о чем речь, для отладки можно оставить, а для работы - не показывать (ошибки)

> [13] VirEx © (30.07.07 13:13)
> ну так и о чем речь, для отладки можно оставить, а для работы
> - не показывать (ошибки)

Речь была про @. Скрипт с расставленными в каждом месте @ - убожество, тем более если задачу можно решить другими путями.

PHP+MySQL и SQL-Injection Найти похожие ветки