Инструменты для тестирования программного обеспечения против каких-либо нападений для программистов? [закрытый]

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

• OWASP Top 10 за 2010 год
• OWASP Guide for Secure Web Applications
• OWASP Testing Guide v3

Есть 2 типа программных дефектов, которые могут вызвать проблемы с безопасностью: ошибки реализации и недостатки конструкции.

Ошибки реализации обычно появляются в определенной области кода, их относительно легко обнаружить и (обычно) не слишком сложно исправить. Вы можете обнаружить (большинство) из них с помощью автоматизированных инструментов, выполняющих статический анализ кода (таких как Fortify или Ounce), хотя эти инструменты дороги. С учетом сказанного, вы все равно должны помнить, что не существует «серебряных пуль», и вы не можете слепо полагаться только на результаты работы инструмента без какого-либо ручного обзора кода, чтобы подтвердить / понять реальный риск, стоящий за проблемами, о которых сообщает инструмент.

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

Поэтому я рекомендую проверить ваш код на наличие ошибок реализации, которые могут повлиять на безопасность (проверка кода с использованием автоматических инструментов, таких как Fortify / Ounce + ручная проверка результатов инструмента) и проверить свой дизайн на наличие недостатков безопасности (для этого нет инструментов должно быть сделано кем-то, кто знает о безопасности).

Чтобы получить хорошее представление о безопасности программного обеспечения и сложности, стоящей за разработкой безопасного программного обеспечения, см. «Безопасность программного обеспечения: обеспечение безопасности» Гэри МакГроу ( amazon link )

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

Важно идентифицировать в проекте функции, связанные с безопасностью, и вручную проверять их. Tamperdata очень полезны для ручного аудита и разработки эксплойтов, поскольку вы можете создавать собственные HTTP-запросы. Хороший пример ручного аудита для PHP: используют ли они mysql_real_escape_string ($ var) или htmlspecialchars ($ var, ENT_QUOTES) , чтобы остановить внедрение sql? (ENT_QUOTES не останавливает обратную косую черту, что так же опасно, как кавычки для mysql, mssql - другая история.) Функции безопасности также являются местом для возникновения «логических ошибок», и никакой инструмент не сможет их обнаружить. , это требует ручного аудита.

Если вы проводите тестирование веб-приложений, то Acunetix - лучший инструмент тестирования, который вы можете использовать. Wapiti - очень хорошая альтернатива с открытым исходным кодом. Хотя любой инструмент можно использовать неправильно. Прежде чем выполнять тест веб-приложения, убедитесь, что отчет об ошибках включен, а также убедитесь, что вы не подавляете ошибки sql, например, с помощью команды try / catch.

Если вы выполняете автоматический статический анализ кода на наличие уязвимостей, таких как переполнение буфера, то Coverity - лучший инструмент, который вы можете использовать (Fortify почти идентичен Coverity). Coverity стоит десятки тысяч долларов, но им пользуются такие громкие имена, как Министерство внутренней безопасности. RATS - альтернатива с открытым исходным кодом, хотя Coverity - гораздо более сложный инструмент. Оба этих инструмента будут давать много ложных срабатываний и ложноотрицательных результатов. RATS ищет опасные вызовы функций, но не видит, безопасно ли это. Таким образом, RATS будет сообщать о каждом вызове strcpy () strcat () sprintf (), но это может быть безопасно, если, например, вы просто копируете статический текст. Это означает, что вам придется копать, хотя и много чуши, но если вы проводите экспертную оценку, то RATS очень помогает, сужая ручной поиск. Если вы пытаетесь найти хоть одну уязвимость, которую можно использовать, в большой кодовой базе, такой как Linux, то Rats не сильно поможет.

Я использовал Coverity, и их отдел продаж утверждает, что он «обнаружит **** ВСЕ **** уязвимости в вашем коде». Но я могу сказать вам из первых рук, что я обнаружил переполнение буфера на основе ванильного стека с персиком , которое Coverity не обнаружил. (RATS, однако, поднял эти проблемы, а также более 1000 вызовов других функций, которые были безопасными ...) Если вам нужно безопасное приложение или вы хотите найти уязвимое переполнение буфера, то Peach - это инструмент платформы, который вы можете использовать для создания инструменты, которые вам нужны.

Если вы ищете более экзотические проблемы с повреждением памяти, такие как висячие указатели, то Valgrind поможет.

То, о чем вы не упомянули, но что я считаю важным: обзоры кода.

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

Я считаю, что во многих случаях можно проводить ручные обзоры кода без специальных инструментов. Просто сядьте вместе за один компьютер или даже распечатайте код и сделайте обзор на бумажной копии. Но раз уж вы спросили об инструментах, то инструментом, который может помочь в ручном просмотре кода, является Rietveld. Я сам им не пользовался, но он основан на тех же идеях, которые используются внутри Google (и написан тем же парнем, который также является автором Python).

Инструмент не знает, является ли ваш код небезопасным.

Это знаете только вы (и злоумышленники).

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