Форум: Форум PHPФорум ApacheФорум Регулярные ВыраженияФорум MySQLHTML+CSS+JavaScriptФорум FlashРазное
Новые темы: 0000000
PHP 5/6. В подлиннике. Авторы: Кузнецов М.В., Симдянов И.В. PHP Puzzles. Авторы: Кузнецов М.В., Симдянов И.В. Объектно-ориентированное программирование на PHP. Авторы: Кузнецов М.В., Симдянов И.В. MySQL на примерах. Авторы: Кузнецов М.В., Симдянов И.В. MySQL 5. В подлиннике. Авторы: Кузнецов М.В., Симдянов И.В.
ВСЕ НАШИ КНИГИ
Консультационный центр SoftTime

Форум PHP

Выбрать другой форум

 

Здравствуйте, Посетитель!

вид форума:
Линейный форум Структурный форум

тема: глюк с get_magic_quotes_gpc()??
 
 автор: psychomc   (30.04.2009 в 10:59)   письмо автору
 
 

<?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 включена, но она не работает или я что-то не так понял...

  Ответить  
 
 автор: ddhvvn   (30.04.2009 в 11:25)   письмо автору
 
   для: psychomc   (30.04.2009 в 10:59)
 

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

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

  Ответить  
 
 автор: psychomc   (30.04.2009 в 11:34)   письмо автору
 
   для: ddhvvn   (30.04.2009 в 11:25)
 

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

  Ответить  
 
 автор: psychomc   (30.04.2009 в 11:36)   письмо автору
 
   для: psychomc   (30.04.2009 в 11:34)
 

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

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

  Ответить  
 
 автор: ddhvvn   (30.04.2009 в 12:31)   письмо автору
 
   для: psychomc   (30.04.2009 в 11:36)
 

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

  Ответить  
 
 автор: psychomc   (30.04.2009 в 13:22)   письмо автору
 
   для: ddhvvn   (30.04.2009 в 12:31)
 

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

  Ответить  
 
 автор: Николай2357   (30.04.2009 в 15:05)   письмо автору
 
   для: psychomc   (30.04.2009 в 13:22)
 

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

  Ответить  
 
 автор: ddhvvn   (30.04.2009 в 15:21)   письмо автору
 
   для: psychomc   (30.04.2009 в 13:22)
 

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

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

  Ответить  
 
 автор: psychomc   (30.04.2009 в 16:16)   письмо автору
 
   для: ddhvvn   (30.04.2009 в 15:21)
 

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

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


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

  Ответить  
 
 автор: Николай2357   (30.04.2009 в 16:49)   письмо автору
 
   для: psychomc   (30.04.2009 в 16:16)
 

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

  Ответить  
 
 автор: psychomc   (30.04.2009 в 16:54)   письмо автору
 
   для: Николай2357   (30.04.2009 в 16:49)
 

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

разве
<?php
$_GET
["id"] = intval($_GET["id"]); 

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

  Ответить  
 
 автор: ddhvvn   (30.04.2009 в 18:37)   письмо автору
 
   для: psychomc   (30.04.2009 в 16:54)
 

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

  Ответить  
 
 автор: psychomc   (01.05.2009 в 14:06)   письмо автору
 
   для: ddhvvn   (30.04.2009 в 18:37)
 

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

  Ответить  
 
 автор: Trianon   (01.05.2009 в 20:20)   письмо автору
 
   для: psychomc   (01.05.2009 в 14:06)
 

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

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

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

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

  Ответить  
 
 автор: psychomc   (02.05.2009 в 17:46)   письмо автору
 
   для: Trianon   (01.05.2009 в 20:20)
 

-

  Ответить  
 
 автор: psychomc   (02.05.2009 в 17:47)   письмо автору
 
   для: Trianon   (01.05.2009 в 20:20)
 

вам виднее :)

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

<?php
// обрабатываем $_POST["pass"], функция trim и т.д тп.

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

// с $_POST["pass"] больеш ничего не делаем, получается что работа mysql_escape_string как раз перед запросом !
// здесь если надо делаем что-то другое, $_POST["pass"] уже не трогаем

INSERT INTO ..... VALUES(...., '$_POST["pass"]', ...)
// ....

  Ответить  
 
 автор: Heavy   (02.05.2009 в 18:39)   письмо автору
 
   для: psychomc   (02.05.2009 в 17:47)
 

Он плох тем, что ориентирован на очень конкретную ситуацию. По-нормальному было бы:
- сделать функцию, которая исправляет $_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(), конечно, ничего не произойдёт, но это ничего не значит.

  Ответить  
 
 автор: psychomc   (02.05.2009 в 19:02)   письмо автору
 
   для: Heavy   (02.05.2009 в 18:39)
 

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

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

  Ответить  
 
 автор: Trianon   (02.05.2009 в 19:05)   письмо автору
 
   для: psychomc   (02.05.2009 в 17:47)
 

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

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

  Ответить  
 
 автор: psychomc   (02.05.2009 в 20:03)   письмо автору
 
   для: Trianon   (02.05.2009 в 19:05)
 

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

  Ответить  
 
 автор: Trianon   (02.05.2009 в 20:10)   письмо автору
 
   для: psychomc   (02.05.2009 в 20:03)
 

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

  Ответить  
 
 автор: psychomc   (02.05.2009 в 23:33)   письмо автору
 
   для: Trianon   (02.05.2009 в 20:10)
 

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

  Ответить  
 
 автор: cheops   (03.05.2009 в 01:31)   письмо автору
 
   для: psychomc   (02.05.2009 в 23:33)
 

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

  Ответить  
 
 автор: psychomc   (03.05.2009 в 01:45)   письмо автору
 
   для: cheops   (03.05.2009 в 01:31)
 

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

  Ответить  
 
 автор: Trianon   (03.05.2009 в 08:43)   письмо автору
 
   для: psychomc   (02.05.2009 в 23:33)
 

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

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

  Ответить  
 
 автор: psychomc   (03.05.2009 в 10:51)   письмо автору
 
   для: Trianon   (03.05.2009 в 08:43)
 

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

  Ответить  
 
 автор: Trianon   (03.05.2009 в 11:26)   письмо автору
 
   для: psychomc   (03.05.2009 в 10:51)
 

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

  Ответить  
 
 автор: psychomc   (04.05.2009 в 10:59)   письмо автору
 
   для: Trianon   (03.05.2009 в 11:26)
 

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

  Ответить  
 
 автор: Trianon   (04.05.2009 в 11:07)   письмо автору
 
   для: psychomc   (04.05.2009 в 10:59)
 

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

  Ответить  
 
 автор: psychomc   (04.05.2009 в 13:55)   письмо автору
 
   для: Trianon   (04.05.2009 в 11:07)
 

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

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

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

  Ответить  
Rambler's Top100
вверх

Rambler's Top100 Яндекс.Метрика Яндекс цитирования