прошу поглядеть интересующихся PHPFAQ slashes

[Фанат]

прошу поглядеть интересующихся PHPFAQ slashes

http://phpfaq.ru/slashes
интересует критика и замечания.

Кроме косметики добавлен давно ожидавшийся кусок для продвинутых про правильную работу со слешами и исправлена инфа про искейп стринг.

Все еще не обладаю реальной информацией по поводу риал искейпа.

 

[empty]

красата!

 

[fixxxer]

не знаю, насколько необходимо добавлять в faq инфу об экранировании в других субд. но распространенной ошибкой при работе с Интербейзом, Сибейзом, MSSQL является str_replace("'", "''"),так как, во-первых, это отэкранирует не все служебные символы, а во-вторых, при включенных gpc_magic_quotes к одинарным кавычкам уже припишутся слэши. Правильно же:
I. Установить в php.ini или .htaccess magic_quotes_sybase=on, и далее поступать, как в FAQ
II. Если п1 невозможен по каким-либо причинам
1) Если magic_quotes_sybase=off и gpc_magic_quotes=on, сделать рекурсивный stripslashes, как в faq
2) установть magic_quotes_sybase=on через ini_set
3) использовать addslashes (п.2 меняет поведение addslashes)

 

[Фанат]

Черт, и правда, сложный вопрос...
Весь фак, по сути, заточен под мускуль. В частности, пункт http://phpfaq.ru/slashes#notes , да и все остальное...

 

[neko]

на то он и фак, все правильно

-~{}~ 14.08.04 19:03:

кроме того в если я ничего не путаю в том же firebird'е можно менять экранирующий символ

 

[ForJest]

http://phpclub.ru/talk/showthread.php?s=&threadid=52902

 

[Yukko]

работе с Интербейзом, Сибейзом, MSSQL является str_replace("'", "''"),

не понял??? ты категорически предлагаешь не делать перед запросом в MS SQL не делать str_replace? а делать magic_quotes_sybase=on?
Тогда, когда при работе с MS SQL в одном батче не удается сделать все, что нужно сделать на данной страничке, а приходится делать несколько запросов, и в результате получается значение с одинарной кавычкой, приходится делать еще:
set_magic_quotes_runtime(1);
что не всегда приводит к ожидаемым результатам (к сожалению сейчас привести пример не могу, но помню, что ушел от этого год назад именно по этой причине).

По моему скромному мнению те, кто работает со связкой:
PHP+Sybase
PHP+MS SQL
PHP+Interbase
в большинстве случаев являются сами себе хостерами и могут руками выключить все magic_quotes_sybase=off
magic_quotes_sybase=off
и делать прямо перед запросом
str_replace("'", "''", $data);
для каждого параметра, который передается в запрос при помощи функции, подобной той, которую привел Фанат тут:http://phpfaq.ru/slashes#mysql, либо при помощи аналога библиотеки предложенной тут:http://dklab.ru/chicken/nablas/30.html и обсужденной тут:http://xpoint.ru/forums/thread.xhtml?action=thread&id=19337.

это отэкранирует не все служебные символы

Какие именно служебные символы еще нужно отэкранировать для MS SQL кроме одинарной кавычки? Правомерность этого вопроса доказывает http://phpclub.ru/talk/showthread.php?s=&threadid=52902 и http://ua.php.net/manual/en/function.addslashes.php (коммент mike at gyrate dot org)

-~{}~ 14.08.04 22:32:

Слеш нужен только при работе с некоторыми базами данных. Причем нужен обязательно.

Предлагаю объединить все в одно предложение, что-то типа:
При работе с некоторыми базами данных слеш нужен обязательно, а во всех остальных случаях он только мешает.

Но не всегда есть доступ к настройкам PHP, особенно если программа пишется для распространения.

Получается у бедного программиста, котрый пишет программу для распространения, чаще чем у других нет доступа к настройкам РНР
Предлагаю перефразировать:
Если нет доступа к настройкам РНР, либо программа пишется для распространения...

Мелочи:

пришедшим от пользователя - из POST

ИМХО, тире лишнее

скрипта - например

тоже самое... лучше так:
...скрипта. Например, ...

 

[neko]

и запятые запятые

 

[Фанат]

распятяые запятые

 

[fixxxer]

