>>> TYPO3 наоборот один из примеров наплевательского отношения к безопасности
>> А это был один из примеров наплевательского отношения к аргументации и передёргивания.
> Я привел ссылку из которой ясно вырисовываются такие казусы: Именно что казусы -- Вы хоть обратили внимание на строчки вида "Successful exploitation of this vulnerability requires"?
> http://secunia.com/advisories/45557/
Здесь самое неприятное -- infoleak в css_styled_content; с browse_links wizard не сталкивался, остальное требует либо доступа к бэкенду (т.е. заведомо повышенный уровень привилегий и журналирования), либо экзотических случаев вроде the victim uses Internet Explorer 6 (либо некрасиво, но малоопасно).
> http://secunia.com/advisories/35770/
Вот здесь действительно был sql injection, причём опять же только при условии доступа к бэкенду. Поэтому самым неприятным IMHO тут является не он, а пункт про click enlarge (если оно используется). Остальное опять же требует доступа к бэкенду либо не столь существенно (хотя всё равно хорошо, что нашли и заткнули).
> Если для вас ежегодное
Можно подробнее? По моим данным, Вы только что соврали.
> обнаружение SQL injection не аргумент....
Это аргумент, но не того веса, который Вы ему пытаетесь приписать. Поскольку я по случаю всё-таки _читаю_ эти самые анонсы, причём с 2004 года, и _практически_ знаю, сколько раз за эти годы приходилось подпрыгивать и что-то оперативно трогать в TYPO3.
> Это и есть наплевательское отношение к безопасности, когда дыры латают по факту
> их обнаружения, а до этого никто даже не задумывается о потенциальных проблемах.
Вы только что плюнули в лицо OpenBSD'шникам, которые свои две ремотных дырки заткнули по факту обнаружения (поскольку вычитка практикуется в обоих проектах).
А теперь посмотрим на реальное состояние дел.
* http://typo3.org/teams/security/
sec team есть и работает, в т.ч. над вычиткой, исправлением и рекомендациями
* http://news.typo3.org/news/article/important-security-bullet.../
для критической дырки 2009 года выпустили обновления для 4.x и патчи для 3.x (вплоть до 3.3 образца 2002, что ли), которые заранее анонсировали с тем, чтобы было возможно спланировать работы
* http://www.slideshare.net/hepi/developing-extensions-with-se...
работа с разработчиками расширений также идёт (помимо слоя работы с БД, который в т.ч. помогает от sql injection'ов)
* http://joind.in/talk/view/3546
...и не только с разработчиками, а и с развёртывающими/сопровождающими сисадминами/вебмастерами тоже.
Можно поинтересоваться политикой безопасности по Вашим проектам, рекомендациями разработчикам и администраторам? Как Вы работаете с информацией об уязвимостях? Как организовывается выпуск исправлений и их анонсирование? Что предпринято архитектурно и организационно для минимизации возможности выпуска кода с дырками? Если сами ничего такого не делаете, а докапываетесь к поставщику -- хорошо, тогда приведите свой эталон, я постараюсь донести до тайпотришников предложения по существу.
Из всего, что Вы высказали, уместна претензия по plaintext password storage (хотя и тоже преувеличена); в остальном занимаетесь выдуванием слонов из мухи. Обиженный джумлятник, что ли? :) Ну так там всё настолько грустно в этом разрезе, что сравнивать просто нечего.
Вариант для распечатки
(ok) on 27-Окт-11, 20:26 
