Уж сколько раз твердили миру… что SDLC придуман не просто так и при написании ПО надо учитывать не только классические принципы программирования, но и учитывать вопросы безопасности. Причем с самого начала проекта, чтобы не латать дыры постфактум. На днях компания Veracode опубликовала свой очередной, уже третий отчет «The State of Software Security Report«, описывающий состояние текущего уровня защиты ПО.
Veracode проанализировала 4835 приложений (в прошлом отчете их было 2922) на разных языках программирования — Java, C/C++, .NET, ColdFusion и PHP; разного типа (компоненты, библиотеки, web и иные приложения) и разной формы «собственности» — внутренняя разработка, open source, аутсорсинговое ПО, коммерческое и т.д.
Краткие результаты таковы:
- 8 из 10 Web-приложений провалили «тест» OWASP Top 10
- более половины всех приложений имеют просто «никакой» уровень качества защиты ПО
- CSS остается одной из распространенных проблем
- большинство разработчиков остро нуждается в тренингах по вопросам ИБ
- лучше всех защищены финансовые организации
- даже разработчики средств защиты не следуют правилам безопасного программирования
- для анализа ПО необходимо использовать и статический и динамический анализ (хотя первый и находит на порядок больше проблем).
Можно ли где-нибудь протестировать произвольно взятый exe файл по указанной методике или другим методикам (OWASP и др.) в области безопасности?
С высокой достоверностью — нет. Хороший результат получить тестированием конечного продукта нельзя. Эффективно только применение мер на этапах проектирования и кодирования. Остальное малоэффективно.
Если практически — можно порыться в ехе-шнике найти ляпы созданные на этапе кодирования а вот заложенные в архитектуру… Это нужно делать на другом уровне абстракции или следить за выполнением в процессе работы — такие методы уже есть…
Тогда как же товарищи из Veracode протестировали продукты, без исходных кодов?
Во-первых, Veracode тестировал во многом исходный код. Они же за это деньги берут 😉
Что же касается исходных кодов, то существуют методы анализа и без оных. Тот же динамический анализ. Не говоря уже о дизассемблировании и последующем анализе.
Ну вот попробуйте одну из моих разработок… публичный вариант… Но могу разложить программу по полочкам прямо в процессе работы… запустите например ворд )) http://goo.gl/g24Fs
Спасибо, Евгений!
А это не тоже самое, что контрольная точка в среде разработки?
Почти тоже… Только эта утилитка как бы съедает программу и может ее контролировать с точностью до 1 машинной команды, можно код изменять прямо в процессе работы, смотреть что он делает, ограничивать и т.п. В этой версии используется для отлова точек и выдает немного доп. инфы.
Compuware Driver Studio, и все дела 😉
Этот комментарий был удален автором.
Тестирование без изходных кодов:
1) Фаззинг
— генерируем данные по известному формату.
— по набору семплов создаем тест данные (мутация)
Циклический запуск ПО с "генерированными" данными. Анализ поведения (падения).
2) Статический анализ
— анализ вызова опасных функций
— анализ дизасм кода, вывление слабостей (аллок, фри, фри ветка. например или аллок, копируем указатель, фри, используем указатель… )
Комбинации указанных методов, да ещё много как можно =)