Вышел PHP 5.4.0

Уязвимости же сайтов скорее зависят от качества движка, на них установленного, чем от ЯП на котором он написан.

// php нелогичен
$array = array('one', 'two');
var_dump(in_array(0, $array)); // true
var_dump(in_array(0, $array, $strict = true)); // false

// php глюкав (в примере - v5.3.1)
for( $i = 1; $i<= 12; $i++ )
    echo date("M", mktime(0,0,0,$i));
// output: JanMarMarAprMayJunJulAugSepOctNovDec

// Некоторые глюки/нелогичности просто вносятся в спеки
// case 1
$a = array(1);
$b = &$a[0];
$c = $a;
$c[0]++;
print "{$a[0]}"; // 2

// case 2
$a = array(1);
//$b =& $a[0];
$c = $a;
$c[0]++;
print "{$a[0]}"; // 1

Покажите как одной строкой на перле magic quotes делаются ? В перле не силен просто :(

$QUERY ~= s/(['«])/\\\1/g;

Что-то типа того.

Вдогонку:

php -r 'echo 0x0+10;' # 26
php -r 'echo 0x0 + 10;' # 10

$QUERY ~= s/(['«])/\\\1/g;

А слеши кто будет экранировать? А <, > и прочие? Выше давал однострочник - лучше записывать через юникодовские символы. А ля ' -> '

Ух, ты! На лоре &#39; не экранируется :) Имелось ввиду ' -> &#39;

Аргументация - смешение заэскейпленных данных от юзера и незаэскейпленных данных из базы.

Ну если скриптописатель умудряется путать данные от юзера и данные от базы - то это ваще труба. Мда, «сделайте штуку, которой смогут пользоваться идиоты, и только идиоты захотят ей пользоваться».

Сотней? Ты хоть попробуй по-программировать немного, что ли.

Ваще-то уже более чем.

Если ты не знаешь, как сделать простейшие вещи, типа эскейпа

кавычек на каком-то языке - какой смысл вообще обсуждать этот язык?

Знаю. Но я ещё знаю как не писать говнокод. Если не писать говнокод, то magic quotes на php в одну строку не укладываются. Если интересно - можно в сырцы PHP поглядеть, как там оно было сделано.

Откуда вы такие берётесь, непонятно.

Оттуда же, окуда всё население Земли.

Ты же понимаешь, что за тобой, кроме болтовни ничего нет?

За мной - есть. Можно даже на лоре нагуглить легко. А вот что есть за Вами кроме болтовни - что-то никак не находится.

Ты не сможешь в принципе решать, что имеет право на существование, а что нет

Я-то могу, а вот Вы, как раз вряд-ли. :)

А слеши кто будет экранировать?

Туда и слеши, и чорта лысого добавить не проблема. В отличии от PHP.

Туда и слеши, и чорта лысого добавить не проблема. В отличии от PHP.

Если хочешь что-то доказать оппоненту - приводи чёткие доводы. Иначе это воспримется как слабина.

Разве в ПХП нету замены по регекспу?

Ну если скриптописатель умудряется путать данные от юзера и данные от базы - то это ваще труба.

Это не труба, это просто значит, что он новичок, поэтому ему лучше эту опцию выключить. А опытный путать не будет, но и юзать эту опцию тоже - зачем самому себе лишний геммор создавать?

Я же написал внятно вроде. Перечитай ещё раз, если не понятно. Эскейп делается при использовании данных (вставить в базу, вывести на экран). Если ты его хочешь делать эскейп в других местах - твои проблемы, юзай перл.

Если не писать говнокод, то magic quotes на php...

... не требуются. Поэтому их и убрали.

За мной - есть.

Окей, давай, убивай php. Дон Кихот.

Если хочешь что-то доказать оппоненту - приводи чёткие доводы. Иначе это воспримется как слабина.

Чёткий довод прост как 5 копеек - обработка строк в perl реализована гораздо удобнее и проще чем в PHP. Потому опция magic quotes в perl не нужна, а в PHP её отсутствие добавляет некоторое количество геморроя.

Разве в ПХП нету замены по регекспу?

Это жалкое подобие того, что есть в perl.

Вышел PHP 5.4.0 (комментарий)

Разве в ПХП нету замены по регекспу?

Есть, конечно, как и везде, но сделано так, что лучше бы не делали. В C тоже можно использовать регэкспы. Но выглядит это по сравнению с $a =~ s/a/b/; настолько убого, что пользоваться этим неприятно.

Есть PHP для начального уровня, и Java/.NET для enterprise. Всё остальное как-то не востребовано.

И есть Python/Ruby для среднего уровня (очевидный фикс)

Это не труба, это просто значит, что он новичок, поэтому ему лучше эту опцию выключить. А опытный путать не будет, но и юзать эту опцию тоже - зачем самому себе лишний геммор создавать?

Я же написал внятно вроде.

Бу-га-га :) Внятно шо пипец: «новичок будет путать, поэтому ему лучше выключить, а опытный путать не будет, поэтому ему лучше выключить.». Логика просто бесподобна :)

И вот, люди, обладающие такой вот логикой, пишут на PHP. Офигенно.

а опытный путать не будет, поэтому ему лучше выключить

Кажется ты немного туповат. Прямо же написано. Опытный не будет её юзать. Не ему лучше выключить, а он сам выключит, ибо не нужна. Теперь понятна логика или всё никак не доходит?

Или не ты туповат, а просто тролль?

Туда и слеши, и чорта лысого добавить не проблема.

Вообще-то это проблема, что ты не знаешь, что нужно экранировать. Твой код будет уязвим. А вот код с похапе функцией, которая знает - нет.

Почему они так и не заняли серьёзный процент рынка веб-приложений? Нужны ли они вообще?

$ENV{$_} =~ s/([«'<>])/sprintf('&#%x', unpack('U', $1))/ge for keys %ENV;

Гм, переводить данные от пользователя в html entities - это ошибка. А что если нужно будет отправить письмо plain текстом, или сообщение в жаббир? Надо же, уже второй перл-гуру, гроза говнокодеров, слился)

Согласен, есть у PHP проблемы. Но разве у остальных ЯП их нет? Покажите мне совершенный ЯП без глюков? И нелогичное поведение функций/операторов можно встретить и в других ЯП. В чём проблема? Были бы друние ЯП лучше на порядок, PHP бы не было.

Python/Ruby по производительности сливают нормальным ЯП конкретно. Поэтому лучше сразу на Java делайте средний проект, на вырост. Потом большого геморроя избежите, по переписыванию с сабжей на приличный ЯП.

Они вполне успешно заняли свою нишу.

Вообще-то это проблема, что ты не знаешь, что нужно экранировать.

Т.е. люди, которые пишут на PHP некий скрипт, не знают, что им нужно экранировать?

Гм, переводить данные от пользователя в html entities - это ошибка.

Интересно, как был сделан такой вывод, при условии что никем не оговаривалось как и где будут использоваться приехавшие от юзера данные? Может именно HTML entities и требуются.

Для перла - это непринципиально вообще, ибо в нём есть удобный инструмент для реализации любого экранирования.

В PHP такого инструмента нет.

magic quotes в PHP были хороши тем, что подходили для большого количества ситуаций. И в большом количестве случаев проще было их включить, чем городить свой код.

Пиэйчпятина.

Гм, переводить данные от пользователя в html entities - это ошибка. А что если нужно будет отправить письмо plain текстом, или сообщение в жаббир? Надо же, уже второй перл-гуру, гроза говнокодеров, слился)

Какое длинное звание :) Я почти польщён.
Других претензий к коду нет? (а то я тут ещё ; забыл) Вообще, я счёл это чем-то вроде perl-golf'а.
На счёт plain/text - это архаизм. Уже давно все шлют и принимают в html. В крайнем случае, обратно преобразовать труда не составляет. Куда важнее, чтобы злой дядька хакер не сделал «живительную» инъекцию.

Прекратят поддержку XP и 2k3 в том смысле, что добавят DirectX 10 или 11.

php -r 'echo 0x0+10;' # 26
php -r 'echo 0x0 + 10;' # 10

Круто, а из-за чего так? Есть логическое объяснение?

Круто, а из-за чего так? Есть логическое объяснение?

У меня нет. Может, я узколоб, но я считаю, что это ошибка.

Так через mod_perl например get/post массивы не приходят ?
Ну что-то вроде как в PHP
script.php?a[]=e1&a[]=e2
получим массив $_GET['a'] из двух элементов «e1» и «e2»

script.php?a[]=e1&a[]=e2
получим массив $_GET['a'] из двух элементов «e1» и «e2»

Человек попросил пример, как это можно сделать ч/з перл. Основная мысль была в s///.

Всегда можно сделать sub escape{ if (ref $a eq ARRAY) { ... } }, и в глубину всё покромсать. Туда же положить bbcode, кавычки «лапки» в «ёлочки» и т.д.

mod_perl

Как-то не пришлось использовать. Вроде, его хают. А так - fast cgi. В перл-фреймворках часто встроены web-серваки (в том числе и боевые).

Других претензий к коду нет?

Еще нужно ескейпить нулевой байт.

В крайнем случае, обратно преобразовать труда не составляет.

Вот не надо учить людей плохому. Ты будешь преобразовать обратно, чтобы посчитать правильную длину строки? Или, к примеру, тебе надо обрезать текст до 200 символов - и опять преобразовывать обратно, чтобы не обрезалось где-то между & и ;? Может даже держать по две переменных, var_escaped и var_unescaped? А данные, которые ты читаешь из файлов, тоже сразу ескейпишь? А данные, которые загружаешь по http со сторонних сервисов? А если в БД еще что-то обрабатывается хранимыми процедурами, переконвертация там просто песня.

Данные должны быть «как есть» и в переменных, и в БД. А ескейпить их надо при составлении SQL запроса и при генерации HTML.

На счёт plain/text - это архаизм.

Вообще-то это RFC. :)

