LINUX.ORG.RU
ФорумTalks

Действительно открытые веб-фреймворки настолько небезопасны?


0

1

Набрел тут на пиаристую статейку: http://ocpsoft.org/opensource/secure-your-applications-url-based-attacks-are-... (можно не читать)

Статейка рассказывает про ужасные и тупые баги:

http://struts.apache.org/2.2.1/docs/s2-005.html

http://www.springsource.com/security/cve-2011-2730

От себя можно добавить аналогичную

Небезопасные параметры по умолчанию в проектах на базе Rails

Все вышеуказанное демонстрирует две вещи:

- использование сторонних библиотек небезопасно

- налицо проблема модели разработки открытых систем - квалификация разработчиков никак не регулируется, что позволяет людям в принципе не задумывающимся о вопросах безопасности (а вопросы ведь тривиальные!) разрабатывать базовое ПО которое потом используют практически все в своих проектах.

В итоге выходит, если у вас задача сделать сколь нибудь безопасную систему либо вам придется заниматься постоянным аудитом кода новых версий сторонних библиотек либо писать все с нуля самим, или использовать ПО вендоров несущих какую либо ответственность за свои ошибки (никаких AS IS, NO WARRANTY?).

Белка, у тебя такое самомнение большое, типа все лохи, а ты в своем софте багов не делаешь никогда? Я тя умоляю. Раз ты такой умный, что же Путин тебе еще ботинки не чистит?

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

shimon ★★★★★
()

Ну во-первых использование AS IS и NO WARRANTY - это эмулированное ССЗБ.

Пункт 2: Даже использование «Ответственного софта» и оплаченной 24/7 техподдержке, не факт, что когда найдут очередную дыру, техподдержка не будет занята более кошелистыми заказчиками(клиентами)

А то, что это никак ни контролируется, я думаю, тебе известно давно. Поэтому выбирай для себя золотую середину.

visual ★★★
()

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

Tark ★★
()

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

Правильно.

спользовать ПО вендоров несущих какую либо ответственность за свои ошибки

Неправильно. Шанс ошибиться у копирастов такой же. А свободный код мы хотя бы можем проверять. А если мы не доверяем даже своей конторе, то что мы вообще делаем на рынке?

mopsene ★★★
()

Дада, Security through obscurity рулит.

kranky ★★★★★
()

вендоров несущих какую либо ответственность за свои ошибки (никаких AS IS, NO WARRANTY?).

А такие вендоры существуют? Чтобы софт был с гарантией качества и ответственностью вендора за фэйлы.

kim-roader ★★
()

А разве есть хоть один разработчик проприетарщины который берет на себя ответственность в случае взлома его софта?

winddos ★★★
()

Безопасность опес-сорс софта коррелирует с размером квалифицированной части аудитории, которая его использует, поделенным на объем этого софта.

soomrack ★★★★★
()

Есть примеры более-менее «взрослого» софта, который подпадает под правило

никаких AS IS, NO WARRANTY

?

trex6 ★★★★★
()

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

Ну так что тогда означают слова «обновления безопасности»?

note173 ★★★★★
()

использовать ПО вендоров несущих какую либо ответственность за свои ошибки

таких вендоров нет. Вообще. Почитай любую eula.

- использование сторонних библиотек небезопасно

использование ПО вообще не безопасно.

квалификация разработчиков никак не регулируется

ЭЭэ, ты видел кто работает в софтовых конторах? У них же дедлайны, у них же издержки... Ну ты понел.

аудитом кода новых версий сторонних библиотек

поставь себе рэдхэт и наслаждайся древнимии и безопасными версиями библиотек. С поддержкой эдак лет 7-10.

true_admin ★★★★★
()

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

fjfalcon ★★★
()

- использование сторонних библиотек небезопасно

Сейчас ситуация такова, что безопасность по-умолчанию не является параметром, которым занимаются. Исключение - продукты, авторы которых явно декларируют свою озабоченность проблемами безопасности, например vsftpd или postfix. Т.е. можно с некоторой долей вероятности надеяться, что человек, принимающий патчи, осмысленно подумает: «а не будет ли тут переполнения и можно ли доверять этим данным»?

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

- налицо проблема модели разработки открытых систем -
квалификация разработчиков никак не регулируется, что позволяет
людям в принципе не задумывающимся о вопросах безопасности (а
вопросы ведь тривиальные!) разрабатывать базовое ПО которое
потом используют практически все в своих проектах.

