LINUX.ORG.RU

В мае будет проведен месяц безопасности PHP

 , , , ,


0

0

Стефан Эссер (Stefan Esser), создатель проекта Hardened-PHP, объявил о проведении в мае инициативы по увеличению безопасности интерпретатора PHP. Мероприятие повторяет по своей сути проведенную в марте 2007 года акцию «Месяц ошибок в PHP», в рамках которой в PHP было обнаружено более 40 проблем безопасности.

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

Работы принимаются до 11 апреля. Победители будут определены экспертным советом и получат призы. Участники конкурса занявшие с первого по четвертое место получат возможность бесплатно посетить конференцию SyScan, кроме того в зависимости от занятого места им будет предоставлено денежное вознаграждение: за первое место - 1000 евро, второе - 750 евро, третье - 500 евро, четвертое - 250 евро. Занявшие с 5 и 6 место получат лицензию на ПО CodeScan PHP, а с 7 по 16 место - 65-долларовые купоны для интернет-магазина Amazon.

Победители будут объявлены 1 мая, в дальнейшем весь май, день за днем, работы участников конкурса и информация об обнаруженных новых уязвимостях будет публиковаться на сайте php-security.org.

Текст объявления

Сайт проекта

>>> Подробности

★★★★★

Проверено: boombick ()

Ответ на: комментарий от KRoN73

Просто её либо допиливать, либо отключать... Проще второе.

helios ★★★★★
() автор топика

> за первое место - 1000 евро, второе - 750 евро, третье - 500 евро, четвертое - 250 евро.

А смысл при таких тарифах занимать первое место?

anonymous
()

Чтож,очень положительная акция.Надеюсь она превратиться в тенденцию!

pinachet ★★★★★
()
Ответ на: комментарий от anonymous

>> за первое место - 1000 евро, второе - 750 евро, третье - 500 евро, четвертое - 250 евро.

А смысл при таких тарифах занимать первое место?

Гуголь за рабочий эксплойт даёт 1337 баксов, а тут можно и планами на будущее обойтись...

helios ★★★★★
() автор топика

разработчикам пыхи выдадут гандоны чтобы они больше не размножались?

anonymous
()

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

d1337r
()

> В мае будет проведен месяц безопасности PHP

на так в мае бы новость и запостили. что это дерьмище делает на главной лора. Вы бы еще новости о событиях которые через год произойдут постили бы, ага. Модераторы там дрочат сидят что ли?

anonymous
()
Ответ на: комментарий от anonymous

Анонимус настолько суров, что читает только заголовок!

Конкурс открыли сейчас. Потом подведут итоги, залатают дыры и с 1ого мая месяц будут думать кудадальше копать...

helios ★★★★★
() автор топика

?

>>> безопасности PHP

безопасности
PHP

segmentation fault

anonymous
()
Ответ на: комментарий от KRoN73

> Неужели Python тоже небезопасен?! :)

Статья про то, как преодолеть дырявость пых-пыха, Казалось бы, при чем тут питон?)

Alesh
()
Ответ на: комментарий от Alesh

>Казалось бы, при чем тут питон?)

Казалось бы, при чём тогда утверждение «Отключат динамическую типизацию?» :)

KRoN73 ★★★★★
()
Ответ на: комментарий от Alesh

>Статья про то, как преодолеть дырявость пых-пыха

Кстати, в Пыхе нет дырявостей, на которые идёт намёк :) Дырявости есть в головах определённых программеров (у нас в проекте народ и в Java совал массовые SQL-иньекции... которые, кстати, на PHP, как раз, уже не катят :D - http://www.linux.org.ru/forum/talks/3777592 ). И ещё больше дырявостей в головах некоторых критиков, совершенно не понимающих, о чём речь.

Вот простые уязвимости в библиотеках - да, попадаются. Но где их не бывает?

KRoN73 ★★★★★
()
Ответ на: комментарий от fractaler

> А для ПХП месяц безопасности вообще каждый день объявлять нужно.

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

isden ★★★★★
()

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

fractaler ★★★★★
()
Ответ на: комментарий от isden

>дырявый код можно написать на чем угодно. это скорее показатель кривизны быдлокодера а не языка.
ПХП очень этому способствует. Очень. Писать на нём поначалу надо, одев марлевую повзку, перчатки и каску.

fractaler ★★★★★
()

Сломать все что на пыхе

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

wfrr ★★☆
()
Ответ на: комментарий от fractaler

>ПХП очень этому способствует. Очень.

Примеры, пожалуйста :)

Писать на нём поначалу надо, одев марлевую повзку, перчатки и каску.


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

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

>Примеры, пожалуйста :)
Из жизни не могу, примеры не на мне, невежливо будет :)