Уже давно все шлют и принимают в html.

Ваши «все» живут где-то в соседних квартирах? :) В любом случае, «Отучаемся говорить за всех!».

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

В крайнем случае, обратно преобразовать труда не составляет.

Зачем?

Может, стоит всё же не увлекаться игрой с возможностями экранирования в любимом языке и делать то, что действительно необходимо, там, где в этом есть необходимость, а не только возможность?

Тот аноним и был я, просто magic quotes в пыхе обычно с переменных get/post начинается. Я и пример на php накатил как вручную закодить magic quotes рекурсивно с массивами. Было утверждение от некоего перлюбителя Stanson, что на php magic quotes десяток строк потребуется, а вы оказывается имели ввиду регулярками по хэшу тут ходить и однострочниками хвастаться :)))

Вот не 100 и даже не 10:

foreach($_GET as $k => $v) $_GET[$k] = addslashes($v);

или с регулярным выражением

foreach($_GET as $k => $v) $_GET[$k] = preg_replace("#([\"'\\\\\\0])#", '\\\\$1', $v);

Интересно, как был сделан такой вывод, при условии что никем не оговаривалось как и где будут использоваться приехавшие от юзера данные? Может именно HTML entities и требуются.

Покажите как одной строкой на перле magic quotes делаются ? В перле не силен просто :(

Magic quotes не вставляют HTML entities

Для перла - это непринципиально вообще, ибо в нём есть удобный инструмент для реализации любого экранирования.

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

В PHP такого инструмента нет.

Вообще-то есть.

$stmt = $conn->prepare(«select field from table where id=?»); $stmt->bindValue(1, $_GET['id']); $stmt->execute();

или

$template->setVar('name', htmlspecialchars($_GET['name']));

magic quotes в PHP были хороши тем, что подходили для большого количества ситуаций. И в большом количестве случаев проще было их включить, чем городить свой код.

Ну вот, пхп разработчики, которых вы недолюбливаете уже выкинули эти magic quotes, как зло, которое не надо даже для совместимости, а перловики хвалятся: «а мы это делаем вот так, в одну строчку»)