Открытые или закрытые системы тут не при чём. До тех пор, пока явно не ставится цель - написать безопасную систему - и определить критерии определения этой безопасности, система безопасной не будет. Вот например я захотел написать аналог SMB сервера и начал пилить самбу. Вопрос - я думаю о безопасности или о том, как отреверсить протокол? 99% проектов озабочены функционалом и у нихе тупо не хватает ресурсов следить ещё и за безопасностью, особенно если ты говоришь про таких монстрова как фреймворки, которые ещё включат в себя пачку стороннего софта как правило. Также надо различать маркетинговый буллшит о безопасности от авторов коммерческого софта - это поле для такого цирка, что многим и не снилось.

В итоге выходит, если у вас задача сделать сколь нибудь
безопасную систему либо вам придется заниматься постоянным
аудитом кода новых версий сторонних библиотек либо писать все с
нуля самим, или использовать ПО вендоров несущих какую либо
ответственность за свои ошибки (никаких AS IS, NO WARRANTY?).

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

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

deadman ★★
()

налицо проблема модели разработки открытых систем - квалификация разработчиков никак не регулируется

А кто контролирует квалификацию разработчиков закрытых систем?

В открытых проектах по крайней мере действует принцип:

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

(Эрик Реймонд)

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

В открытых проектах по крайней мере действует принцип:

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

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

12309 до сих пор не могут зафиксить.

Вообще-то это был ряд багов и их всех уже давно зафиксили. Последние намеки пропали в ведре 3.3 И вообще, 12309 - детектор неудачников.

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

А разве есть хоть один разработчик проприетарщины который берет на себя ответственность в случае взлома его софта?

Была год-два назад у кого-то (вроде из российских властей) инициатива ввести ответственность за критические баги. Так на лоре такой вой поднялся, сразу видно кто пишет проприетарный говнокод.

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

Сделай fsck -fc на любую файлуху. Понаблюдай за IOW в top/sysstat/iostat. Мой детектор уже видит в тебе лузера и неотягощенного мыслью индивида.

GateKeeper ★★
()

использовать ПО вендоров несущих какую либо ответственность за свои ошибки (никаких AS IS, NO WARRANTY?)

Такое вообще бывает?? Чем и как эти вендоры отвечают за свои ошибки? Сколько это ПО стоит?

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

Была год-два назад у кого-то (вроде из российских властей) инициатива ввести ответственность за критические баги. Так на лоре такой вой поднялся, сразу видно кто пишет проприетарный говнокод.

Ты снова выходишь на связь, академическая сопля? Давай, заботань кнута, драконову книгу и sicp, что-нибудь из бредней буча или gof, парочку язычков по-популярнее, и приди к нам в ИНДУСтрию — покажи, как надо писать программы без критических багов.

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

СПЕРДОБЕЙСЯ, ага

Да тут ничего сложного нет же. За исключением последнего пункта: «без критических багов». Вот я и прошу тебя: научи нас, как так писать большие и сложные программы, чтобы делать это с приемлемой скоростью и приемлимыми трудозатратами, но притом без ошибок?

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

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

man система менеджмента качества

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

Не прокатывает. Создай любой ехт раздел гиг на 20-30. Разрешается (даже настоятельно рекомендуется) использовать ядро 3.3

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

ISO 9001 это самый базовый уровень, и очень либеральный кстати. Надо умудрится, чтоб сертификат не получить. Вот GMP повышает трудозатраты почти в два раза, но без него на западные рынки (а теперь и российский, man ВТО) не пустят.

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

Но позволяет минимизировать. А как показывает практика самый эффективный способ борьбы с багами - увольнение тех, кто их допускает.

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

Но позволяет минимизировать.

В каком это смысле - «минимизировать»?

А как показывает практика самый эффективный способ борьбы с багами - увольнение тех, кто их допускает.

Бгг. Ты практики в глаза не видел. Ни управленческой, ни программистской.

Manhunt ★★★★★
()

или использовать ПО вендоров несущих какую либо ответственность за свои ошибки (никаких AS IS, NO WARRANTY?)

А такие разве есть? О_о

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

В каком это смысле - «минимизировать»?

Тебе и значение букв алфавита рассказывать? Даже в таком простом занятии как раскатка огурцов по банкам есть возможность получить очень веселые эффекты. Однако ряд простых мер позволяет свести эту вероятность практически до нуля, при тог что банка с огурцами гораздо менее детерминированная система чем любой программный код.

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