Почему я за свою практику в своём продакшн-коде зевнул уязвимость только один раз <...>

Так у тебя и на аватарке 3 головы!

fractaler ★★★★★
()
Ответ на: комментарий от KRoN73

Подведя итоги делаем вывод что главной уязвимостью в PHP является SQL, при этом не только в PHP.

Выход один, отказ от SQL.

SV0L0CH
()
Ответ на: комментарий от wfrr

>Это как 0_o? тамже PreparedStatement!

Ну и что? :D Знаешь поговорку про дурака и хрустальный МПЧ?

Народ вовсю использовал прямые запросы вида
[code]
«INSERT INTO xxx VALUES (»+x+",«+y+»)"
[/code]

При чём некоторые параметры прямо со ввода строкой передавались...

:)

А PreparedStatement и в PHP есть... Во многих вариантах.

Так что не от языка зависит, а от программиста.

KRoN73 ★★★★★
()
Ответ на: комментарий от fractaler

>Из жизни не могу, примеры не на мне, невежливо будет :)

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

Так у тебя и на аватарке 3 головы!


Но программирует только 1/3 из них :)

KRoN73 ★★★★★
()
Ответ на: комментарий от SV0L0CH

>Выход один, отказ от SQL.

Если писать с таким же подходом на noSQL-базах, то уязвимости всё равно будут, хотя и иного плана :) Ну, будут они соваться не в select'ы, а во views'ы...

Лучше вообще отказаться от компьютеров.

...

Но и без компьютеров, блин, уязвимостей дофига всё равно. Наверное, это во Вселенной что-то патчить надо :)

KRoN73 ★★★★★
()
Ответ на: комментарий от SV0L0CH

Неа, используя rewrite часто хочется сделать единую точку входя, для создания произвольной структуры сайта, тут появляеется возможность злоумышленнику читать произвольные файло. Затем если есть аплоад, то это вообще дырищще. Ибо чтобы на жабахостинге выполнить произвольный код, нужно както залить его в classes, а чтобы его туда залить нужно его сначала выполнить, а вот в пыхе...

wfrr ★★☆
()
Ответ на: комментарий от KRoN73

Народ вовсю использовал прямые запросы вида

Ну я такое видел последний раз когда еще студентом пришел на работу и хренел увидев как тип сдает уже третий сайт напейсаный таким манером, ибо уже тгда читал журнал какир и знал про SQL иньекции. Первым делом спросил, а этож небезопасно? На что был ответ: никто не взломал. (косяк в том что я тогда не мог осилить самому сотворить SQL иньекцию, ибо там был не мускуль а нечто более серьезное)

wfrr ★★☆
()
Ответ на: комментарий от KRoN73

>Вот, боюсь я, что чисто языковых примеров найти будет сложно, если вообще возможно.
А я этого и не говорил. Я сказал, что нужно каждый день объявлять месяц безопасности ПХП. При таком раскладе быдлокодеры (не принимать на свой счёт), может, поймут, что когда пишешь на ПХП, то нужно думать в первую очередь не «как бы это заработало», а «как бы не заработало что-то ещё».
И да, мои примеры — скорее человеческие уязвимости, самообман на простоте кода.

fractaler ★★★★★
()
Ответ на: комментарий от wfrr

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

У меня точка входа всегда одна. Обычно, что-то типа:

ewriteCond %{REQUEST_FILENAME}index.html !-f
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule .* /bors-loader.php [L,QSA]

И лоадер такого вида:

include_once('/usr/src/bors/bors-core/main.php');

(прямого вызова нет, так как PHP-код обычно лежит вообще вне прямого доступа http)

И читать произвольные файлы в итоге невозможно в принципе :) Хотя бы потому, что нигде нет прямой загрузки файлов. Ну, конечно, если я где-то что-то не зевнул, зарекаться ни от чего нельзя, но пока такое не всплывало :)

KRoN73 ★★★★★
()
Ответ на: комментарий от wfrr

>Ну я такое видел последний раз когда еще студентом пришел на работу

У ребят в http://www.l2jserver.com/ такое пару лет было не заткнуто :)

Оттуда в наш форк и переползло.

На что был ответ: никто не взломал.


Вот там тоже пару лет никто не ломал, а потом пошли массовые удаления информации из баз данных игровых серверов :)

KRoN73 ★★★★★
()
Ответ на: комментарий от fractaler

>Я сказал, что нужно каждый день объявлять месяц безопасности ПХП.

Нужно. Но не из-за особенностей языка :)

может, поймут, что когда пишешь на ПХП, то нужно думать в первую очередь не «как бы это заработало», а «как бы не заработало что-то ещё».


