Группа elhacker.net провела небольшое исследование и пришла к выводу (http://www.opennet.me/base/cgi/1147797595_4096.txt.html), что практически 90% исследованных продуктов на PHP (19 из 21 в случайной выборке) позволяют узнать текущий путь их установки в системе ("Full Path Disclosure" уязвимость).
С первого взгляда проблема выявления пути установки не представляет реальной угрозы и выглядит несерьезно, но позволяет оценить общее отношение большинства PHP разработчиков к проблемам безопасности, игнорирующих основы безопасного программирования.
В качестве другого примера может выступить практически ежемесячное нахождение серьезных проблем безопасности в популярных открытых системах управления конетном (http://wiki.opennet.ru/CMSComparison) и движках форумов (http://wiki.opennet.ru/ForumComparison). Например, на этой неделе прошла информация о выявлении новых SQL-Injection проблем в YapBB и phpBB.URL: http://www.opennet.me/base/cgi/1147797595_4096.txt.html
Новость: http://www.opennet.me/opennews/art.shtml?num=7527
Если руки не из того места растут, то всё что угодно можно сделать.
стоит признать, что это происходит из-за лёгкости в освоении данного языка. Как следствие, много новичков пишут "боевые" системы, допуская ошибки по незнанию, или элементарной программистской безграмотности. Разбирал тут одну корпоротивную систему, запстил с показом notify - около 1400 замечаний при обработке одной страници
ой. это на русском?
А все из-за того, что заказчики "жмотятся" на нормальную з/п за проект. Если бы студентов вначале учили "грамотности", а не (полагаясь на дешевизну) давали production-проекты, (имхо) таких бы дырок находилось меньше.
Абсолютное большинство заказчиков не знает что такое PHP и не способно оценить профессиональный уровень исполнителя. В большинстве случаев требования к качеству кода не ставятся вовсе. Какая разница сколько заплатит заказчик, если в итоге он всё ровно рискует получить то же самое. Если конечно это не большой заказ на действительно крупную сумму и какого-нибудь толкового программиста или web-студию не задушит жаба его отбить у гастрабайтеров, пока они его не забрали демпенговыми методами.
Риск, риску рознь.Расчитывая за 100$ получить какую либо серьезную прикладуху, заказчик изначально увеличивает эти риски до 100% вероятности.
От меня подобным образом проекты уходили, хоть это и не мой основной кусок хлеба. И какбы насколько я вижу, проекты эти, так потихоньку и умерли.. если вообще разродились.
С моей точки зрения, люди, которые не способны оценить трудоемкость проекта и свои трудозатраты, либо оценивающие их занижено, с гораздо большей вероятностью накосячат в конечном результате.
Только вот с точки зрения заказчика, к примеру 300$ против 1000$ перебивают все разумные доводы и последние отголоски разума :).
>Риск, риску рознь.> Расчитывая за 100$ получить какую либо серьезную прикладуху, заказчик изначально
> увеличивает эти риски до 100% вероятности.У меня складывается впечатление, что в нашей стране многие руководители совершено не умеют оценивать риски и принимать решения исходя из их существования. И дело касается не только безопасноти но и любых других факторов, которые носят вероятностный характер.
Например многие экономят на бесприбойниках (UPS), несмотря на то, что простой при отключении питания может принеси убытков гораздо больше чем этот UPS стоит... Все надеются на авось. Авось в этом году не будет перебоев с питанием. Авось нашим сайтом не заинтересуются хакеры.
Любой динамичесчий контент это одна большая дыра :)
Программист может быть очень квалифицированным, но он не хакер, который специализируется именно на поиске таких уязвимостей. Так как практически невозможно написать качественный код большоего проекта на том что по определению дыряво как решето. Это относится не только к PHP.
>Любой динамичесчий контент это одна большая дыра :)
>Программист может быть очень квалифицированным, но он не хакер, который специализируется именно
>на поиске таких уязвимостей. Так как практически невозможно написать качественный код
>большоего проекта на том что по определению дыряво как решето. Это
>относится не только к PHP.А что программист уже не компетентен делать простые проверки входящих параметров ? Все зло от этого, и никакого хакерства, просто смотри и проверяй что приходит от юзера.
>А что программист уже не компетентен делать простые проверки входящих параметров ?
>Все зло от этого, и никакого хакерства, просто смотри и проверяй
>что приходит от юзера.В 99.9% программист не будет лезть в исходники функции что-бы определить как надо фильтровать входные данные от пользователя. Есть конечно некие базовые вещи котрые надо проверять, но они полностью не избавляют от проблемы.
Дыры то как правило находят все новые и новые :)
>В 99.9% программист не будет лезть в исходники функции что-бы определить как
>надо фильтровать входные данные от пользователя. Есть конечно некие базовые вещи
>котрые надо проверять, но они полностью не избавляют от проблемы.
>Дыры то как правило находят все новые и новые :)Нужно отделять мух от котлет, дыры в самом php и дыры в программах на php. Программист программируюя форум обязан проверить, чтобы в переменной с именем пользователя не прошла часть SQL запроса, как минимум нужно спецсимволы экранировать.
>Нужно отделять мух от котлет, дыры в самом php и дыры в
>программах на php. Программист программируюя форум обязан проверить, чтобы в переменной
>с именем пользователя не прошла часть SQL запроса, как минимум нужно
>спецсимволы экранировать.А можно пример в студию для экранирования такой классики как ' or 'a'='a
>А можно пример в студию для экранирования такой классики как '
>or 'a'='aВ PEAR quoteSmart не подойдёт? Которая для MySQL в итоге вызывает mysql_real_escape_string.
Просто я PEAR::DB частенько пользуюсь..
>>А можно пример в студию для экранирования такой классики как '
>>or 'a'='a
>
>В PEAR quoteSmart не подойдёт? Которая для MySQL в итоге вызывает mysql_real_escape_string.
>
>Просто я PEAR::DB частенько пользуюсь..А PEAR quoteSmart исходники досконально просмотренны ?:) оно во всех случаях вернет реальную строку или есть шанс что нет ?
ну и второй вопрос, многие высококвалифицированные программисты знают про такие уязвимости ?
>А можно пример в студию для экранирования такой классики как '
>or 'a'='a
stripSlashes() ?
>>А можно пример в студию для экранирования такой классики как '
>>or 'a'='a
>
>
>stripSlashes() ?
сравните http://ru.php.net/manual/ru/function.stripslashes.php и http://ru.php.net/manual/ru/function.addslashes.php
>сравните http://ru.php.net/manual/ru/function.stripslashes.php и http://ru.php.net/manual/ru/function.addslashes.phpУупс! Конечно же я имел ввижу addSlashes().. названия перепутал, т.к. давно на РНР ничего не писал %)
>>Любой динамичесчий контент это одна большая дыра :)
>>Программист может быть очень квалифицированным, но он не хакер, который специализируется именно
>>на поиске таких уязвимостей. Так как практически невозможно написать качественный код
>>большоего проекта на том что по определению дыряво как решето. Это
>>относится не только к PHP.
>
>А что программист уже не компетентен делать простые проверки входящих параметров ?
>Все зло от этого, и никакого хакерства, просто смотри и проверяй
>что приходит от юзера.Неправы! Пример: скрипт подключается к базе, хакер (читать кракер) прибивает хост с субд к примеру дос-атаками или использует SQL-иньекции чтобы подвесить базу, далее скрипт не ощутив коннекта к базе рапортует: "мля немогу подконектится к базе такойто, юзер такойто, пароль такойто..." Реально? Я так поимел одного асп-ешника, а сайт крупной торговой фирмы :) было весело вообщем. БЕЗГРАМОТНОСТЬ ПРОГРАММЕРОВ ПОРАЖАЕТ ПОРОЙ :)
> Любой динамичесчий контент это одна большая дыра :)
> Программист может быть очень квалифицированным, но он не хакер, который специализируется
> именно на поиске таких уязвимостей. Так как практически невозможно написать качественный
> код большоего проекта на том что по определению дыряво как решето.Очень много зависить от программиста от его стиля работы.
Если писать заведомо дярыве приложения, а потом латать те уязвимости которые найдены, то будет как Вы описываете. Поскольку в плохо написанном приложении хакер всегда найдет больше дырок чем программист.
Но если писать c security in mind, то все силньо меняется. Причем это не намного сложнее. Просто нужно уметь писать безопасно. А если человек научился этому, то он будет писать качественный код с такой же скоростью как новичок пишет небезопасный код.
Многие программисты не утруждают себя даже проверкой входных параметров. Их приложения, конечно, дырявы. Из этого не следует, что все веб приложения дырявы как решето.
Многие из тех, кто пишут небезопасные приложения даже не слышали что такое SQL Injections, а если и слышали то не понимают как это относится к их приложениям.
В общем вывод такой - учиться, учиться и еще раз учиться. (c) Ленин.
Читать книжки вроде OWASP Guide
http://www.owasp.org/documentation/guide/guide_about.html
и другие.Еще хочу заметить, что качество кода и его безопасность вещи взаимосвязанные. Те кто пишут небезопасный код делают больше багов не связанных с безопасностью...
Дыры есть в любом софте. Абсолютно.
И не нада говорить конкретно про php.
Этак если взять OSS С программы, то можно сказать что дыры есть в 100% программ?
Именно так оно и есть :)
Чем выше уровень абстракции у какого-либо инструмента, тем больше потенциальных уязвимостей в нем. :) И тем больше потенциальных уязвимостей у проекта на нем написанном.
И в тоже время, на дырявом интрументе можно создать проект на 99% процентов свободном от уязвимостей, но это уже совсем другая тема :)
>Дыры есть в любом софте. Абсолютно.Все чаще и чаще слышу подобное заблуждение. Видимо какя-то попытка оправдать собственную безграмоность.
PS. Учится нужно по работам DJB и Wietse Venema. Посмотри security.html из Postfix, там на одной странице рассказано как избежать 99% проблем.
Это не заблуждение, это статистика. Дыры есть абсолютно в люых _функциональных_ приложениях .
>Это не заблуждение, это статистика. Дыры есть абсолютно в люых _функциональных_ приложениях
>.Можно написать любое функциональное приложение в котором не будет дыр, лишь бы голова у разработчиков была там где нужно. Ваша статистика говорит о плачевном состоянии уровня образования большинства разработчиков, которые для своего оправдания и выдумывают мифы о невозможности избежать простейших дыр. 99% дыр можно избежать на этапе разработки и отладки, 1% оставим под человеческий фактор :-)
Посмотрите сколько Coverty своим роботом находит багов, и сколько из них, на которые даже показали пальцем, исправлены.
Всё правильно. И новичков много, и заказчики жмотятся. Сюда же можно доавить общую спешку и неорганизованность, которые сопровождают появление любого большинства проектов...
Но РНР сам по себе дедисциплинирует программиста.
1) Только в угаре можно было додуматься смещивать код и данные! В век, когда придуманы 1001 способ разделить код и данные от конфигов и .h-файлов до шаблонов и баз данных наконец... в это всремя появляется "язык" в котором код и данные перемешаны! Это в голове не укладывается! Врезультате невозможносопровождать ни HTML-код (данные), ни PHP-код. Отсюда и появляются всякие уродцы.
2) Я всё понимаю. Очень мило вкомпилить всё в сервер, но получается, что язык содержит около 3000 функций. Причём их набор зависит от сборки. Отсюда:
2.1) Код получается непереносимым
2.2) Никто не знает весь РНР. Новый программист не очень понимает то, что писал старый, появляются нагромождения кода и дыры в защите.
3) При необъятности возможностей (нездоровой) РНР остаётся фантастически примитивным языком. Я молчу про то, что межанизм указателей в нём находится на уровне Perl4, но есть совершенно непростительные ляпы. Например в точке вызова функции не видно, как передаётся параметр: по ссылке или по значению. (Тоже относится и к возвращаемым значениям) Это пораждает неразбериху при совместной разработке или при последующей доработке.
Короче РНР -- ЗЛО )
>ни HTML-код (данные), ни PHP-код
HTML-код - это оформление, а никак ни данные>2.1) Код получается непереносимым
с чего бы это? доставь нужное расширение и все. как это связано с переносимостью?>2.2) Никто не знает весь РНР. Новый программист не очень понимает то, что писал старый, появляются нагромождения кода и дыры в защите.
бред пишите, уважаемый, бред
PHP очень хорошо дукументирован>межанизм указателей в нём находится на уровне Perl4
каких еще указателей? их там нет вообще! а были бы, дыр было бы просто море>Например в точке вызова функции не видно, как передаётся параметр: по ссылке или по значению. (Тоже относится и к возвращаемым значениям)
можно поподробнее?>Это пораждает неразбериху при совместной разработке или при последующей доработке.
по-моему, проблема в организации..
>HTML-код - это оформление, а никак ни данные
Какая разница. Всё-равно любой нормальный человек постарается отделить оформление от исполняемого кода. А в PHP теперь пишут целый фреймворки с реализацией Model-View-Controller. Ибо такое встраивание годится только для гостевой книги и не больше.>>2.2) Никто не знает весь РНР. Новый программист не очень понимает то, что писал старый, появляются нагромождения кода и дыры в защите.
>бред пишите, уважаемый, бред
>PHP очень хорошо дукументирован
Документация не причём. Но PHP, можно сказать, "стимулирует" новичка писать код так, что он в дальнейшем нечитабелен. И нужно предельно аккуратно относится к своему коду, чтобы он не превратился в помойку в последствии, даже если дизайн хороший.
А много человек знают весь STL? Начать с того, что там дефолтный аллокатор глюкавый в реализации GNU. Об этом узнаёшь случайно, когда наткнёшься.. Реализации поставляющиеся с коммерческими компиляторами при этом работают нормально.>>Например в точке вызова функции не видно, как передаётся параметр: по ссылке или по значению. (Тоже относится и к возвращаемым значениям)
>можно поподробнее?
Пишешь вызов ф-ии и передаёшь ей аргумент. В этом месте не видно, по ссылке или значению была передана переменная, нужно смотреть объявление самой функции. Но этим и .Net страдает, уж на что элегантный язык, и на с++ такой подход зачастую используется.Перефразирую: PHP - зло для больших проектов.
>>HTML-код - это оформление, а никак ни данные
>Какая разница. Всё-равно любой нормальный человек постарается отделить оформление от исполняемого кода.
человек, на чей пост был ответ, просто не понимает, о чем пишет, на что и было указано
>А в PHP теперь пишут целый фреймворки с реализацией Model-View-Controller. Ибо
>такое встраивание годится только для гостевой книги и не больше.
никто и не спорит с этим.
кстати, тот же способ, только наоборот, можно использовать и в других языках, например printf("< h1 >%s< /h1 >", header_text);
просто в пхп это сделано несколько более удобно>>>2.2) Никто не знает весь РНР. Новый программист не очень понимает то, что писал старый, появляются нагромождения кода и дыры в защите.
>>бред пишите, уважаемый, бред
>>PHP очень хорошо дукументирован
>Документация не причём. Но PHP, можно сказать, "стимулирует" новичка писать код так,
>что он в дальнейшем нечитабелен.
честно говоря, не особо понимаю, чем он стимулирует это делать..
а если вернуться к изначальному заявлению, то про новичков там ничего не было :) если автор не может сам разобраться в творчестве предшественника, либо полагает, что после него нельзя будет разобраться.. ну что ж.. причины могут быть разными :)> И нужно предельно аккуратно относится к
>своему коду, чтобы он не превратился в помойку в последствии, даже
>если дизайн хороший.
само собой, это всегда нужно>А много человек знают весь STL? Начать с того, что там дефолтный
>аллокатор глюкавый в реализации GNU. Об этом узнаёшь случайно, когда наткнёшься..
>Реализации поставляющиеся с коммерческими компиляторами при этом работают нормально.
это скорее проблемы реализации, а не документирования>>>Например в точке вызова функции не видно, как передаётся параметр: по ссылке или по значению. (Тоже относится и к возвращаемым значениям)
>>можно поподробнее?
>Пишешь вызов ф-ии и передаёшь ей аргумент. В этом месте не видно,
>по ссылке или значению была передана переменная, нужно смотреть объявление самой
>функции.
а нужно ли это? я пока не замечал такой необходимости..
если вы используете функцию, то должны бы знать как ее использовать>Перефразирую: PHP - зло для больших проектов.
это весьма существенное дополнение по сравнению с первоисточником, не правда ли? :)
> бред пишите, уважаемый, бред
> PHP очень хорошо дукументирован
Да? А вот, например, ссылка
http://ru.php.net/manual/ru/function.imagefttext.php
указывает на обратное.
Хотя, как написано, "(PHP 4 >= 4.1.0, PHP 5)", т.е. функция появилась ешё в php-4.1.0.
>> бред пишите, уважаемый, бред
>> PHP очень хорошо дукументирован
>Да? А вот, например, ссылка
>http://ru.php.net/manual/ru/function.imagefttext.php
>указывает на обратное.
>Хотя, как написано, "(PHP 4 >= 4.1.0, PHP 5)", т.е. функция появилась ешё в php-4.1.0.
да, наверное, я несколько неточен был :)
скажем так, наиболее востребованные функции хорошо документированы
что касается вашей ссылки, то там из контекста непонятен только последний опциональный аргумент.. все относительно
Наплевательское отношение программистов к безопасности действительно удручает.Не раз когда я говорил некоторым людям о том, что в их веб-приложениях есть уязвимости я получал ответ - а мне плевать, мне деньги платят за то, чтоб работало, а не за безопасность.
но, темнеменее обсуждая здесь эту тему мы можем подчеркнуть это для себя, а всем остальным впринципе напливать, многие веберы, покажут красиво оформленый движок возьмут деньги отдадут диск или накрайняк для заказчика зарегают на хостинге домен,зальют и всё, а что там и как написано одному писальщику известно. и если несказать хуже он сам незнает отом какого он написал, потомучто после написания протестил только работоспособность и неболее...
>а всем остальным впринципе напливать, многие веберы, покажут красиво оформленый движок
>возьмут деньги отдадут диск или накрайняк для заказчика зарегают на хостингеЧасто отдают скомпилированные zend encoder бинарники, так что даже очевидные ошибки в их поделке не поправить своими силами, а через полгода и след от тех девелоперов простынет.
Есть одни знакомые купившие за огромные деньги популярный коммерческий движок на php и уже не первый месяц добиваются чтобы в него отложенные insert включили, иначе в пиках все затыкается, сами бы сделали все за пять минут, да не тут то было. Вот вам и отличие бесплатного софта и программ за 10k$, и там и там о безопасности и производительности не думают.
>Часто отдают скомпилированные zend encoder бинарники, так что даже очевидные ошибки в
>их поделке не поправить своими силамиДа, вот это вообще ужасно :-((
/me тестирует такой продукт
ps. offtopic
Зазенденые скрипты не проблема, могу раскриптовать зазенденые файлы...
Будет не дорого стоить ;)
читаем название ньюса, а не про то что кого закодировал!!!! или желает декодировать.....
Я тоже согласен со всем сказаным выше. Работал в московсом институте (причем не из самых плохих) и при этом часто общался со студентами с кафедры информационных технологий. Вы бы видели, как ужасно там преподают! Сидят там старперы всякие, которые гоняют ребят в основном, по математике, а прикладных знаний не дают вообще. Например, приходит ко мне парень и показывает php код и спрашивает, почему он у него не работает. А у него все вызовы выглядят как func_(args), а там где я написал _ у него стоят пробелы. Когда я спросил, почему у него такие глупые ошибки, им чего, основы синтаксиса то же самой сюхи не объясняли? - он сказал, что нет, они ряды всякие раскладывают в основном. А парень то далеко не глупый. Старается, я вижу. А вы бы видели, как им объясняли SQL! Бабуля какая то им это читала. Бабуля! А еще она им читает математические принципы работы RSA, не обяснив им даже сначала основных принципов работы алгоритмов с открытым ключом. Не объяснила даже студентам, что означает mod в ее лекциях. Что такое арифметика в классах вычетов, ребята до сих пор так и не знают, зато ряды они раскладывают професионально :) А ведь уже завтра эти выпускники пополнят ряды новоявленных программеров с кашей в голове, какя тут нахрен безопасность! А работодателям все по фигу, им самое главное, чтобы специалист поменьше зарплаты себе требовал. Отсюда и обьявления вида "Требуется специалист со знаниями perl, php, ruby, python, c, c++, java, apache, linux, html, xml (не хватает еще пролога и лиспа для крутости) на зарплату 600$", коими завалены российские сайты поиска работы. Понятно, какой человек откликнется на такое предложение. Или вот такое предложение, на которое я натолкнулся пару месяцев назад, там пишут, что молодой и переспективной фирме, занятой в области аудита безопасности требуется безопасник со знаниями стека протоколов TCP/UDP. Я не описался - именно TCP/UDP! Представляете, что в итоге получится, когда такой аудитор поработает над программным проектом, написанным тем самым программером за 600$? А потом они будут впаривать нам свое совместно накаляканное чудо за вполне приличные деньги. И никуда тут не денешься, потому что живем мы в раздолбайской стране, единственной стране в мире, где в национальном языке есть такое слово, как "халява". Плохо все, короче.