Тебе и значение букв алфавита рассказывать?

Теоретически достижимый минимум в данном случае - ноль багов. Отсюда вопрос: что предложенные тобой меры на самом деле «минимизируют», если они не обеспечивают достижения минимума?

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

Не совсем понятно, как распространить твой опыт по закатке огурцов и мытью сортиров на программирование? Можешь привести в качестве примера хотя бы 10 больших и сложных программ, в которых не было найдено критических багов после официального релиза?

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

Теоретически достижимый минимум в данном случае - ноль багов.

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

Не совсем понятно, как распространить твой опыт по закатке огурцов и мытью сортиров на программирование?

man отраслевые стандарты, они есть везде, и в электронике, и в аэрокосмической отрасли, и в пищевой промышленности. А вот в программировании их нет.

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

Пускали. Как раз с 9001. Для того он, собственно, и получался. Потом еще антимонополька (причем по антидемпингу) европейская понаезжала, но это другая история.

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

Тебя как Manhunt'а тоже в детстве роняли? Зачем мне возится с переразбивкой диска только ради того чтоб проверить твой прогон?

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

Рависит от рынка. Серия 9001 это лишь базовый стандарт, доказывающий что начальник является начальником, сисадмин - сисадмином, а говядина поставляемая на колбасный завод - говядиной. Кроме того, есть целые пачки отраслевых стандартов, GMP например для лекарственных средств.

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

Тебе тесткейс дали. Давай пруфы уже, что бага нет (или исправили). Будь уже мужиком.

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

создал. Винт - WD Green на 1,5 ТБ, ядро 2.6.38, раздел на LVM. Пустил fsck с указанными ключами. УМВР.

P.S. 12309 видел 1 раз - проблема была в помирающем IDE-винте

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

Есть вероятность что парашют не раскроется.

Причем ответственность нераскрытие несет тот, кто прыгает. С производителя парашюта - взятки гладки. AS IS, NO WARRANTY.

Так вот, ты на этом основании предлагаешь прыгать без парашютов?

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

man отраслевые стандарты, они есть везде, и в электронике, и в аэрокосмической отрасли, и в пищевой промышленности. А вот в программировании их нет.

И это неспроста. Да, есть куча разных практик и подходов. Вот, например: http://www.ixbt.com/soft/microsoft-security-development-lifecycle.shtml Практики есть, достаточно хорошего выхлопа - нет.

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

Причем ответственность нераскрытие несет тот, кто прыгает. С производителя парашюта - взятки гладки. AS IS, NO WARRANTY.

Вообще-то лютое бешенное 4.2

И это неспроста.

Да, неспроста. Очень хорошо характеризует полный бардак в отрасли.

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

Причем ответственность нераскрытие несет тот, кто прыгает. С производителя парашюта - взятки гладки. AS IS, NO WARRANTY.

Вообще-то лютое бешенное 4.2

Пруф?

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

Очень хорошо характеризует полный бардак в отрасли.

Ну так приди в отрасль, и покажи им всем, как надо делать все по уму :D

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

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

Теоретически достижимый минимум в данном случае - ноль багов

Этот минимум — теоретически недостижимый предел. В случае решения недопоставленной задачи при помощи неавтоматизируемых средств (программистов) нет никаких аргументированно уменьшающих число ошибок средств. Есть лишь наборы практик, которые «вроде бы работают», вроде ревью кода и полного покрытия тестами (в которых тоже могут быть ошибки). Именно об этом говорил DNA_Seq когда писал про

ряд простых мер позволяет свести эту вероятность практически до нуля

Отсюда на вопрос

что предложенные тобой меры на самом деле «минимизируют», если они не обеспечивают достижения минимума?

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

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

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

Так ты готов после внедрения практик нести реальную ответственность своими яйцами за критически баги, или нет? :D

Есть лишь наборы практик, которые «вроде бы работают», вроде ревью кода и полного покрытия тестами (в которых тоже могут быть ошибки).

У нас практикуется code review, динамический и статический анализ кодов специальными инструментами, юнит-тестирование, автотесты, имеется обособленный от собственно программистов отдел контроля качества ... однако это всё не позволяет вытянуть программу на тот уровень безбажности, о котором брызжет слюнями DNA_Seq.

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