Повторюсь, PHP тут не при чём :) Более того, тот же mysql_query сегодня менее уязвим, чем прямые SQL-вызовы в Java, потому что mysql_query с некоторых пор не позволяет делать мультизапросы :)

Можно сделать include на любой файл и, таким образом, передавая некорректную ссылку получать что-то, что не предполагалось? Да, в Java такое прямо уже не прокатит, зато прекрасно прокатит в Perl.

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

>Если писать с таким же подходом на noSQL-базах, то уязвимости всё равно будут, хотя и иного плана :)

Это всё экранирование, о нём часто забывают. Помню однажды решил переименовать директории в своей файлопомойке и в целях сортировки решил ставить '#' в начале. Потом като положил туда сорци и набрал make...

В общем дыр везде хватает...

А с SQL и прочим генерируемым кодом непосредственно дела лучше не иметь(собственно так грамотные люди и поступают).

SV0L0CH
()
Ответ на: комментарий от SV0L0CH

>А с SQL и прочим генерируемым кодом непосредственно дела лучше не иметь

Именно так. «Машина должна работать. Человек - думать» (c) IBM

Компьютер железный, пусть он код и генерит :)

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

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

Первое, что приходит на память — interrupted execution.

Можно попробовать на старых версиях пхп:

<?php
    function compare($a, $b)
    {
        global $arr;
        if (isset($arr[3])) {
            unset($arr[3]);
        }

        return 0;
    }

    $arr = array('A', 'B', 'C', 'D', 'E', 'F');
    usort($arr, "compare");
    print_r($arr);
?>

Трабла там в работе zend_hash_sort() — по сишному массиву указателей воссоздаётся PHP-шный массив, при этом если из PHP-массива убрать элемент, при доступе к нему есть вероятность схватить SEGFAULT.

Подобная же фигня (была) возможна со многими функциями (из PHP-расширений), которые использовали convert_XXX_ex() вместо convert_xxx() — при передаче по ссылке аргумента неверного типа возникал E_WARNING, и если был установлен пользовательский обработчик ошибок, он мог угробить PHP :-)

При этом не могу сказать, что все эти ошибки исправлены сейчас — мне в одном проекте пришлось скрестить Kohana 3 и WordPress. И не редки ситуации, когда mod_php при неудачном стечении обстоятельств и включенном обработчике ошибок Kohana укладывается в сегфолт. Осталось сделать минимальный воспроизводимый test case и можно отправлять :-)

sjinks ★★★
()
Ответ на: комментарий от wfrr

> чтобы его туда залить нужно его сначала выполнить, а вот в пыхе...

php_flag engine off

помогает

sjinks ★★★
()
Ответ на: комментарий от sjinks

>Первое, что приходит на память — interrupted execution.

Пардон, а какое это отношение имеет к уязвимости языка? :)

Напомню начало цепочки:

А для ПХП месяц безопасности вообще каждый день объявлять нужно.

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

ПХП очень этому способствует


Вот и стало интересно, чем PHP способствует дырявости кода по сравнению с другими языками :)

То, что в PHP встречаются опасные конструкции - это сколько угодно. Скажем, http://www.linux.org.ru/forum/development/3273356

Но к уязвимости языка это не имеет отношения.

Тем более, что и на Питоне можно словить 1/3 == 0, и на Java Integer(1000) != Integer(1000) ;)

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

> Пардон, а какое это отношение имеет к уязвимости языка? :)

Это уязвимость интерпретатора. Проблема не в том, что это небезопасная конструкция, проблема во внутренней реализации в Zend Engine.

Хотя если языком считать чисто лексику + синтаксис + семантику, то да, уязвимостей, наверное, очень мало.

ПХП очень этому способствует

Если вспомнить register_globals on, magic_quotes_gpc on, magic_quotes_runtime on + прочие «фичи», то да.

Например, привык человек полагаться на мэджик квотс, не использует экранирование переменных в запросе. И т.п. :-)

sjinks ★★★
()
Ответ на: комментарий от sjinks

>Если вспомнить register_globals on

Давно уже по дефолту выключен. И уже много-много лет назад говорилось, что это - зло :)

magic_quotes_gpc on


Кстати, как он сейчас по дефолту? Боюсь, что тоже выключен...

Например, привык человек полагаться на мэджик квотс, не использует экранирование переменных в запросе. И т.п. :-)


Я выше приводил пример, как люди на Java не использовали экранирование :) Но это не говорит о том, что Java способствует SQL-уязвимостям :)

KRoN73 ★★★★★
()

Это они всей толпой соберутся, откроют http://bugs-beta.php.net/ и будут там проблемы с безопасностью и прочие баги искать? :) Пусть сначала разберутся с широко известными старыми багами, а то там половина уже плесенью покрылась. Клоуны.

-- JL

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.