Инструменты для тестирования программного обеспечения против любых атак для программистов?

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

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

Например, я слышал о статическом / динамическом анализе кода и нечетком тестировании.

  • Атаки SQL-инъекций
  • Межсайтовый скриптинг
  • Атаки с переполнением буфера
  • Логические ошибки
  • Любые виды вредоносных программ
  • Скрытые каналы
  • ......

Спасибо

7 ответов

Решение

Я собираюсь сосредоточиться на безопасности веб-приложений здесь...

На самом деле вы хотите привыкнуть к ручному обходу веб-сайта / приложения и игре с различными параметрами и т. Д., Поэтому прокси-инструменты очень помогают (они позволяют вам захватывать формы и взаимодействовать с ними до того, как они достигнут сервера):

LiveHTTPHeaders - плагин FireFox.
Burp Proxy - на основе Java.

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

Черный ящик:

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

И есть много других коммерческих инструментов: WhiteHat Sentinel, HP Web Inspect и, вероятно, многие другие, которые я не могу вспомнить.

Белая коробка:

Многие академические исследования, которые я видел, связаны с инструментами статического анализа кода; Я не использовал их, потому что все они были сосредоточены только на PHP и имели некоторые ограничения.

Другие источники:

http://ha.ckers.org/ - отличный блог, с активным форумом, связанным с веб-приложением сек. OWASP - как уже упоминалось, здесь много полезных статей / руководств / руководств.

Если вы хотите больше узнать о том, как вручную атаковать сайты, то Damn Vulnerable Web App - хороший учебный проект. Под этим я подразумеваю, что это веб-приложение, которое написано так, что оно намеренно небезопасно, поэтому вы можете на законных основаниях проверить свои знания об уязвимостях безопасности веб-приложений.

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

  • гусеничный трактор
  • синтаксический анализатор
  • атакующий

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

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

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

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

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

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

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

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

Для хорошего прочтения по безопасности программного обеспечения и сложности проектирования безопасного программного обеспечения, проверьте Software Security: Building Security In, Gary McGraw ( ссылка на amazon)

На рынке есть множество сканеров безопасности веб-приложений

Посмотрите на этот список:

WASC - список сканеров безопасности веб-приложений и Netsparker Community Edition: бесплатная версия Netsparker.

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

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

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

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

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

Только вы (и нападающие).

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

Другие вопросы по тегам