Форум PHP

<?php function post_filter($post) {            if (get_magic_quotes_gpc())     {         $post = stripslashes($post);     }     else     {         $post = mysql_escape_string($post);     }     return $post; } ?>

так кавычки не экранируются, убираю проверку get_magic_quotes_gpc() - mysql_escape_string экранирует...
получается что get_magic_quotes_gpc включена, но она не работает или я что-то не так понял...

похоже, что не так )
если опция magic_quotes включена, то кавычки УЖЕ экранируются (слешем).
Вы делаете проверку и если опция включена, Вы убираете эти самые "поставленные автоматом" слеши.
А если опция не включена, то Вы просто экранируете кавычки и строка возвращается со слешами.

Вы чего хотите добиться то? )

ааааа...фак! как же я ступил ))))

значит по дядьке Трианону такой вариант будет правильным:

<?php function post_filter($post) {     if (get_magic_quotes_gpc())     {         $post = stripslashes($post);     }          $post = mysql_escape_string($post);          return $post; } ?>

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

тут замышляли :)
http://softtime.ru/forum/read.php?id_forum=1&id_theme=64715&page=1

Ух надает, придет. Подзатыльников.
Нельзя данные на входе mysql_escape_string() обрабатывать. Смысл то какой? Убрали бэкслэши и тут же поставили. Эта функция только для работы с MySQL.
Хотя тут не видно, что это $_POST массив.

да, что-то я прочел и немного впал в ступор.. )
все-таки подождем когда придет Он и все разрулит ))))

а, если, как я понял от Николая, речь идет о данных, которые будут использоваться НЕ в запросах, тогда вроде ясно, а если нет - то не ясно ))

надеюсь что придёт....
использую так:

$_POST["pass"] = post_filter($_POST["pass"]);

только для пост и только перед вставкой в запрос...

Если
>только перед вставкой в запрос...
то правильно, а вот
>только для пост
не правильно. $_GET и $_COOKIE тоже нужно так обрабатывать.

само собой :)
но т.к я из $_GET не беру строковые данные для вставки в базу, а только числовые, то зачем?

разве

<?php $_GET["id"] = intval($_GET["id"]);

не достаточно?

по сути достаточно

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

Я в соседней теме написал в частности следующее.
mysql_escape_string() вызывается непосредственно перед обрамлением текстовых строк апострофами, при формированнии текста SQL-запроса - во всех случаях.
Причем этот пост Вы видели и на него отреагировали.
Теперь Вы пишете
>значит по дядьке Трианону такой вариант будет правильным:
> $post = mysql_escape_string($post);
> return $post;

где есть вызов mysql_escape_string() и нет ни звука ни про апострофы ни про sql-запросы.

Внимание, вопрос. Лично Вам. Ответьте, пожалуйста.

Кем я Вас должен считать?

-

вам виднее :)

просто хотел сделать это одной функцией...
а чем плох вариант снизу?

<?php // обрабатываем $_POST["pass"], функция trim и т.д тп. $_POST["pass"] = post_filter($_POST["pass"]); // с $_POST["pass"] больеш ничего не делаем, получается что работа mysql_escape_string как раз перед запросом ! // здесь если надо делаем что-то другое, $_POST["pass"] уже не трогаем INSERT INTO ..... VALUES(...., '$_POST["pass"]', ...) // ....

Он плох тем, что ориентирован на очень конкретную ситуацию. По-нормальному было бы:
- сделать функцию, которая исправляет $_POST, $_GET, $_COOKIE, $_REQUEST от бекслешей, поставленных magic_quotes_gpc.
- не портить чистое значение переменной-источника данных (в данном случае $_POST['pass'] (вводить какую-нибудь переменную типа $esc_pass = mysql_escape_string($_POST['pass']) или сразу писать, формируя запрос "VALUES( ...., '" . mysql_escape_string($_POST['pass']) . "', ...)").
- вся обработка (вы пишите "обрабатываем $_POST["pass"], функция trim и т.д тп") вообще-то должна быть ПОСЛЕ того, как $_POST['pass'] будет "чистым" значением (т.е. без лишних бекслешей). В случае с trim(), конечно, ничего не произойдёт, но это ничего не значит.

>сделать функцию, которая исправляет $_POST, $_GET, $_COOKIE, $_REQUEST от бекслешей, поставленных magic_quotes_gpc.
да, но дело в том что пока только post данные используются, поэтому пока только так...

>не портить чистое значение переменной-источника данных (в данном случае $_POST['pass'])
но ведь если эта самая переменная $_POST['pass'] больше нигде потом не пригодится, то надо ли...?

плох он двумя вещами.
1.Непосредственно в контексте оператора mysql_query не видно, что аргумент приготовлен. А видно как раз наоборот, место потенциальной дыры. Поскольку, анализируя такой скрипт, придется переносить внимание в разные его части, код становится запутанным.

2. На всём пространстве жизни переменной от вызова этой некоей функции до запроса (да и за запросом) воспользоваться её значением как истинным уже не получится. К примеру, получить число символов в аргументе, посчитать хеш, просто вывести на экран и т.п. Вы не сможете. Не сможете Вы также аккуратно перейти на работу с теми клиентами СУБД SQL , которые требуют применения плэйсхолдеров для включения значений при построении SQL-операторов. (mysqli, mssql, oracle) - они-то будут требовать истинных значений, а не препарированных.

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

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

поделитесь тогда пожалуйста, чего мне следует бояться кроме sql-инъекций и xss?

Бойтесь файлов, загружаемых пользователями.

об этом читал в Вашей книге "Практика создания веб-сайтов Второе здание" ;)
кстати, спасибо Вам за неё, всё очень доходчиво

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

Кстати, изрядное количество ошибок такого рода достигается, если скрипт примененяет элемент $_FILES['file']['name'] для именования серверной копии загруженного файла.

>б) в этих каталогах запрещать размещение любых типов файлов, кроме указанных явно.>дополню.
это с помощью .htaccess?
скиньте ссылку пожалуйста

Разве с помощью .htaccess можно запретить размещение?
Какую ссылку?

а каким образом тогда?
идет просто проверка при добавлении $_FILES["file"]["type"]
этого достаточно?

что такое добавление $_FILES["file"]["type"]?
Проверка да, и ограничение при формировании расширений файла - второго параметра move_uploaded_file()

>что такое добавление $_FILES["file"]["type"]?
извините, не правильно сформировал ответ, имел ввиду при добавлении файла

я кстати использую copy.. или все-таки безопаснее move_uploaded_file() ?

на счет ограничения немного не понял, там же вроде место куда перемещается файл указано...