Только 2 способа защиты данных, идущих от пользователя?

[silvek]

Только 2 способа защиты данных, идущих от пользователя?

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

Это правда, что их всего два:

1) Для типа INT - intval($data)
и
2) Для строк - mysql_real_escape_string($data)?

Тогда во втором случае легко sql_injection способами вида chat_decode(%23%12%21%12) и т.п.

Существуют ли еще способы?

 

[Апокалипсис]

FAQ читать уже не модно?
http://phpfaq.ru/slashes#mysql

 

[silvek]

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

Глубже тему раскрыть можно?
Инъекции делают кодированием и обратным раскодированием строк и т.п.

 

[kruglov]

silvek
"Вы думаете, в ЦК дураки сидят?" ©

Какой еще char_decode, если вокруг кавычки стоят?

 

[Pigmeich]

silvek

Тогда во втором случае легко sql_injection способами вида chat_decode(%23%12%21%12) и т.п.

прошу продемонстрировать injection

 

[WP]

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

 

[silvek]

Ок, значит панацея следующая.
Там где возможно - делать заранее предустановленные варианты.
Там, где нужен реально динамический запрос делаем так:
1) выясняем какие данные типа INT и поголовно их intval;
2) любые не-INT данные в ysql_real_escape_string().

Все?

 

[zerkms]

1) выясняем какие данные типа INT и поголовно их intval;

я бы, скорее, отнёс сюда все числовые значения, а не только целые

 

[phprus]

zerkms

я бы, скорее, отнёс сюда все числовые значения, а не только целые

А если у нас поле в базе имеет тип с плавающей точкой, то если про'intval'ить то, что в него будет записано то мы как минимум потеряем дробную часть, так что ко всем числовым значениям применять intval нельзя.

 

[zerkms]

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

 

[Sluggard]

выясняем какие данные типа INT и поголовно их intval;

Дело вкуса. Я предпочитаю все данные от пользователя ескейпить и брать в кавычки. Если приходит запрос:
/news/12pp/
что разумнее, сообщать "новость не найдена" или подсовывать новость с id=12?

 

[Фанат]

silvek
Ты тебе надо почитать, что по ссылке написано. А не 2 секунды носом повертеть.
Судя по твоим репликам, ты ничего не понял.
Предустановленные варианты используются не там, где нереально динамический запрос, а там, где они нужны. В любом запросе.
никакой заменой escape_string они не являются.

Вообще, в твоем перечислении логики нет никакой. Ты сам посмотри, что за дурость ты пишешь:

Там, где возможно - заранее предустановленные варианты. Где невозможно - escape_string

Если хоть один из этих двух вариантов не работает, то грош цена этой "защите". А если хоть один работает, то тогда второй нафиг не нужен.

поэтому прочти внимательно, и доложи, как понял