Подтвердить что ты не робот

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

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

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

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

  • Атаки SQL-инъекций
  • Скрипты для кросс-сайтов
  • Атаки с использованием Bufferoverflow
  • Логические ошибки
  • Любые виды Malwares
  • Скрытые каналы
  • ......

спасибо

4b9b3361

Ответ 1

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

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

LiveHTTPHeaders - плагин FireFox.

Burp Proxy - на основе Java.

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

Черный ящик:

WebSecurify - не использовал его, но был создан известным парнем безопасности веб-приложений.

Skipfish - Google опубликовал это недавно, поэтому, вероятно, стоит посмотреть.

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

Белый ящик:

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

Другие ресурсы:

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

Ответ 4

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

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

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

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

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

Ответ 5

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

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

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

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

Ответ 7

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

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

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