Защита от SQL инъекций

Если все данные для БД я буду обрабатывать функцией mysql_escape_string даст ли это 100% гарантию невозможности проведения SQL-inj через вводимые данные или нужно использовать что то ещё?

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

(Отредактировано автором: 04 Декабря, 2010 - 18:44:44)

Помимо прочего.
Пользователю, от которого работает скрипт, надо выдать минимум прав.
Если не нужно ничего записывать в базу, то права только на SELECT.

Увы, это скрипт регистрации и прав нужно много
Так даст это гарантии безопасности?

Большинству скриптов с головой хватает select, insert, update и иногда delete. А для регистрации - и вовсе только select и insert, так что нифига не много.

Да, использование mysql_real_escape_string обезопасит запросы от инъекций.

-----
PostgreSQL DBA

Использования предполагаемой вами функции mysql_escape_string является достаточным для осуществления перевода информационных полей на более высокий уровень экранирования и фактической защиты от потенциальной SQL-инъекции - однако более предпочтительным вариантом является обеспечение указанных действия посредством функции mysql_real_escape_string с учетом кодовых таблиц представления данных - дело в том что при использовании различных кодировок соединения с БД и локального представления информациооных полей как unicode и ascii - может привести к возможност передачи недопустимого ascii-символа как часть более полного unicode-символа не являющегося запрещенным

-----
Сделать можно все что угодно - нужно только старание, терпение и хороший поисковик
Безлимитный web-хостинг от 15 рублей за 40 МБ дискового пространства - http://ihost[dot]oks71[dot]ru/

А как выполнить обратное преобразование текста перед выводом на экран? А то выглядит некрасиво.

Главное убрать file_priv и шелл точно не зальютчерез иньекцию.
Да и на delete тоже права со многих скриптов можно убрать!

Обратное преобразование с чего? При выводе на экран пользовательских даных нужно не забывать про функцию htmlspecialchars()

-----
Если вы хотя бы 3-4 раза не решите всё выкинуть и начать заново - вы явно что-то делаете не так.

Это само собой, но как убратьлишние слеши после mysql_real_escape_string при выводе на экран?

А где ты их увидел?

Ну функция экранирует спец символы, например кавычку слешем и они записываются в базу \' или я не прав?

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

-----
PostgreSQL DBA

Tmin10 а в чем смысл экранирования, как ты думаешь?
Смотри: у тебя строковое поле. Когда записываешь вещи в строковые поля, то эти вещи ты берешь в кавычки. field = 'value'. Если тебе захочется, чтоб в значении были кавычки (o'connor), то написать field = 'o'connor' ты не можешь (угадай почему). Вот экранирование кавычки (\') - это просто способ сделать ее обычным символом в контексте sql запроса. Обычно кавычка в запросе - это специальный символ - ограничитель значения.
А sql-инъекция - это прием заключающийся в том, что злой человек вставляет этот ограничитель и пишет после него нужную ему часть запроса.