Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 51
Мягко говоря не совсем адекватная оценка…
Для популярных приложений баги ищут специально, и соответвенноо находят чаще, не то что для редко всречающихся…
Для популярных приложений баги ищут специально, и соответвенноо находят чаще, не то что для редко всречающихся…
Где-то в топике есть слово «популярное»? Я говорил о юзабельных приложениях, а не популярных. Если лично Вы или Ваши знакомые используют это приложение — значит оно более-менее юзабельное, и достойно добавления в список.
Что касается «находят чаще» — да, это так. Ну и что? Это не имеет никакого значения при выборе приложения. Если я ставлю малоизвестное приложение, для которого дыры просто никто ещё не искал — это всё-равно будет безопаснее установки популярного, но сильно дырявого приложения. Популярность стоит учитывать только при выборе между двумя «безопасными» приложениями — более популярное, скорее всего, будет безопаснее, т.к. в нём более активно искали дыры.
Что касается «находят чаще» — да, это так. Ну и что? Это не имеет никакого значения при выборе приложения. Если я ставлю малоизвестное приложение, для которого дыры просто никто ещё не искал — это всё-равно будет безопаснее установки популярного, но сильно дырявого приложения. Популярность стоит учитывать только при выборе между двумя «безопасными» приложениями — более популярное, скорее всего, будет безопаснее, т.к. в нём более активно искали дыры.
Если будет желание и кандидаты — можно завести рядом отдельную аналогичную табличку для платных/не-OSS приложений.
Далее,
есть приложения в которых иногда находят уязвимости, но тем не менее их можно считать достаточно надежными — пример Vbulletin форум
Кроме того, зачастую даже сомнительный скрипт можно поставить достаточно «безопасно»
то есть на уровне конфига апача запретить php, ssi, оверрайд опций для всех доступных на запись директорий, расставить права, запретить лишние функции пхп (те же шел-вызовы и варианты).
А еще есть мод-секурити и КО…
Да и для совсем тяжелых случаев — включить selinux или аналог.
Но это все детали, я к тому что подобная классификация малополезна и относительна
есть приложения в которых иногда находят уязвимости, но тем не менее их можно считать достаточно надежными — пример Vbulletin форум
Кроме того, зачастую даже сомнительный скрипт можно поставить достаточно «безопасно»
то есть на уровне конфига апача запретить php, ssi, оверрайд опций для всех доступных на запись директорий, расставить права, запретить лишние функции пхп (те же шел-вызовы и варианты).
А еще есть мод-секурити и КО…
Да и для совсем тяжелых случаев — включить selinux или аналог.
Но это все детали, я к тому что подобная классификация малополезна и относительна
За последний год в Vbulletin два SQL-injection. Даже если не считать остальные уязвимости (и их количество), только эти две показывают, что безопасностью разработчики не очень озабочены: не существует ни одной причины, по которой в приложении могут остаться SQL-injection, после того как разработчики узнали о таком типе уязвимостей! Скажите, пожалуйста, если такое приложение «можно считать достаточно надёжным» — тогда какое нельзя?!
Что касается настроек сервера — это всё нужно делать даже при установке самого безопасного приложения. Ибо в любом приложении есть баги. И, вполне вероятно, неизвестные или приватные дыры. Поэтому такая многоуровневая защита необходима в любом случае. НО! Это не повод ставить дырявое приложение и надеяться на другие уровни защиты. Если бы один из этих уровней давал 100% защиту — никто бы вообще не морочил себе голову написанием безопасных веб-приложений.
Полезность предложенной в топике классификации я вижу в том, чтобы при прочих равных иметь возможность поставить наименее дырявое приложение. Часто клиенты просят «поставить форум». Какой именно — им всё-равно. А у меня критерий один — безопасность. Потому, что за взлом отвечать буду я. И последствия взлома устранять — тоже я. Поэтому лично для меня такая табличка была бы бесценна.
Что касается настроек сервера — это всё нужно делать даже при установке самого безопасного приложения. Ибо в любом приложении есть баги. И, вполне вероятно, неизвестные или приватные дыры. Поэтому такая многоуровневая защита необходима в любом случае. НО! Это не повод ставить дырявое приложение и надеяться на другие уровни защиты. Если бы один из этих уровней давал 100% защиту — никто бы вообще не морочил себе голову написанием безопасных веб-приложений.
Полезность предложенной в топике классификации я вижу в том, чтобы при прочих равных иметь возможность поставить наименее дырявое приложение. Часто клиенты просят «поставить форум». Какой именно — им всё-равно. А у меня критерий один — безопасность. Потому, что за взлом отвечать буду я. И последствия взлома устранять — тоже я. Поэтому лично для меня такая табличка была бы бесценна.
Зачем вы уязвимость плагина расцениваете, как уязвимость самого форума?
А что вам говорит, что разрботчиков не заботит безопасность? Неисправленных ошибок нет
Unpatched 0% (0 of 20 Secunia advisories)
Most Critical Unpatched
There are no unpatched Secunia advisories affecting this product, when all vendor patches are applied…
secunia.com/advisories/product/3212/
Unpatched 0% (0 of 20 Secunia advisories)
Most Critical Unpatched
There are no unpatched Secunia advisories affecting this product, when all vendor patches are applied…
secunia.com/advisories/product/3212/
Нет, не говорит. Когда жареный петух в жопу клюнет (т.е. выпустят CVE и по всем новостям пройдёт новость об очередной уязвимости), большинство дыру довольно быстро заткнёт и выпустит апдейт. Это не называется «заботит безопасность». Когда разработчиков заботит безопасность, они с самого начала пишут код без таких детских дыр, как инъекции SQL или кода. В крайнем случае, они затыкают все дыры такого типа первый раз с ними столкнувшись, и вносят необходимые изменения в процесс разработки/фреймворк/принятые стандарты кодирования, чтобы такие дыры в будущем не появлялись. А когда разработчики затыкают дыру упомянутую в CVE, оставляя рядом другие аналогичные, чтобы заткнуть их когда выйдет следующий CVE — нет, это не называется что их заботит безопасность.
Это получается что если разработчика заботит безопасность он никогда не допустит ошибку?
Он может проверить все? Он знает все? Он Бог?
Многие проекты пишет большое количество народу. Очень сложно проверить весь код, заметить уязвимости которые появились от того что два модуля оказались вместе, а по отдельности багов нет. Баги есть у всех. Если разработчик заботится о безопасности он быстро исправит баг и постарается дальше таких не допустить. Проблема с Opensource приложениями в том что их пишут разные люди. Да за два года может не быть багов. Но за два года все может ужасно устареть. И в новой версии могут наплодить множество багов. Просто потому что ее писали например почти с нуля. Обезопасить сервер можно убрав его в сейф, закрыв на замок, рандомно сгенерировать рут пароль, не знать его самому, а главное не дай бог его не включать в сеть, а то вдруг взломают )
Он может проверить все? Он знает все? Он Бог?
Многие проекты пишет большое количество народу. Очень сложно проверить весь код, заметить уязвимости которые появились от того что два модуля оказались вместе, а по отдельности багов нет. Баги есть у всех. Если разработчик заботится о безопасности он быстро исправит баг и постарается дальше таких не допустить. Проблема с Opensource приложениями в том что их пишут разные люди. Да за два года может не быть багов. Но за два года все может ужасно устареть. И в новой версии могут наплодить множество багов. Просто потому что ее писали например почти с нуля. Обезопасить сервер можно убрав его в сейф, закрыв на замок, рандомно сгенерировать рут пароль, не знать его самому, а главное не дай бог его не включать в сеть, а то вдруг взломают )
Вы говорите очень правильно. Но — теоретически. А я говорю о конкретных багах. Таких, которых, не без причины, называют "детскими". Таких, которых в коде быть не должно в принципе. Ибо никакой проблемы экранировать всё, что отправляется в базу — нет. Равно как и нет никакой проблемы найти в коде все sql-запросы и проконтролировать, что в них всё экранируется. Это тупая, механическая работа, не требующая интеллекта и невероятно высоких скилов. Если она не выполняется — значит разработчиков безопасность их продукта не беспокоит. И значит, меня, и всех кого волнует безопасность, не интересует их продукт.
Что касается «пишут разные люди». Я понимаю их сложности, но… Мне пох. С прибором. Не ебёт. Либо они решают свои проблемы с разными людьми, и добиваются приемлемого уровня безопасности до релиза, либо их безопасность их продукта не беспокоит. Я не вижу никакой проблемы проконтролировать наличие «детских» дыр вроде SQL-injection в коде перед релизом, сколько бы «разных людей» не участвовало в разработке.
Когда я увижу в базе CVE приложение, у которого нет хотя бы детских дыр, тогда будет хоть какой-то повод отнестись к дырам снисходительно, мол, всё не предусмотришь, с каждым может случиться, но они всё-равно молодцы, так мало дыр за столько лет, и все такие уникальные… сразу видно, серьёзно ребята безопасностью озабочены!
Что касается «пишут разные люди». Я понимаю их сложности, но… Мне пох. С прибором. Не ебёт. Либо они решают свои проблемы с разными людьми, и добиваются приемлемого уровня безопасности до релиза, либо их безопасность их продукта не беспокоит. Я не вижу никакой проблемы проконтролировать наличие «детских» дыр вроде SQL-injection в коде перед релизом, сколько бы «разных людей» не участвовало в разработке.
Когда я увижу в базе CVE приложение, у которого нет хотя бы детских дыр, тогда будет хоть какой-то повод отнестись к дырам снисходительно, мол, всё не предусмотришь, с каждым может случиться, но они всё-равно молодцы, так мало дыр за столько лет, и все такие уникальные… сразу видно, серьёзно ребята безопасностью озабочены!
Блин! Вы что, издеваетесь, или действительно ничего не понимаете? Что, от того, что одна из упомянутых мной уязвимостей относится к плагину, vBulletin стал заметно безопаснее? Вам что, мало других уязвимостей? Мне надо их ручками отфильтровать, какие к плагинам относятся, а какие к самому vBulletin? Держите кучку SQL injection именно в vBulletin, не плагинах: CVE-2008-2460, CVE-2007-2911, CVE-2007-1573, CVE-2007-1292, CVE-2006-5104, CVE-2006-2805, CVE-2006-2018, CVE-2005-3024, CVE-2005-3022, CVE-2005-3019,… они не кончились, но мне надоело копипастить. Они годами делают одну и ту же детскую ошибку! Причём там хватает и других ошибок, на одних SQL injection свет не сошёлся.
О чём это говорит лично мне, и многим другим опытным и вменяемым админам и программистам? О том, что там дыры есть и сейчас, их много, и они там будут всегда! Ибо разработчики либо не хотят, либо не могут писать безопасный код в принципе.
И, лично я, выбирая между двумя приложениями, про одно из которых мне известно, что «там дыры есть, их много, и они там будут всегда», а про второе у меня такого рода информации нет — выберу второе. Потому, что хуже — точно не будет, но может быть значительно лучше!
О чём это говорит лично мне, и многим другим опытным и вменяемым админам и программистам? О том, что там дыры есть и сейчас, их много, и они там будут всегда! Ибо разработчики либо не хотят, либо не могут писать безопасный код в принципе.
И, лично я, выбирая между двумя приложениями, про одно из которых мне известно, что «там дыры есть, их много, и они там будут всегда», а про второе у меня такого рода информации нет — выберу второе. Потому, что хуже — точно не будет, но может быть значительно лучше!
Как же вы не понимаете, что отстутствие записей на этом сайте это не показатель безопасности приложения, скорее популярности.
Вот инофрмация прямо с этого сайта CVE, специально для таких как вы
PLEASE NOTE: The statistics provided should NOT be used to compare the overall security of products against one another. It is IMPORTANT to understand what the below comments mean when using the statistics, especially when using the statistics to compare the vulnerability aspects of different products.
Вот инофрмация прямо с этого сайта CVE, специально для таких как вы
PLEASE NOTE: The statistics provided should NOT be used to compare the overall security of products against one another. It is IMPORTANT to understand what the below comments mean when using the statistics, especially when using the statistics to compare the vulnerability aspects of different products.
Отсутствие — не показатель. Зато наличие записей — показатель.
И я не сравниваю безопасность приложений — я ищу приложения, в которых нет свежих известных дыр. Ибо при прочих равных я предпочту поставить такое приложение, нежели приложение, которое: a) содержит известные незакрытые дыры; b) имеет длинную историю уязвимостей, говорящую о том, что разработчики либо не умеют, либо не хотят писать безопасный код; c) имеет известные уязвимости за последний год, что уменьшает вероятность того, что разработчики осознали ошибки и серьёзно занялись безопасностью хоть в последнее время.
Ну а кроме того, Вы знаете другой способ поиска более безопасных приложений? Ну так просветите меня, я только спасибо скажу!
И я не сравниваю безопасность приложений — я ищу приложения, в которых нет свежих известных дыр. Ибо при прочих равных я предпочту поставить такое приложение, нежели приложение, которое: a) содержит известные незакрытые дыры; b) имеет длинную историю уязвимостей, говорящую о том, что разработчики либо не умеют, либо не хотят писать безопасный код; c) имеет известные уязвимости за последний год, что уменьшает вероятность того, что разработчики осознали ошибки и серьёзно занялись безопасностью хоть в последнее время.
Ну а кроме того, Вы знаете другой способ поиска более безопасных приложений? Ну так просветите меня, я только спасибо скажу!
Steer CMS — я не вижу, чтобы это хоть кто-то юзал. Я в топике просил указывать приложения, которыми пользуетесь лично Вы или Ваши знакомые. Mail list у Steer CMS дохлый, за последние пол года два письма. Гугл инсталляции не показывает. И т.д.
Что касается остальных — что это? Плагины к фреймворку? И давно это считается «приложением»? Вы можете показать сайты, на которые в качестве CMS поставили этот плагин и на нём работают?
Что касается остальных — что это? Плагины к фреймворку? И давно это считается «приложением»? Вы можете показать сайты, на которые в качестве CMS поставили этот плагин и на нём работают?
Steer CMS использовал лично я. И уверен в безопасности полученного на выходе приложения. Потому, что SQL injection не возможен в принципе. XSS тоже, ведь весь вывод екранируется автоматически, а если надо вывести из БД HTML, то для этого программисту надо специально запрашивать Raw версию данных. (Если программист уже сам там напартачил, то это явно не вина фреймворка)
Что касается остальных, так это готовые самостоятельные безопасные приложения, которые упакованы в плагин для удобства установки одной командой, знаете вот как .deb, только для Symfony
Что касается остальных, так это готовые самостоятельные безопасные приложения, которые упакованы в плагин для удобства установки одной командой, знаете вот как .deb, только для Symfony
Я не совсем понимаю, это плагины, или приложения. Если приложения, это значит что должна быть возможность их установки и использования обычными юзерами, без необходимости писать какой-либо код. И имеющейся «из коробки» функциональности должно более-менее хватать среднему юзеру.
На сайте написано: «This plugin allows you to add a simple Content Management System (CMS) to your symfony application...» — что подразумевает наличие у меня некоего «symfony application». Которого у меня нет… и где их раздают — я не знаю. :)
В общем, на взгляд неискушённого пользователя, а не программиста на symfony, это всё-таки плагины, а не приложения. И для этого пользователя они бесполезны. Хотя вполне возможно, что программист способен набросать тривиальное «symfony application» в несколько строк и получить в браузере что-то похожее на обычную CMS. Но это не делает плагин — продуктом.
На сайте написано: «This plugin allows you to add a simple Content Management System (CMS) to your symfony application...» — что подразумевает наличие у меня некоего «symfony application». Которого у меня нет… и где их раздают — я не знаю. :)
В общем, на взгляд неискушённого пользователя, а не программиста на symfony, это всё-таки плагины, а не приложения. И для этого пользователя они бесполезны. Хотя вполне возможно, что программист способен набросать тривиальное «symfony application» в несколько строк и получить в браузере что-то похожее на обычную CMS. Но это не делает плагин — продуктом.
Да, неискушенного пользователя ждет еще много сюрпризов, при создании сайта.
Ведь почти все веб-приложения предполагают наличие некоего Apache или другого веб сревера, а где их раздают он не знает. А еще базы данных страшные с какимито PHP, да еще и нужной версии.
Ведь почти все веб-приложения предполагают наличие некоего Apache или другого веб сревера, а где их раздают он не знает. А еще базы данных страшные с какимито PHP, да еще и нужной версии.
Нда, Вы действительно демагог. Вы знаете, давайте не будем останавливаться, действительно, какая разница — плагин, приложение… всё есмь набор байтов. Операционки, веб-сервера — все едино, с Вашей точки зрения, да? Тогда я могу Вам предложить отличную CMS: Windows. Ведь никто не может сказать, что Windows не позволяет «управлять контентом»?!
Вы забраковали приложение, потому что оно требует наличие фреймворка.
А как быть с Rails приложениями, а дотнетовскими?
А как быть с Rails приложениями, а дотнетовскими?
Я ничего не браковал. Я просто поинтересовался, как быть юзеру, который умеет устанавливать обычные веб-приложения вроде Wordpress или SMF — сможет он воспользоваться предложенными Вами плагинами так же, как обычными веб-приложениями, или нет? Если нет — значит это не веб-приложения, а плагины. К фреймворку. А фреймворки обычно преднозначаны для программистов, а не юзеров. Или Вы не чувствуете никакой разницы, между программистом и пользователем?
Насчёт рельсов не скажу, а дотнетовские приложения устанавливаются и работаю так же, как обычные. Для пользователя разница только в том, что при установке первого дотнетовского приложения от него потребуется сначала установить другое приложение — сам дотнет. Но одну программу устанавливать, или две — разница не принципиальная, если установка обоих сводится к скачать-запустить-next-next-next-finish. Я могу установить плагины к symfony так же просто, и сразу начать использовать свою новую CMS?
Насчёт рельсов не скажу, а дотнетовские приложения устанавливаются и работаю так же, как обычные. Для пользователя разница только в том, что при установке первого дотнетовского приложения от него потребуется сначала установить другое приложение — сам дотнет. Но одну программу устанавливать, или две — разница не принципиальная, если установка обоих сводится к скачать-запустить-next-next-next-finish. Я могу установить плагины к symfony так же просто, и сразу начать использовать свою новую CMS?
Для убунту это три комманды
cd path/to/www/dir
sudo apt-get install php5-symfony
symfony new
symfony plugin-install
Если не убунту
cd path/to/www/dir
wget www.symfony-project.org/get/sf_sandbox_1_0.tgz
tar -xvvzf sf_sandbox_1_0.tgz
cd sf_sandbox
./symfony plugin-install
cd path/to/www/dir
sudo apt-get install php5-symfony
symfony new
symfony plugin-install
Если не убунту
cd path/to/www/dir
wget www.symfony-project.org/get/sf_sandbox_1_0.tgz
tar -xvvzf sf_sandbox_1_0.tgz
cd sf_sandbox
./symfony plugin-install
Часть схлопнулась
symfony new (any_name)
symfony plugin-install (plugin)
symfony new (any_name)
symfony plugin-install (plugin)
Вы действительно думаете, что юзер будет искать на хабре эти инструкции, и пытаться их выполнить? Если это продукт, то должна быть веб-страница с документацией, описывающей процесс установки. То, что написано здесь меньше всего напоминает инструкции для юзера по установке обычного веб-приложения.
Ну да ладно, мне просто стало любопытно на это чудо посмотреть. В процессе выполнения Ваших инструкций:
/sf_sandbox/web/sfSimpleCMSPlugin/ тоже ничего не дал.
Полазив по каталогам (ни один юзер этого делать не будет!), я пришёл к выводу, что ссылка /sf_sandbox/web/ должна пустить меня в систему. По крайней мере там лежит index.php, и он даже запускается из консоли. Но, увы: 404. Ладно, попробуем /sf_sandbox/web/index.php. О! «Symfony Project Created»! Круто. Только где моя CMS? Я юзер, мне symfony, rails и .net нафиг не интересны, мне нужна моя CMS. Но давайте почитаем, что же мне, юзеру, предлагается делать дальше:
WTF? Где моя CMS?! :-))))
Ну да ладно, мне просто стало любопытно на это чудо посмотреть. В процессе выполнения Ваших инструкций:
powerman@web ~/www/sf_sandbox $ ./symfony new cms [Exception] A symfony project already exists in this directory. powerman@web ~/www/sf_sandbox $ ./symfony plugin-install sfSimpleCMSPlugin >> dir+ /home/powerman/www/sf_sandbox/plugins/.channels/.alias >> dir+ /home/powerman/www/sf_sandbox/p...hannel.pear.symfony-project.com >> plugin installing plugin "sfSimpleCMSPlugin" >> pear No releases available for package >> pear "pear.php.net/sfSimpleCMSPlugin" >> pear Cannot initialize 'channel://pear.php.net/sfSimpleCMSPlugin', >> pear invalid or missing package file >> pear Package "channel://pear.php.net/sfSimpleCMSPlugin" is not >> pear valid [Exception] install failedНу ладно, с пятой попытки я догадался указать plugin-install параметром полную url к плагину, и он поставился. Теоретически. Ибо как зайти в мою новую CMS и начать её использовать — не ясно. Как настроить url, по которой будет доступна CMS — не ясно. Попытки зайти на /, /sf_sandbox/, /sf_sandbox/symfony.php были безуспешны (последняя url выдала: You must launch symfony command line with the symfony script). Ладно, пошёл смотреть что вывелось в процессе установки плагина:
powerman@web ~/www/sf_sandbox $ ./symfony plugin-install http://plugins.symfony-project.org/get/sfSimpleCMSPlugin/sfSimpleCMSPlugin-0.7.3.tgz >> plugin installing plugin "http://plugi...in/sfSimpleCMSPlugin-0.7.3.tgz" >> pear downloading sfSimpleCMSPlugin-0.7.3.tgz ... >> pear Starting to download sfSimpleCMSPlugin-0.7.3.tgz (64,296 >> pear bytes) >> pear .. >> pear .. >> pear .. >> pear .. >> pear .. >> pear .. >> pear ....done: 64,296 bytes >> pear WARNING: channel "pear.symfony-project.com" has updated its >> pear protocols, use "channel-update pear.symfony-project.com" to >> pear update >> pear install ok: >> pear channel://pear.symfony-project.com/sfSimpleCMSPlugin-0.7.3 >> plugin installing web data for plugin >> link+ /home/powerman/www/sf_sandbox/web/sfSimpleCMSPluginК сожалению, заход на
Полазив по каталогам (ни один юзер этого делать не будет!), я пришёл к выводу, что ссылка /sf_sandbox/web/ должна пустить меня в систему. По крайней мере там лежит index.php, и он даже запускается из консоли. Но, увы: 404. Ладно, попробуем /sf_sandbox/web/index.php. О! «Symfony Project Created»! Круто. Только где моя CMS? Я юзер, мне symfony, rails и .net нафиг не интересны, мне нужна моя CMS. Но давайте почитаем, что же мне, юзеру, предлагается делать дальше:
What's next - Create your data model - Customize the layout of the generated templates - Learn more from the online documentation
WTF? Где моя CMS?! :-))))
Да ладно вам идиота строить по ссылке Instalation команда, которую предполагается скопировать и вставить.
А по ссылке README написано как ее собственно использовать и настраивать
А по ссылке README написано как ее собственно использовать и настраивать
Для Вас, похоже, юзер==идиот. К сожалению, довольно распространённая в среде программистов точка зрения. И Вы, похоже, не понимаете разницу между продуктом юзабельным для программиста и для юзера. Между уровнем поддержки и документации, которые нужны программисту и юзеру…
Я вот недавно ставил для клиента очередное веб-приложение. Выглядело это примерно так:
Заметьте, никаких консольных команд. Работа с архивами, ftp и веб-интерфейсом — всё в рамках способностей юзера. Все описанные мной операции по установке крупно написаны на сайте приложения, сложно не заметить.
При этом юзер понятия не имеет, на каком фреймворке (да и языке программирования, по большому счёту) написано это приложение — может и на symfony.
Ничего похожего в случае с Вашими плагинами я не наблюдаю. Да, я без проблем их поставлю, настрою, ещё и пропатчу по ходу дела и вышлю пару багрепортов. Но я — не юзер. И плагин — не приложение. Странно, что Вы это никак не поймёте.
Я вот недавно ставил для клиента очередное веб-приложение. Выглядело это примерно так:
- — скачать архив
- — распаковать
- — создать на сервере MySQL-юзера
- — прописать MySQL-юзера в config.php
- — залить весь каталог на сервер
- — выставить права 0777 на один каталог
- — зайти на /setup.php и нажать next-next-next
Заметьте, никаких консольных команд. Работа с архивами, ftp и веб-интерфейсом — всё в рамках способностей юзера. Все описанные мной операции по установке крупно написаны на сайте приложения, сложно не заметить.
При этом юзер понятия не имеет, на каком фреймворке (да и языке программирования, по большому счёту) написано это приложение — может и на symfony.
Ничего похожего в случае с Вашими плагинами я не наблюдаю. Да, я без проблем их поставлю, настрою, ещё и пропатчу по ходу дела и вышлю пару багрепортов. Но я — не юзер. И плагин — не приложение. Странно, что Вы это никак не поймёте.
2 года — как то многовато, учитывая скорость тех прогресса (и наличие ускорения) =)
есть такие вебсервисы — webasyst.ru (рус. версия) webasyst.net (англ. версия).
лично я юзал.
это не форум, не блог, не cms, не фреймворк… это просто набор онлайновых сервисов по типу 37 signals…
cve.mitre.org/cgi-bin/cvekey.cgi?keyword=webasyst — ничего не показывает.
лично я юзал.
это не форум, не блог, не cms, не фреймворк… это просто набор онлайновых сервисов по типу 37 signals…
cve.mitre.org/cgi-bin/cvekey.cgi?keyword=webasyst — ничего не показывает.
Да, сервис неплохой. В плане безопасности удалость найти только вот это. Но скрипты у них платные. А если брать платный софт, то там, я надеюсь, ситуация в плане безопасности значительно лучше. Если будет ещё несколько пожеланий, я просто сделаю отдельную табличку для платного софта.
Та дырка отмечена аж датой Oct 23 2006.
С тех движок очень сильно переписан. Но не могу сказать, устранена она или нет — это могут сказать только разработчики.
Кстати, существует версия Shop-Script FREE.
С тех движок очень сильно переписан. Но не могу сказать, устранена она или нет — это могут сказать только разработчики.
Кстати, существует версия Shop-Script FREE.
В Shop-Script FREE были серьезные уязвимости. Вот например критическая уязвимость, которую я нашел в прошлом году:
milw0rm.com/exploits/4419
Среди прочих веб-приложений под категорию относительно безопасных могу отнести Drupal, Joomla (естественно, не учитывая уязвимостей в компонентах) и последние версии Wordpress, хотя и там есть бреши…
milw0rm.com/exploits/4419
Среди прочих веб-приложений под категорию относительно безопасных могу отнести Drupal, Joomla (естественно, не учитывая уязвимостей в компонентах) и последние версии Wordpress, хотя и там есть бреши…
FREE — насколько я понял, это отдельная версия, не связанная с той которую они продают сейчас и предоставляют online. А мы выше обсуждали именно коммерческую версию.
Joomla?!?! Честно говоря, последний раз когда я смотрел уязвимости в Joomla я не приглядывался, какие из них в плагинах, а какие в ядре — их нереальное количество отбило желание вникать. Кроме того, в случае большого количества плагинов/компонентов, возникает простой вопрос: если некоторые плагины/компоненты широко распространены, и используются в большинстве типовых инсталляций, то с точки зрения безопасности дыры в этих плагинах то же самое, что дыры в ядре. А я не использую Joomla, и как определить какие плагины используются редко, а какие часто — не знаю. Кроме того, если клиенту поставить Joomla (или другую аналогичную систему, не важно), то он в любой момент может захотеть какие-то плагины… если их установка сделана просто, то он может сам их и поставить — не думая, что это может как-то повлиять на безопасность. В общем, я не знаю, как можно Joomla относить даже к очень очень относительно безопасным системам.
Что касается Drupal — загляните сюда. Или вся эта толпа дыр тоже в плагинах? А оно без плагинов вообще хоть что-то полезное юзеру делать умеет?
Joomla?!?! Честно говоря, последний раз когда я смотрел уязвимости в Joomla я не приглядывался, какие из них в плагинах, а какие в ядре — их нереальное количество отбило желание вникать. Кроме того, в случае большого количества плагинов/компонентов, возникает простой вопрос: если некоторые плагины/компоненты широко распространены, и используются в большинстве типовых инсталляций, то с точки зрения безопасности дыры в этих плагинах то же самое, что дыры в ядре. А я не использую Joomla, и как определить какие плагины используются редко, а какие часто — не знаю. Кроме того, если клиенту поставить Joomla (или другую аналогичную систему, не важно), то он в любой момент может захотеть какие-то плагины… если их установка сделана просто, то он может сам их и поставить — не думая, что это может как-то повлиять на безопасность. В общем, я не знаю, как можно Joomla относить даже к очень очень относительно безопасным системам.
Что касается Drupal — загляните сюда. Или вся эта толпа дыр тоже в плагинах? А оно без плагинов вообще хоть что-то полезное юзеру делать умеет?
>Честно говоря, последний раз когда я смотрел уязвимости в Joomla я не приглядывался, какие из них в плагинах, а какие в ядре —
> их нереальное количество отбило желание вникать.
по-моему все прекрасно видно с первого взгляда: все уязвимости за исключением нескольких в старых версиях были обнаружены в компонентах
>если некоторые плагины/компоненты широко распространены, и используются в большинстве типовых инсталляций, то с точки
> зрения безопасности дыры в этих плагинах то же самое, что дыры в ядре.
все, как раз наоборот: большую часть всех уязвимостей составляют дыры в малораспространенных плагинах, которые написаны любителями.
В целом, согласен с тем, что у Joomla большая проблема с компонентами, впрочем эта проблема затрагивает и многие популярные веб-приложения, в частности Wordpress
>Что касается Drupal — загляните сюда.
Да, действительно. В таком случае друпал то же не годится
> их нереальное количество отбило желание вникать.
по-моему все прекрасно видно с первого взгляда: все уязвимости за исключением нескольких в старых версиях были обнаружены в компонентах
>если некоторые плагины/компоненты широко распространены, и используются в большинстве типовых инсталляций, то с точки
> зрения безопасности дыры в этих плагинах то же самое, что дыры в ядре.
все, как раз наоборот: большую часть всех уязвимостей составляют дыры в малораспространенных плагинах, которые написаны любителями.
В целом, согласен с тем, что у Joomla большая проблема с компонентами, впрочем эта проблема затрагивает и многие популярные веб-приложения, в частности Wordpress
>Что касается Drupal — загляните сюда.
Да, действительно. В таком случае друпал то же не годится
А если брать платный софт, то там, я надеюсь, ситуация в плане безопасности значительно лучше.
далеко не факт. Платный не всегда означает безопасный
В принципе да, дыр у них действительно мало. Но вот здесь написано, что последний релиз затыкает не все дыры…
Насчет безопасности SMF совершенно не согласен, за последнее время найдено две серьезные уязвимости:
milw0rm.com/related.php?program=Simple+Machines+Forum
Кстати почему автор милворм не упомянул? Как правило, он является первоисточником большинства 0day уязвимостей в веб-приложениях
milw0rm.com/related.php?program=Simple+Machines+Forum
Кстати почему автор милворм не упомянул? Как правило, он является первоисточником большинства 0day уязвимостей в веб-приложениях
среди форумов могу выделить punbb/fluxbb и phpbb3
среди блогов — Serendipity и, как уже отмечал, последние версии WP
среди блогов — Serendipity и, как уже отмечал, последние версии WP
Serendipity — в последней версии вроде уязвимостей нет, но ей только пол года. И, судя по истории уязвимостей, думаю в ней дыры ещё найдут. Либо они выпустят дырявую следующую версию. Не знаю, может и стоит её добавить в таблицу, как лучшее из худшего.
WP — да, Вы уже отмечали. На милворме лежат эксплойты для 2.6.1, а она вышла 3 месяца назад. Возможно я ошибаюсь, но по-моему Вы считаете, что если в паблике нет эксплойтов для последней версии, то софт можно считать безопасным. Я так не думаю. Я считаю софт безопасным, если его пишут так, что уязвимости в нём — большая редкость. WP в эту категорию не попадает ну ни как.
punbb — аналогично, последняя дыра 3-х месячной давности. И снова обширная история уязвимостей.
fluxbb — а что это? это что-то на базе кода punbb?
phpBB — до 3.0.1 уязвимости были, а вышла она пол года назад. В общем, можно поступить как с Serendipity — добавить в таблицу, как лучшее из худшего. Но что-то меня на счёт phpBB мучают плохие предчувствия…
WP — да, Вы уже отмечали. На милворме лежат эксплойты для 2.6.1, а она вышла 3 месяца назад. Возможно я ошибаюсь, но по-моему Вы считаете, что если в паблике нет эксплойтов для последней версии, то софт можно считать безопасным. Я так не думаю. Я считаю софт безопасным, если его пишут так, что уязвимости в нём — большая редкость. WP в эту категорию не попадает ну ни как.
punbb — аналогично, последняя дыра 3-х месячной давности. И снова обширная история уязвимостей.
fluxbb — а что это? это что-то на базе кода punbb?
phpBB — до 3.0.1 уязвимости были, а вышла она пол года назад. В общем, можно поступить как с Serendipity — добавить в таблицу, как лучшее из худшего. Но что-то меня на счёт phpBB мучают плохие предчувствия…
>Serendipity — в последней версии вроде уязвимостей нет, но ей только пол года.
По-моему достаточный промежуток времени, чтобы считать веб-приложение стабильным
>И, судя по истории уязвимостей, думаю в ней дыры ещё найдут. Либо они выпустят дырявую следующую версию.
Пророческим даром я, к сожалению, не наделен, но крайне сомневаюсь, что будут найдены серьезные уязвимости, так как анализировал исходный код этого веб-приложения и имею представление о его степени безопасности. К тому же, почему разработчики вдруг выпустят дырявую версию, если до этого особых проблем с безопасностью не возникало? Многие веб-разработчики и специалисты по веб-безопасности доверяют Serendipity — например блог blog.php-security.org использует именно этот движок.
>WP — да, Вы уже отмечали. На милворме лежат эксплойты для 2.6.1, а она вышла 3 месяца назад.
Вы имеете представление насчет этих уязвимостей? Если нет, то я могу вас заверить: их степень опасности достаточно низкая, поэтому я лично до сих пор использую WP 2.6
>Вы считаете, что если в паблике нет эксплойтов для последней версии, то софт можно считать безопасным.
я считаю софт безопасным только на основе собственного анализа исходного кода
>Я считаю софт безопасным, если его пишут так, что уязвимости в нём — большая редкость. WP в эту категорию не попадает ну ни как.
Согласен, но ведь необходимо правильно оценивать реальную угрозу, которую представляет та или иная уязвимость. Что касается WP, то последняя значительная уязвимость датируется июнем 2007 года
>punbb — аналогично, последняя дыра 3-х месячной давности. И снова обширная история уязвимостей.
опять же, что за уязвимость? Пассивная XSS причем с ограничениями:
This bug cannot be used directly in PunBB 1.2, but can appear in mods using the page number set by PunBB
Обширная история уязвимостей? Не думаю. Лишь ненамного больше, чем в YaBB
>fluxbb — а что это? это что-то на базе кода punbb?
да, именно так, и в плане безопасности превосходит своего предшественника
>phpBB — до 3.0.1 уязвимости были, а вышла она пол года назад.
Ваше утверждение основано на этом?
Unspecified vulnerability in phpBB before 3.0.1 has unknown impact and attack vectors related to «urls gone through redirect() being used within login_box().»
phpBB3 не стоит путать со второй версией, с безопасностью там все в порядке
По-моему достаточный промежуток времени, чтобы считать веб-приложение стабильным
>И, судя по истории уязвимостей, думаю в ней дыры ещё найдут. Либо они выпустят дырявую следующую версию.
Пророческим даром я, к сожалению, не наделен, но крайне сомневаюсь, что будут найдены серьезные уязвимости, так как анализировал исходный код этого веб-приложения и имею представление о его степени безопасности. К тому же, почему разработчики вдруг выпустят дырявую версию, если до этого особых проблем с безопасностью не возникало? Многие веб-разработчики и специалисты по веб-безопасности доверяют Serendipity — например блог blog.php-security.org использует именно этот движок.
>WP — да, Вы уже отмечали. На милворме лежат эксплойты для 2.6.1, а она вышла 3 месяца назад.
Вы имеете представление насчет этих уязвимостей? Если нет, то я могу вас заверить: их степень опасности достаточно низкая, поэтому я лично до сих пор использую WP 2.6
>Вы считаете, что если в паблике нет эксплойтов для последней версии, то софт можно считать безопасным.
я считаю софт безопасным только на основе собственного анализа исходного кода
>Я считаю софт безопасным, если его пишут так, что уязвимости в нём — большая редкость. WP в эту категорию не попадает ну ни как.
Согласен, но ведь необходимо правильно оценивать реальную угрозу, которую представляет та или иная уязвимость. Что касается WP, то последняя значительная уязвимость датируется июнем 2007 года
>punbb — аналогично, последняя дыра 3-х месячной давности. И снова обширная история уязвимостей.
опять же, что за уязвимость? Пассивная XSS причем с ограничениями:
This bug cannot be used directly in PunBB 1.2, but can appear in mods using the page number set by PunBB
Обширная история уязвимостей? Не думаю. Лишь ненамного больше, чем в YaBB
>fluxbb — а что это? это что-то на базе кода punbb?
да, именно так, и в плане безопасности превосходит своего предшественника
>phpBB — до 3.0.1 уязвимости были, а вышла она пол года назад.
Ваше утверждение основано на этом?
Unspecified vulnerability in phpBB before 3.0.1 has unknown impact and attack vectors related to «urls gone through redirect() being used within login_box().»
phpBB3 не стоит путать со второй версией, с безопасностью там все в порядке
Serendipity добавил.
Если нет, то я могу вас заверить: их степень опасности достаточно низкая, поэтому я лично до сих пор использую WP 2.6Я не считаю смену пароля админа «низкой» степенью опасности. Ибо после смены пароля и входа под админом обычно можно наворотить достаточно дел.
опять же, что за уязвимость? Пассивная XSS причем с ограничениями:Ну, почему же… загляните на securityfocus, там три первые уязвимости. Плюс 9 месяцев назад взлом пароля, для которого на милворме эксплоит есть.
Обширная история уязвимостей? Не думаю. Лишь ненамного больше, чем в YaBBНе могу сказать, что я в восторге от YaBB (имел неосторожность заглянуть в код :)), но, тем не менее — в 2008 уязвимостей нет, в 2007 — две дыры, в 2006 — одна, в 2005 — две… и ни одного эксплойта на том же милворме. Пока это рекорд, если не считать fluxbb, к которому я пока не понял, как относиться.
да, именно так, и в плане безопасности превосходит своего предшественникаЧестно говоря, это настолько хорошо, что в это сложно поверить. От того, что проект форкнули, причём форк продолжают разрабатывать примерно те же самые люди, он не может «вдруг» стать намного безопаснее. Fluxbb ещё слишком молодой проект (пол года) с одной стороны, с другой код из него активно импортируют в punbb… Так что уровень безопасности у них, я думаю, примерно одинаковый. Надо просто определиться — если это новый проект — тогда о его безопасности ещё рано говорить, пусть пару лет сначала просуществует, и всё с его безопасностью станет понятно. А если это не новый проект, а развитие PunBB — тогда не стоит забывать про уязвимости PunBB обсуждая FluxBB. Иначе как-то странно получается, что переименование проекта слишком сильно влияет на его безопасность…
Ваше утверждение основано на этом?Угу. Ладно, предчувствия проигнорирую, предсказывать ничего не буду, добавляю в таблицу — лучших кандидатов всё-равно нет.
Кстати, раз уж у нас с Вами такой конструктивный диалог получается, может Вы и CMS безопасную на примете имеете, чтобы в табличке пустой раздел не оставлять? Или ещё какой-нить безопасный софт можете порекомендовать, не форум/блог/cms?
Я не считаю смену пароля админа «низкой» степенью опасности.Ибо после смены пароля и входа под админом обычно можно наворотить достаточно дел.
Вы бы все-таки открыли ту ссылку, которую я дал:
во-первых, смена пароля возможна лишь в том случае, когда в настройках WP разрешена регистрация пользователей (по умолчанию запрещено), что является редкостью среди используемых блогов,
во-вторых, атакующему удастся лишь поменять пароль, но не узнать его.
Среди прочих форумных дижков могу отметить IdealBB и Snitz Forum 2000 (оба написаны на ASP).
К кандидатам среди CMS на PHP можно отнести: papaya, typo3, ez publish
Еще можно создать категорию shop-движков: лидер, несомненно, — osCommerce
Я ссылку открывал. «лишь поменять пароль» — это означает, что он может поставить свой пароль и зайти в админку. А из админки дел можно натворить кучу, начиная с удаления контента и заканчивая протрояниванием статей, чтобы собрать урожай среди читателей блога. Если это «низкая» степень опасности, тогда что «высокая»? Или админка WP ничего такого делать не позволяет?
За софт спасибо, гляну и отвечу чуть позже, сейчас времени нет…
За софт спасибо, гляну и отвечу чуть позже, сейчас времени нет…
IdealBB — коммерческий.
typo3 — снова беда с расширениями. правда, надо отдать им должное, за безопасностью они по крайней мере наблюдают активно, количество и частота выхода их «TYPO3 Security Bulletin» поражает. ещё сильнее поражает то, что они наблюдают не только за ядром, но и за расширениями. если оно и дыряво, то ты хотя бы будешь об этом оперативно проинформирован. :) добавлять в список, наверное не стоит — во-первых по причине беды с расширениями, чисто психологически сложно удержаться от наворачивания функциональности, и следить за безопасностью каждого расширения проблематично; кроме того, полистав их security bulletin, нашёл пару XSS (два самых свежих) и вот это, более ранние за этот год не смотрел.
Snitz Forum 2000, papaya, ez publish, osCommerce — спасибо, добавляю.
P.S. Кстати, любопытный факт: у osCommerce на сайте написано, что у них 5 тысяч адд-онов для osCommerce. И при этом уязвимостей в этих аддонах практически нет — я буквально пару штук видел за последние годы…
typo3 — снова беда с расширениями. правда, надо отдать им должное, за безопасностью они по крайней мере наблюдают активно, количество и частота выхода их «TYPO3 Security Bulletin» поражает. ещё сильнее поражает то, что они наблюдают не только за ядром, но и за расширениями. если оно и дыряво, то ты хотя бы будешь об этом оперативно проинформирован. :) добавлять в список, наверное не стоит — во-первых по причине беды с расширениями, чисто психологически сложно удержаться от наворачивания функциональности, и следить за безопасностью каждого расширения проблематично; кроме того, полистав их security bulletin, нашёл пару XSS (два самых свежих) и вот это, более ранние за этот год не смотрел.
Snitz Forum 2000, papaya, ez publish, osCommerce — спасибо, добавляю.
P.S. Кстати, любопытный факт: у osCommerce на сайте написано, что у них 5 тысяч адд-онов для osCommerce. И при этом уязвимостей в этих аддонах практически нет — я буквально пару штук видел за последние годы…
«лишь поменять пароль» — это означает, что он может поставить свой пароль и зайти в админку.
«лишь поменять пароль» значит заменить прежний пароль администратора рандомным значением при восстановлении пароля. Свой пароль атакующий поставить не сможет — в этом заключается особенность уязвимости SQL Column Truncation в Wordpress. В самом эксплоите ясно сказано:
6. admin's password changed, but new password will be send to correct admin email ;/
Что касается второго эксплоита (Admin Takeover), то он способен лишь теоретически изменить пароль и также требует открытой регистрации, так как основан на первом эксплоите. Для его работы необходимы rainbow-таблицы, по моим подсчетам занимающие более 100 ГБ, которые необходимо генерировать php-скриптом. По своему опыту могу сказать — это займет не одну неделю. Вдобавок к этому необходимо быстро произвести поиск по rainbow-таблицам искомого сида, так как время keep-alive может не хватить. Плюс к этому у атакующего всего одна попытка, так как, однажды запросив восстановление пароля и получив «Exploit failed» по причине слишком длинного таймаута, атакующий уже не сможете предугадать код подтверждения, так как он всегда будет одним и тем же в базе данных до тех пор, пока его не подтвердят, а это значит, что сид случайного числа безвозвратно утерян. В общем, считаю этот эксплоит совершенно непрактичным.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Список безопасных веб-приложений