|
|
|
|
<?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 включена, но она не работает или я что-то не так понял... | |
|
|
|
|
|
|
|
для: psychomc
(30.04.2009 в 10:59)
| | похоже, что не так )
если опция magic_quotes включена, то кавычки УЖЕ экранируются (слешем).
Вы делаете проверку и если опция включена, Вы убираете эти самые "поставленные автоматом" слеши.
А если опция не включена, то Вы просто экранируете кавычки и строка возвращается со слешами.
Вы чего хотите добиться то? ) | |
|
|
|
|
|
|
|
для: ddhvvn
(30.04.2009 в 11:25)
| | ааааа...фак! как же я ступил )))) | |
|
|
|
|
|
|
|
для: 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;
}
?>
|
| |
|
|
|
|
|
|
|
для: psychomc
(30.04.2009 в 11:36)
| | хм... я не уверен, но смотря, что Вы с дядькой замышляли... ))
Вот он придет и скажет Вам, правильно или нет. | |
|
|
|
|
|
|
|
|
для: psychomc
(30.04.2009 в 13:22)
| | Ух надает, придет. Подзатыльников.
Нельзя данные на входе mysql_escape_string() обрабатывать. Смысл то какой? Убрали бэкслэши и тут же поставили. Эта функция только для работы с MySQL.
Хотя тут не видно, что это $_POST массив. | |
|
|
|
|
|
|
|
для: psychomc
(30.04.2009 в 13:22)
| | да, что-то я прочел и немного впал в ступор.. )
все-таки подождем когда придет Он и все разрулит ))))
а, если, как я понял от Николая, речь идет о данных, которые будут использоваться НЕ в запросах, тогда вроде ясно, а если нет - то не ясно )) | |
|
|
|
|
|
|
|
для: ddhvvn
(30.04.2009 в 15:21)
| | надеюсь что придёт....
использую так:
$_POST["pass"] = post_filter($_POST["pass"]);
|
только для пост и только перед вставкой в запрос... | |
|
|
|
|
|
|
|
для: psychomc
(30.04.2009 в 16:16)
| | Если
>только перед вставкой в запрос...
то правильно, а вот
>только для пост
не правильно. $_GET и $_COOKIE тоже нужно так обрабатывать. | |
|
|
|
|
|
|
|
для: Николай2357
(30.04.2009 в 16:49)
| | само собой :)
но т.к я из $_GET не беру строковые данные для вставки в базу, а только числовые, то зачем?
разве
<?php
$_GET["id"] = intval($_GET["id"]);
|
не достаточно? | |
|
|
|
|
|
|
|
для: psychomc
(30.04.2009 в 16:54)
| | по сути достаточно | |
|
|
|
|
|
|
|
для: ddhvvn
(30.04.2009 в 18:37)
| | Трианон не ответил, его понять можно, любому бы надоело одно и то же писать по сто раз.
спасибо всем кто принял участие | |
|
|
|
|
|
|
|
для: psychomc
(01.05.2009 в 14:06)
| | Я в соседней теме написал в частности следующее.
mysql_escape_string() вызывается непосредственно перед обрамлением текстовых строк апострофами, при формированнии текста SQL-запроса - во всех случаях.
Причем этот пост Вы видели и на него отреагировали.
Теперь Вы пишете
>значит по дядьке Трианону такой вариант будет правильным:
> $post = mysql_escape_string($post);
> return $post;
где есть вызов mysql_escape_string() и нет ни звука ни про апострофы ни про sql-запросы.
Внимание, вопрос. Лично Вам. Ответьте, пожалуйста.
Кем я Вас должен считать? | |
|
|
|
|
|
|
|
для: Trianon
(01.05.2009 в 20:20)
| | - | |
|
|
|
|
|
|
|
для: 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"]', ...)
// ....
|
| |
|
|
|
|
|
|
|
для: 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(), конечно, ничего не произойдёт, но это ничего не значит. | |
|
|
|
|
|
|
|
для: Heavy
(02.05.2009 в 18:39)
| | >сделать функцию, которая исправляет $_POST, $_GET, $_COOKIE, $_REQUEST от бекслешей, поставленных magic_quotes_gpc.
да, но дело в том что пока только post данные используются, поэтому пока только так...
>не портить чистое значение переменной-источника данных (в данном случае $_POST['pass'])
но ведь если эта самая переменная $_POST['pass'] больше нигде потом не пригодится, то надо ли...? | |
|
|
|
|
|
|
|
для: psychomc
(02.05.2009 в 17:47)
| | плох он двумя вещами.
1.Непосредственно в контексте оператора mysql_query не видно, что аргумент приготовлен. А видно как раз наоборот, место потенциальной дыры. Поскольку, анализируя такой скрипт, придется переносить внимание в разные его части, код становится запутанным.
2. На всём пространстве жизни переменной от вызова этой некоей функции до запроса (да и за запросом) воспользоваться её значением как истинным уже не получится. К примеру, получить число символов в аргументе, посчитать хеш, просто вывести на экран и т.п. Вы не сможете. Не сможете Вы также аккуратно перейти на работу с теми клиентами СУБД SQL , которые требуют применения плэйсхолдеров для включения значений при построении SQL-операторов. (mysqli, mssql, oracle) - они-то будут требовать истинных значений, а не препарированных. | |
|
|
|
|
|
|
|
для: Trianon
(02.05.2009 в 19:05)
| | спасибо за ответ. познавательно.
мне кажется то что сверху мне не грозит, по крайней мере в ближайшем будущем | |
|
|
|
|
|
|
|
для: psychomc
(02.05.2009 в 20:03)
| | C таким подходом, конечно, можно писать скрипты. Для себя.
Но имеет смысл поостеречься давать советы. Другим.
Вы же не можете наверняка утверждать, что будет им грозить, а что нет? | |
|
|
|
|
|
|
|
для: Trianon
(02.05.2009 в 20:10)
| | поделитесь тогда пожалуйста, чего мне следует бояться кроме sql-инъекций и xss? | |
|
|
|
|
|
|
|
для: psychomc
(02.05.2009 в 23:33)
| | Бойтесь файлов, загружаемых пользователями. | |
|
|
|
|
|
|
|
для: cheops
(03.05.2009 в 01:31)
| | об этом читал в Вашей книге "Практика создания веб-сайтов Второе здание" ;)
кстати, спасибо Вам за неё, всё очень доходчиво | |
|
|
|
|
|
|
|
для: psychomc
(02.05.2009 в 23:33)
| | дополню.
Бояться нужно не самих файлов. Нужно опасаться ситуаций, когда пользователь сможет сделать их содержимое исполняемым кодом.
На практике это означает, что нужно
а) предотвращать загрузку файлов в каталоги не предназначенные для этого специально.
б) в этих каталогах запрещать размещение любых типов файлов, кроме указанных явно.
в) в том числе и любые попытки поместить или изменить там служебные файлы апача .ht*
г) из явно указанных типов исключить типы, интерпретируемые как на сервере (php и т.п.) так и на клиенте от имени сервера (html, и т.п.)
Кстати, изрядное количество ошибок такого рода достигается, если скрипт примененяет элемент $_FILES['file']['name'] для именования серверной копии загруженного файла. | |
|
|
|
|
|
|
|
для: Trianon
(03.05.2009 в 08:43)
| | >б) в этих каталогах запрещать размещение любых типов файлов, кроме указанных явно.>дополню.
это с помощью .htaccess?
скиньте ссылку пожалуйста | |
|
|
|
|
|
|
|
для: psychomc
(03.05.2009 в 10:51)
| | Разве с помощью .htaccess можно запретить размещение?
Какую ссылку? | |
|
|
|
|
|
|
|
для: Trianon
(03.05.2009 в 11:26)
| | а каким образом тогда?
идет просто проверка при добавлении $_FILES["file"]["type"]
этого достаточно? | |
|
|
|
|
|
|
|
для: psychomc
(04.05.2009 в 10:59)
| | что такое добавление $_FILES["file"]["type"]?
Проверка да, и ограничение при формировании расширений файла - второго параметра move_uploaded_file() | |
|
|
|
|
|
|
|
для: Trianon
(04.05.2009 в 11:07)
| | >что такое добавление $_FILES["file"]["type"]?
извините, не правильно сформировал ответ, имел ввиду при добавлении файла
я кстати использую copy.. или все-таки безопаснее move_uploaded_file() ?
на счет ограничения немного не понял, там же вроде место куда перемещается файл указано... | |
|
|
|