The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Около 90% программ на PHP содержат проблемы безопасности

16.05.2006 22:47

Группа elhacker.net провела небольшое исследование и пришла к выводу, что практически 90% исследованных продуктов на PHP (19 из 21 в случайной выборке) позволяют узнать текущий путь их установки в системе ("Full Path Disclosure" уязвимость).

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

В качестве другого примера может выступить практически ежемесячное нахождение серьезных проблем безопасности в популярных открытых системах управления конетном и движках форумов. Например, на этой неделе прошла информация о выявлении новых SQL-Injection проблем в YapBB и phpBB.

  1. Главная ссылка к новости (https://www.opennet.ru/base/cgi...)
  2. YapBB find.php SQL Injection Vulnerability
  3. PhpBB Admin/Restore Database remote cmmnds
  4. PHPBB 2.0.20 persistent issues with avatars
  5. phpBB "charts.php" XSS and SQL-Injection
  6. SecurityTop - черный и белый список, хороших и безнадежных с точки зрения безопасности программ
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/7527-php
Ключевые слова: php, security
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (37) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Alex (??), 23:13, 16/05/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Если руки не из того места растут, то всё что угодно можно сделать.
     
  • 1.2, Аноним (-), 23:42, 16/05/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    стоит признать, что это происходит из-за лёгкости в освоении данного языка. Как следствие, много новичков пишут "боевые" системы, допуская ошибки по незнанию, или элементарной программистской безграмотности. Разбирал тут одну корпоротивную систему, запстил с показом notify - около 1400 замечаний при обработке одной страници
     
     
  • 2.3, Николай Самохвалов (?), 23:50, 16/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    ой. это на русском?
     
  • 2.4, еще один анонимус (?), 01:27, 17/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    А все из-за того, что заказчики "жмотятся" на нормальную з/п за проект. Если бы студентов вначале учили "грамотности", а не (полагаясь на дешевизну) давали production-проекты, (имхо) таких бы дырок находилось меньше.
     
     
  • 3.5, mutronix (?), 03:58, 17/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    Абсолютное большинство заказчиков не знает что такое PHP и не способно оценить профессиональный уровень исполнителя. В большинстве случаев требования к качеству кода не ставятся вовсе. Какая разница сколько заплатит заказчик, если в итоге он всё ровно рискует получить то же самое. Если конечно это не большой заказ на действительно крупную сумму и какого-нибудь толкового программиста или web-студию не задушит жаба его отбить у гастрабайтеров, пока они его не забрали демпенговыми методами.
     
     
  • 4.6, dct (??), 07:32, 17/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    Риск, риску рознь.

    Расчитывая за 100$ получить какую либо серьезную прикладуху, заказчик изначально увеличивает эти риски до 100% вероятности.

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

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

    Только вот с точки зрения заказчика, к примеру 300$ против 1000$ перебивают все разумные доводы и последние отголоски разума :).

     
     
  • 5.15, citrin (ok), 12:14, 17/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >Риск, риску рознь.

    > Расчитывая за 100$ получить какую либо серьезную прикладуху, заказчик изначально
    > увеличивает эти риски до 100% вероятности.

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

    Например многие экономят на бесприбойниках (UPS), несмотря на то, что простой при отключении питания может принеси убытков гораздо больше чем этот UPS стоит... Все надеются на авось. Авось в этом году не будет перебоев с питанием. Авось нашим сайтом не заинтересуются хакеры.

     

  • 1.7, BB (??), 10:12, 17/05/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Любой динамичесчий контент это одна большая дыра :)
    Программист может быть очень квалифицированным, но он не хакер, который специализируется именно на поиске таких уязвимостей. Так как практически невозможно написать качественный код большоего проекта на том что по определению дыряво как решето. Это относится не только к PHP.
     
     
  • 2.10, uldus (ok), 11:02, 17/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >Любой динамичесчий контент это одна большая дыра :)
    >Программист может быть очень квалифицированным, но он не хакер, который специализируется именно
    >на поиске таких уязвимостей. Так как практически невозможно написать качественный код
    >большоего проекта на том что по определению дыряво как решето. Это
    >относится не только к PHP.

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

     
     
  • 3.25, BB (??), 10:38, 18/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >А что программист уже не компетентен делать простые проверки входящих параметров ?
    >Все зло от этого, и никакого хакерства, просто смотри и проверяй
    >что приходит от юзера.

    В 99.9% программист не будет лезть в исходники функции что-бы определить как надо фильтровать входные данные от пользователя. Есть конечно некие базовые вещи котрые надо проверять, но они полностью не избавляют от проблемы.
    Дыры то как правило находят все новые и новые :)

     
     
  • 4.26, uldus (ok), 11:50, 18/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >В 99.9% программист не будет лезть в исходники функции что-бы определить как
    >надо фильтровать входные данные от пользователя. Есть конечно некие базовые вещи
    >котрые надо проверять, но они полностью не избавляют от проблемы.
    >Дыры то как правило находят все новые и новые :)

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

     
     
  • 5.30, BB (??), 17:07, 18/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >Нужно отделять мух от котлет, дыры в самом php и дыры в
    >программах на php. Программист программируюя форум обязан проверить, чтобы в переменной
    >с именем пользователя не прошла часть SQL запроса, как минимум нужно
    >спецсимволы экранировать.

    А можно пример в студию для экранирования такой классики как  ' or 'a'='a

     
     
  • 6.32, Danil (??), 00:42, 19/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >А можно пример в студию для экранирования такой классики как  '
    >or 'a'='a

    В PEAR quoteSmart не подойдёт? Которая для MySQL в итоге вызывает mysql_real_escape_string.
    Просто я PEAR::DB частенько пользуюсь..

     
     
  • 7.34, BB (??), 10:28, 19/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >>А можно пример в студию для экранирования такой классики как  '
    >>or 'a'='a
    >
    >В PEAR quoteSmart не подойдёт? Которая для MySQL в итоге вызывает mysql_real_escape_string.
    >
    >Просто я PEAR::DB частенько пользуюсь..

    А PEAR quoteSmart исходники досконально просмотренны ?:) оно во всех случаях вернет реальную строку или есть шанс что нет ?
    ну и второй вопрос, многие высококвалифицированные программисты знают про такие уязвимости ?

     
  • 6.33, phpcoder (??), 06:53, 19/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >А можно пример в студию для экранирования такой классики как  '
    >or 'a'='a


    stripSlashes() ?

     
     
  • 7.35, Аноним (-), 13:38, 19/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >>А можно пример в студию для экранирования такой классики как  '
    >>or 'a'='a
    >
    >
    >stripSlashes() ?
    сравните  http://ru.php.net/manual/ru/function.stripslashes.php и http://ru.php.net/manual/ru/function.addslashes.php
     
     
  • 8.36, phpcoder (??), 13:52, 19/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    Уупс Конечно же я имел ввижу addSlashes названия перепутал, т к давно на Р... текст свёрнут, показать
     
  • 3.39, AD3000 (?), 12:43, 05/09/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >>Любой динамичесчий контент это одна большая дыра :)
    >>Программист может быть очень квалифицированным, но он не хакер, который специализируется именно
    >>на поиске таких уязвимостей. Так как практически невозможно написать качественный код
    >>большоего проекта на том что по определению дыряво как решето. Это
    >>относится не только к PHP.
    >
    >А что программист уже не компетентен делать простые проверки входящих параметров ?
    >Все зло от этого, и никакого хакерства, просто смотри и проверяй
    >что приходит от юзера.

    Неправы! Пример: скрипт подключается к базе, хакер (читать кракер) прибивает хост с субд к примеру дос-атаками или использует SQL-иньекции чтобы подвесить базу, далее скрипт не ощутив коннекта к базе рапортует: "мля немогу подконектится к базе такойто, юзер такойто, пароль такойто..." Реально? Я так поимел одного асп-ешника, а сайт крупной торговой фирмы :) было весело вообщем. БЕЗГРАМОТНОСТЬ ПРОГРАММЕРОВ ПОРАЖАЕТ ПОРОЙ :)

     
  • 2.16, citrin (ok), 12:26, 17/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    > Любой динамичесчий контент это одна большая дыра :)
    > Программист может быть очень квалифицированным, но он не хакер, который специализируется
    > именно на поиске таких уязвимостей. Так как практически невозможно написать качественный
    > код большоего проекта на том что по определению дыряво как решето.

    Очень много зависить от программиста от его стиля работы.

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

    Но если писать c security in mind, то все силньо меняется. Причем это не намного сложнее. Просто нужно уметь писать безопасно. А если человек научился этому, то он будет писать качественный код с такой же скоростью как новичок пишет небезопасный код.

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

    Многие из тех, кто пишут небезопасные приложения даже не слышали что такое SQL Injections, а  если и слышали то не понимают как это относится к их приложениям.

    В общем вывод такой - учиться, учиться и еще раз учиться. (c) Ленин.

    Читать книжки вроде OWASP Guide
    http://www.owasp.org/documentation/guide/guide_about.html
    и другие.

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

     

  • 1.8, zk (?), 10:26, 17/05/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Дыры есть в любом софте. Абсолютно.
    И не нада говорить конкретно про php.
    Этак если взять OSS С программы, то можно сказать что дыры есть в 100% программ?
     
     
  • 2.9, BB (??), 10:38, 17/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    Именно так оно и есть :)
    Чем выше уровень абстракции у какого-либо инструмента, тем больше потенциальных уязвимостей в нем. :) И тем больше потенциальных уязвимостей у проекта на нем написанном.
    И в тоже время, на дырявом интрументе можно создать проект на 99% процентов свободном от уязвимостей, но это уже совсем другая тема :)
     
  • 2.11, uldus (ok), 11:09, 17/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >Дыры есть в любом софте. Абсолютно.

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

    PS. Учится нужно по работам DJB и Wietse Venema. Посмотри security.html из Postfix, там на одной странице рассказано как избежать 99% проблем.


     
     
  • 3.23, fresco (?), 09:36, 18/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    Это не заблуждение, это статистика. Дыры есть абсолютно в люых _функциональных_ приложениях .
     
     
  • 4.24, uldus (ok), 10:35, 18/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >Это не заблуждение, это статистика. Дыры есть абсолютно в люых _функциональных_ приложениях
    >.

    Можно написать любое функциональное приложение в котором не будет дыр, лишь бы голова у разработчиков была там где нужно. Ваша статистика говорит о плачевном состоянии уровня образования большинства разработчиков, которые для своего оправдания и выдумывают мифы о невозможности избежать простейших дыр. 99% дыр можно избежать на этапе разработки и отладки, 1% оставим под человеческий фактор :-)

    Посмотрите сколько Coverty своим роботом находит багов, и сколько из них, на которые даже показали пальцем, исправлены.

     

  • 1.12, Alex (??), 11:33, 17/05/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Всё правильно. И новичков много, и заказчики жмотятся. Сюда же можно доавить общую спешку и неорганизованность, которые сопровождают появление любого большинства проектов...
    Но РНР сам по себе дедисциплинирует программиста.
    1) Только в угаре можно было додуматься смещивать код и данные! В век, когда придуманы 1001 способ разделить код и данные от конфигов и .h-файлов до шаблонов и баз данных наконец... в это всремя появляется "язык" в котором код и данные перемешаны! Это в голове не укладывается! Врезультате невозможносопровождать ни HTML-код (данные), ни PHP-код. Отсюда и появляются всякие уродцы.
    2) Я всё понимаю. Очень мило вкомпилить всё в сервер, но получается, что язык содержит около 3000 функций. Причём их набор зависит от сборки. Отсюда:
    2.1) Код получается непереносимым
    2.2) Никто не знает весь РНР. Новый программист не очень понимает то, что писал старый, появляются нагромождения кода и дыры в защите.
    3) При необъятности возможностей (нездоровой) РНР остаётся фантастически примитивным языком. Я молчу про то, что межанизм указателей в нём находится на уровне Perl4, но есть совершенно непростительные ляпы. Например в точке вызова функции не видно, как передаётся параметр: по ссылке или по значению. (Тоже относится и к возвращаемым значениям) Это пораждает неразбериху при совместной разработке или при последующей доработке.
    Короче РНР -- ЗЛО )
     
     
  • 2.13, Аноним (-), 12:03, 17/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >ни HTML-код (данные), ни PHP-код
    HTML-код - это оформление, а никак ни данные

    >2.1) Код получается непереносимым
    с чего бы это? доставь нужное расширение и все. как это связано с переносимостью?

    >2.2) Никто не знает весь РНР. Новый программист не очень понимает то, что писал старый, появляются нагромождения кода и дыры в защите.
    бред пишите, уважаемый, бред
    PHP очень хорошо дукументирован

    >межанизм указателей в нём находится на уровне Perl4
    каких еще указателей? их там нет вообще! а были бы, дыр было бы просто море

    >Например в точке вызова функции не видно, как передаётся параметр: по ссылке или по значению. (Тоже относится и к возвращаемым значениям)
    можно поподробнее?

    >Это пораждает неразбериху при совместной разработке или при последующей доработке.
    по-моему, проблема в организации..

     
     
  • 3.19, skyogre (?), 13:14, 17/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >HTML-код - это оформление, а никак ни данные
    Какая разница. Всё-равно любой нормальный человек постарается отделить оформление от исполняемого кода. А в PHP теперь пишут целый фреймворки с реализацией Model-View-Controller. Ибо такое встраивание годится только для гостевой книги и не больше.

    >>2.2) Никто не знает весь РНР. Новый программист не очень понимает то, что писал старый, появляются нагромождения кода и дыры в защите.
    >бред пишите, уважаемый, бред
    >PHP очень хорошо дукументирован
    Документация не причём. Но PHP, можно сказать, "стимулирует" новичка писать код так, что он в дальнейшем нечитабелен. И нужно предельно аккуратно относится к своему коду, чтобы он не превратился в помойку в последствии, даже если дизайн хороший.
    А много человек знают весь STL? Начать с того, что там дефолтный аллокатор глюкавый в реализации GNU. Об этом узнаёшь случайно, когда наткнёшься.. Реализации поставляющиеся с коммерческими компиляторами при этом работают нормально.

    >>Например в точке вызова функции не видно, как передаётся параметр: по ссылке или по значению. (Тоже относится и к возвращаемым значениям)
    >можно поподробнее?
    Пишешь вызов ф-ии и передаёшь ей аргумент. В этом месте не видно, по ссылке или значению была передана переменная, нужно смотреть объявление самой функции. Но этим и .Net страдает, уж на что элегантный язык, и на с++ такой подход зачастую используется.

    Перефразирую: PHP - зло для больших проектов.

     
     
  • 4.28, Аноним (-), 14:15, 18/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    человек, на чей пост был ответ, просто не понимает, о чем пишет, на что и было у... большой текст свёрнут, показать
     
  • 3.21, Dimez (??), 16:55, 17/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    > бред пишите, уважаемый, бред
    > PHP очень хорошо дукументирован
    Да? А вот, например, ссылка
    http://ru.php.net/manual/ru/function.imagefttext.php
    указывает на обратное.
    Хотя, как написано, "(PHP 4 >= 4.1.0, PHP 5)", т.е. функция появилась ешё в php-4.1.0.
     
     
  • 4.29, Аноним (-), 14:20, 18/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >> бред пишите, уважаемый, бред
    >> PHP очень хорошо дукументирован
    >Да? А вот, например, ссылка
    >http://ru.php.net/manual/ru/function.imagefttext.php
    >указывает на обратное.
    >Хотя, как написано, "(PHP 4 >= 4.1.0, PHP 5)", т.е. функция появилась ешё в php-4.1.0.
    да, наверное, я несколько неточен был :)
    скажем так, наиболее востребованные функции хорошо документированы
    что касается вашей ссылки, то там из контекста непонятен только последний опциональный аргумент.. все относительно
     

  • 1.14, citrin (ok), 12:09, 17/05/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Наплевательское отношение программистов к безопасности действительно удручает.

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

     
  • 1.17, umnik (?), 12:44, 17/05/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    но, темнеменее обсуждая здесь эту тему мы можем подчеркнуть это для себя, а всем остальным впринципе напливать, многие веберы, покажут красиво оформленый движок возьмут деньги отдадут диск или накрайняк для заказчика зарегают на хостинге домен,зальют и всё, а что там и как написано одному писальщику известно. и если несказать хуже он сам незнает отом какого он написал, потомучто после написания протестил только работоспособность и неболее...
     
     
  • 2.20, uldus (ok), 14:12, 17/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >а всем остальным впринципе напливать, многие веберы, покажут красиво оформленый движок
    >возьмут деньги отдадут диск или накрайняк для заказчика зарегают на хостинге

    Часто отдают скомпилированные zend encoder бинарники, так что даже очевидные ошибки в их поделке не поправить своими силами, а через полгода и след от тех девелоперов простынет.

    Есть одни знакомые купившие за огромные деньги популярный коммерческий движок на php и уже не первый месяц добиваются чтобы в него отложенные insert включили, иначе в пиках все затыкается, сами бы сделали все за пять минут, да не тут то было. Вот вам и отличие бесплатного софта и программ за 10k$, и там и там о безопасности и производительности не думают.


     
     
  • 3.27, phpcoder (??), 13:56, 18/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >Часто отдают скомпилированные zend encoder бинарники, так что даже очевидные ошибки в
    >их поделке не поправить своими силами

    Да, вот это вообще ужасно :-((


    /me тестирует такой продукт

     
  • 3.31, sniff (?), 20:18, 18/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    ps. offtopic
    Зазенденые скрипты не проблема, могу раскриптовать зазенденые файлы...
    Будет не дорого стоить ;)
     
     
  • 4.37, umnik (?), 19:58, 20/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    читаем название ньюса, а не про то что кого закодировал!!!! или желает декодировать.....
     

  • 1.38, scum (??), 14:36, 25/05/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Я тоже согласен со всем сказаным выше Работал в московсом институте причем не ... большой текст свёрнут, показать
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру