Explay CMS - бесплатная система управления соц. сетями

[pilot911]

mysql_real_escape_string() calls MySQL's library function mysql_real_escape_string, which prepends backslashes to the following characters: \x00, \n, \r, \, ', " and \x1a.

Эта функция должна вызываться всегда для обеспечения безопасности данных перед посылкой в MySQL.

Никакого соединения с мускуль сервером не нужно, ну и экранируются не только кавычки, но и нек других символов

 

[DiMA]

zerkms
Причем тут мля "защита" и "скорее опротиворечил"? Что за детский сад? Либо ты объясняешь, как сделать инъекцию, либо подтверждаешь безопасность addslashes. Либо так, либо эдак, какие нах средние варианты, флеймер?

Я проблем с addslashes не вижу. Ни одной. Если не прав - давай доказательство в студию, съем свой галстук

Проект работает на UTF-8 и это никак не изменить. Всем известные опасные китайские кодировки не используются. Атакующий никак не может изменить UTF-8 на что-то другое, кроме владельца сайта.

Вот те функция транслитерации. На UTF-8 работает.
$a=array('щ'=>'sch', 'ч'=>'ch', 'ё'=>'jo');
$str="щчё";
echo strtr($str, $a);

Ну, с какого бодуна strtr должна не работать или addslashes пропускать инъекции? Ну, объясните же мне! В UTF-8 все опасные символы находятся в диапазоне 0xxxxxxx. Этот байт может быть только первым в многобайтовой последовательности одного символа. Поэтому по барабану как искать символы для слеширования - через функцию addslahes, ничего не знающей о кодировках, или через умную функцию. Все опасные символы в SQL, подлежащие слешированию, находятся в диапазоне 0-127.

Тоже самое с заменой русских букв - они состоят из принципиально разных байтов - 110xxxxx 10xxxxxx, которые не могут наложиться в середину другой буквы. Т.е. можно принять тупой str_replace, не знающей о UTF-8. В чем я не прав-то?

 

[Smelo]

pilot911
http://www.php.ru/manual/function.mysql-real-escape-string.html

Замечание: Функцию mysql_real_escape_string() можно использовать только после того, как установлено соединение с MySQL. В противном случае возникнет ошибка уровня E_WARNING, а функция возвратит FALSE. Если link_identifier не указан, используется последнее открытое соединение.

addslashes удобно использовать при кроссБД

 

[zerkms]

DiMA
ссылка уже была - выше. кетчуп? майонез?

про strtr прогнулся, ага. забыл что там массивы можно передавать %)
непонятно - зачем тогда девелоперы сделали 100% аналог уже существующей функции (str_replace)

-~{}~ 29.08.09 20:41:

Smelo
ну и бред. нужно использовать для каждой БД свои функции для обезопасивания строк.

 

[Smelo]

zerkms
кетчуп
там же ясно по ссылке написано, что работает только с китайскими кодировками

ну и бред. нужно использовать для каждой БД свои функции для обезопасивания строк.

если обёртка без placeholder-ов, то никакой это не бред

 

[zerkms]

Smelo
ты это скажи хозяевам поломанных блогов.

 

[Smelo]

zerkms
приведи пример обхода addslashes при utf?

 

[zerkms]

ps: что люди только не сделают, лишь бы через жопу сделать.

Smelo
я использую плейсхолдеры в 1% случаев. в остальных 99% - pdo::quote. ы?

-~{}~ 29.08.09 20:49:

Smelo
при утф нет. это повод делать через задницу? (затачивая код под конкретные глупые ограничения) м?

 

[DiMA]

Млять... причем тут дебильные блоги вордпресс, позволяющие сменить КЛЕНТУ по своему желанию свою кодировку? Ты еще дырявым сам PHP назови, раз в нем можно сделать так:

eval($_GET) или include($_POST)