Я категорически предлагаю при запросах к MSSQL etc не делать тупо str_replace, напарываясь на \'magic_quotes_gpc\'. Все остальное - опционально, в общем-то.

 

[Yukko]

fixxxer
ну так

magic_quotes_gpc

проверить наверное надо... либо сознательно отключить. Я тебя правильно понял?

 

[Фанат]

Вот тут товарищ интересовался функцией adds
http://phpclub.ru/talk/showthread.php?s=&threadid=55775
справедливо указывая на достаточную бесполезность ее второго использования - прослешивания скаляра.
Я подумал, что там не хватает проверки на мэджик квотес.

function adds(&$el,$level=0) { 
  if (is_array($el)) { 
    if (get_magic_quotes_gpc()) return; 
    foreach($el as $k=>$v) adds($el[$k],$level+1); 
  } else { 
    if (!get_magic_quotes_gpc()) $el = addslashes($el); 
    if (!$level) return $el; 
  } 
}

Вообще - есть в ней смысл какой-то?
Чего скажут уважаемые знатоки?
Как-то это все уже так давно писалось, что побудительные мотивы, по которым я писал ту или иную функцию, уже потерялись во мраке...
может, выкинуть ее вообще?
Или что-то другое написать?

 

[Ямерт]

ИМО, это вчерашний день.
Лучше отключать quotes и использовать PEAR:B с prepare/execute - или передавать значения как массив-параметр к getRow, query & Co. Слэши поставятся сами как надо.

 

[Фанат]

Ну, про это там тоже написано.
Одно другому не мешает

-~{}~ 16.11.04 15:30:

Неисчерпаемая тема.
На форуме securitylab меня ткнули носом , что прослешивание и обкавычивание - не панацея.
Действительно, есть разделы в запросе, в которых кавычки являются совершенно лишними.
И ведь совершенно прав чувак.
И пусть в лимите ты ничего уже не сделаешь вредным опратором, а принимать состав полей из запроса будет толлько больной на голову девелопер или автор пхпмайадмина. Но у нас же фак, в котором надо разжевывать все.
Охохох. Опять этот многострадальный текст исправлять.

плюс - замечания по функции strips...

С другой стороны - хорошо.
А то ж за столько лет никто и не придрался почти. профи не читают, а ньюбы не видят косяков.

 

[Romantik]

Для простоты можно заключать в кавычки не только строковые, но и числовые переменные, проскольку mysql сам преобразует их к нужному виду. Тем более, что мы не можем быть уверены в том, что от пользователя пришла переменная именно того типа, который мы ожидаем. То есть, для надежности, любые данные, вставляемые в запрос, мы будем заключать в кавычки. Например:
$query="INSERT INTO table (name,age,type) VALUES ('$name','$age','12')";

Я думаю стоит все таки упомянуть об обязательной проверке чисел intval, doubleval

 

[Фанат]

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

 

[ONK]

Возможно стоит существенно переписать фак, заодно разделий его на две условных части.
1. Как можно поступать со слэшами. (для тех кто хочет просто заткнуть дыры в работе с базой данных)
2. Как нужно поступать со слэшами. (для тех кто хочет правильно работать с принимаемыми данными)

 

[Фанат]

а нужно - это про что?
про плейсхолдеры?

 

[ONK]

Я имею в виду что первый пункт подразумевает приведение всех полученных данных к однократно прослэшенному состоянию. Т.к. это избавляет программиста от необходимости думать и изменять ранее написанный под magic_quotes_gpc = On код.

Однако этот вариант плохо согласуется c набором правил составления безопасных SQL запросов, а в некоторых случаях не позволяет производить необходимые операции над полученными данными без лишнего вызова stripslashes()...

Второй вариант наоборот подразумевает привдение данных к первозданному виду, в котором они были отправлены пользователем, и дальнейшую грамотную работу с ними. Детали реализации грамотной работы не имеют существенного значения, важен сам набор правил последовательности действий, "алгоритм правильной обработки получаемых данных". Можно привести один из примеров реализации необходимого для обработки данных API, не важно в виде отдельных функций он будет реализован или в виде специального "абстрактного класса со статическими методами" (я предпочитаю класс для экономии пространства имён функций).

 

[Фанат]

не.
никаких классов.
итак размер фака превышает пределы восприятия.
А по разделению - так оно и так разделено.
про правильный подход тамнаписано.
Надо больше?