Да кто Вам такое сказал?

Вообще-то дядя шутит, и речь идёт про заявления при создании.

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

Есть PHP для начального уровня

Есть python для начального уровня

Вот не надо учить людей плохому.

Zend эскейпит, Mojo тоже - это так, на вскидку. Чего же все вокруг делают обработку неправильно?

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

Меня в этой ситуации больше поражает то, что Вы даже не хотите попробовать думать в сторону TMTOWTDI.

Уже давно все шлют и принимают в html.

Принимают, как правило, в папочку spam. А то ещё drop/reject сразу. :-)

Отучаемся говорить за всех!

«Подавляющее множество людей» - звучит «угловато».

Вообще-то это RFC. :)

Это всё замечательно. Я даже верю в IP по голубиной почте. Но в реальном мире правит рынок. Людям нравится, когда красиво свёрстано, когда логотипы и прочие радости жизни.

Зачем?

Ну как «зачем»? В базе лежат уже гарантированно _чистые_ данные, готовые к употреблению даже самой же базой.

там, где в этом есть необходимость, а не только возможность?

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

Ах, да, чуть не забыл. А с <iframe src="http://evilhacker.com/"></iframe> Вы что делаете? Не то же самое, что я предлагаю?

Принимают, как правило, в папочку spam. А то ещё drop/reject сразу. :-)

Надо рассказать фейсбуку и прочим, что их письма не доходят :(

Может 0x0+10 это один из видов записи hex-чисел? Или благодаря правилам нестрогой типизации с неявным приведением типов 0x0+10 приводится к строке? Хотя 0x010 тоже ведь не 26 :)

Zend эскейпит

Нет, он как раз эскейпит при составлении запроса и в шаблонах, как и я сказал, а не по принципу magic quotes, или тем более html entities. http://framework.zend.com/manual/ru/zend.view.scripts.html http://framework.zend.com/manual/en/zend.db.statement.html

Mojo

не имел с ним дело

Меня в этой ситуации больше поражает то, что Вы даже не хотите попробовать думать в сторону TMTOWTDI.

Этот вопрос уже обговорен по 100 раз еще во времена php 4

Туда же положить bbcode

А вот скажите, если допустим у вас есть бб-код К лору из которого вы сразу же делаете <a href="http://linux.org.ru/">К лору</a>, записываете в БД, как вы потом его перепарсите обратно, когда пользователь к примеру захочет подредактировать свой пост?

гм) бб-код К лору

бб-код [url=http://linux.org.ru/] К лору[/url]

Нет, он как раз эскейпит при составлении запроса и в шаблонах

И тут я вспомнил, что перед ним стоял ckeditor. Прошу прощения - здесь моя промашка.

Что же, приходится признать, что мой пример был некорректен.

Почему не держать оба варианта в бд? Особенно, если разметок много.

Ответ очевиден: чтобы не держать оба варианта в БД) К тому же как вы будете там держать оба варианта, если у вас сразу в переменных HTML код