Ты мне зубы не заговаривай. Либо я полный лох с проблемами UTF-8, либо ты. Давай уж определись. На статью пинять не надо, я все это читал перечитывать сотни раз и не только это. Статья четко доказывает мою правоту.

 

[Smelo]

ы?<<

50\50

 

[zerkms]

Smelo
приведи хоть одну причину использовать addslashes, уязвимости для которой существуют (хоть и не для всех кодировок), а не mysql_real_escape_string, которая работает всегда?

-~{}~ 29.08.09 20:52:

>> А т.к. проект работает на UTF-8, то использовать mysql_real_escape_string не обязательно. Достаточно просто addslashes.
DiMA
она твою правоту не доказывает ни в коем разе. приведи хоть 1 причину использовать addslashes, а не mysql_real_escape_string? зачем менять и так уже отлично работающий кусок кода? не к чему больше было придраться что ли?

 

[Smelo]

яж сказал - "через жопу" написанные КроссБД обёртки, возможно большая скорость работы, не требует соединения с БД

я использую прейсхолдеры и mysql_real_espace_string
но спор то начался из-за того что вы начали необонованно питаться

 

[zerkms]

Smelo

написанные КроссБД обёртки, возможно большая скорость работы, не требует соединения с БД

угу, экранирование запросов без БД. следующим советом, будет написание скриптов на пхп, которые не требуют пхп?

 

[DiMA]

Ты признаешь, что addslashes и куча однобайтовых строчных функций пхп идеально работает и со строками UTF-8? Достачно включить голову. То-то же, флеймер.

 

[zerkms]

DiMA
я признаю, что работает. ты не ответил на мой вопрос: зачем менять функцию, которая работает идеально всегда на функцию, для которой известны проблемы?

 

[DiMA]

Это другая совершенно проблема (на которую тебе ответили).

А ты написал, будто мой совет может привести к дырам. И не смог этого доказать.

 

[zerkms]

DiMA
да, в этом плане я прогнал.
теперь твоя очередь признаться, что просто попытка прикопаться к нормальному куску кода?

 

[Smelo]

А т.к. проект работает на UTF-8, то использовать mysql_real_escape_string не обязательно. Достаточно просто addslashes.

 

[zerkms]

Smelo
т.е. если бы ты увидел код:

$a = $b + $c;
то первым советом, который ты бы дал, было что-то вроде:
"а т.к. прибавление нуля не изменит сумму - то можно и ноль прибавить $a = $b + $c + 0;"

так?

повторяю вопрос: зачем заменять функцию, которая работает на всех кодировках на функцию, которая на некоторых кодировках может быть уязвимой?

Достаточно просто addslashes.

а mysql_real_escape_string это сложно? я не понимаю смысл слова "просто" в контексте. разжуй?

 

[DiMA]

Между тем, в обсуждаемой функции никто слона так и не заметил. Прочитайте ее еще разок.

Если магик квоты включены, то слеширование не работает. Т.е. мы полагаемся на пхп, который до запуска скрипта
1) либо исполняет addslahes
2) либо каким-то макаром mysql_real_escape_string (без знаний о кодировках).

Я не проверял, какой из 2х вариантов применяет пхп на магикквотах (потому что это нах никому не нужно). Думаю, первый. В пользу этого говорит и документация.

Т.о. включая квоты, мы автоматически переключаемся с mysql_real_escape_string() на addslahes(). Вот тут то точно будет инъекция, если проект перейдет на китайскую кодировку. И это не смотря, что мы следовали совету zerkms - "ставим mysql_real_escape_string и все будет автоматически безопасно"! Хрен вам, а не безопасность, нужно говолой думать.

-~{}~ 29.08.09 14:29:

> теперь твоя очередь признаться, что просто попытка прикопаться к нормальному куску кода?

С учетом тупизма с магикквотами ты меня по прежнему подозреваешь в придирках? .-)

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

------------
Снимать блокировку перед закрытием файла не нужно. Сам снимится на закрытии.
------------

=)