Инструменты тестирования на возможность проникновения [закрываются]
Исключение нулевого указателя генерируется, когда приложение пытается использовать null в случае, когда требуется объект. К ним относятся:
- Вызов метода экземпляра объекта
null. - Доступ или изменение поля объекта
null. - Принимая длину
null, как если бы это был массив. - Доступ или изменение слотов
null, как если бы это был массив. - Бросок
nullкак будто это было значение Throwable.
Приложения должны бросать экземпляры этого класса, чтобы указать на другие незаконные использования объекта null.
Ссылка: http://docs.oracle.com/javase/8/docs/api/java/lang/NullPointerException.html
11 ответов
Существует пара различных направлений, можно пойти с автоматизированными инструментами тестирования для веб-приложений.
Первый, существуют коммерческие веб-сканеры , которых HP WebInspect и Rational AppScan самые популярные два. Это "единые", инструменты "выпустил-забыл", которые Вы загружаете и устанавливаете на внутреннем рабочем столе Windows и затем даете URL пауку Ваш сайт, сканирование для известных уязвимостей (т.е., вещи, которые поразили Bugtraq), и датчик для сценариев перекрестного сайта и уязвимостей Внедрения SQL.
1132-секундный, существуют инструменты сканирования исходного кода , которых Coverity и Fortify являются, вероятно, самыми известными двумя. Это инструменты, которые Вы устанавливаете на рабочем столе разработчика, чтобы обработать Ваш Java или исходный код C# и искать известные шаблоны небезопасного кода, как плохой контроль ввода.
Наконец, существуют инструменты теста на проникновение . Безусловно самый популярный инструмент тестирования на возможность проникновения веб-приложения среди специалистов по безопасности является Комплектом Отрыжки, который можно найти в http://www.portswigger.net/proxy . Другие включают Прокси Скачка и OWASP WebScarab. Снова, Вы установите это на внутреннем рабочем столе Windows. Это будет работать как Прокси HTTP, и Вы укажете на свой браузер на него. Вы используете свои приложения, как обычный пользователь был бы, в то время как это записывает Ваши действия. Можно тогда вернуться к каждой отдельной странице или действию HTTP и зондировать его для проблем безопасности.
В сложной среде, и особенно если Вы рассматриваете что-нибудь сделай сам, , я настоятельно рекомендую инструменты тестирования на возможность проникновения . Вот то, почему:
Коммерческие веб-сканеры обеспечивают большую "ширину", наряду с превосходным созданием отчетов. Однако:
-
Они имеют тенденцию пропускать вещи, потому что каждое приложение отличается.
-
Они являются дорогими (WebInspect запускается в 10-х тысяч).
-
Вы платите за материал, в котором Вы не нуждаетесь (как базы данных известного плохого CGIs с 90-х).
-
Их трудно настроить.
-
Они могут привести к шумным результатам.
сканеры Исходного кода более полны, чем веб-сканеры. Однако:
-
Они являются еще более дорогими, чем веб-сканеры.
-
Они требуют, чтобы исходный код работал.
-
, Чтобы быть эффективными, они часто требуют, чтобы Вы аннотировали свой исходный код (например, выбрали входные трассы).
-
у Них есть тенденция произвести ложные положительные стороны.
И коммерческие сканеры и сканеры исходного кода имеют дурную привычку к становлению shelfware. Хуже, даже если они работают, их стоимость сопоставима с получением 1 или 2 целых приложений, контролируемых консультированием; при доверии консультантам Вы, как гарантируют, станете лучше, следует из них, чем от инструментов.
инструменты Тестирования на возможность проникновения имеют оборотные стороны также:
-
Их намного более трудно использовать, чем коммерческие сканеры "выпустил-забыл".
-
Они принимают некоторые экспертные знания в уязвимостях веб-приложения---, необходимо знать то, что Вы ищете.
-
Они производят минимальное формальное создание отчетов.
, С другой стороны:
-
Они очень, намного более дешевый---лучшая из партии, Комплекта Отрыжки, стоит только 99EU и имеет бесплатную версию.
-
Их легко настроить и добавить к рабочему процессу тестирования.
-
Они намного лучше в помощи Вам "узнать" Ваши приложения с внутренней части.
Вот что-то, что Вы сделали бы с перьевым инструментом тестирования для основного веб-приложения:
-
Входят в приложение через прокси
-
, Создают "список совпадений" главных функциональных областей приложения и осуществляют каждого однажды.
-
Использование инструмент "паука" в Вашем перьевом тестовом приложении для нахождения всех страниц и действий и обработчиков в приложении.
-
Для каждой динамической страницы и каждой HTML-формы паук раскрывает, используйте "fuzzer" инструмент (Отрыжка называет его "злоумышленником") осуществить каждый параметр с недопустимыми исходными данными. Большинство fuzzers идет со строками базового теста, которые включают:
-
метасимволы SQL
-
Escape HTML/Javascript и метасимволы
-
Интернационализировавшие варианты их для уклонения от входных фильтров
-
Известные имена полей формы по умолчанию и значения
-
Известные имена каталогов, имена файлов и глаголы обработчика
-
-
Проводят несколько часов, фильтруя получающиеся ошибки (типичный пух, выполненный для одной формы, мог бы генерировать 1000 из них), поиск подозрительных ответов.
Это - трудоемкий подход "без операционной системы". Но когда Ваша компания владеет реальными приложениями, подход без операционной системы окупается, потому что можно использовать его для создания комплектов регрессионного теста, которые будут работать как часы в каждом dev цикле для каждого приложения. Это - победа для набора причин:
-
Ваше тестирование безопасности займет предсказуемое количество времени и ресурсы на приложение, которое позволяет Вам бюджету и медицинской сортировке.
-
Ваша команда получит максимально точные и полные результаты, так как Ваше тестирование будет настроенным на Ваши приложения.
-
Это собирается стоить меньше, чем коммерческие сканеры и меньше, чем консультанты.
, Конечно, если Вы идете этим путем, Вы в основном превращаете себя в консультант по безопасности для Вашей компании. Я не думаю, что это - плохая вещь; если Вы не хотите тех экспертных знаний, WebInspect или Укрепляете, не собирается помогать Вам очень так или иначе.
Я знаю, что Вы спросили конкретно о pentesting инструментах, но так как им достаточно ответили (я обычно иду с соединением AppScan и обученного pentester), я думаю, что важно указать, что pentesting не является единственным способом "проверить на лазейки безопасности" и часто не самое эффективное .
инструменты обзора Исходного кода могут предоставить Вам намного лучшую видимость в Вашу кодовую базу и найти много дефектов, что pentesting не будет.
Они включают, Укрепляют и OunceLabs (дорогой и для многих языков), VisualStudio.NET CodeAnalysis (для.NET и C++, свободного с VSTS, достойным, но не большие), ОШИБКА OWASP для Java (свободный, достойный не большой), CheckMarx (не дешевый, фантастический инструмент для.NET и Java, но высоко наверху)и многое другое.
важный момент необходимо отметить - (большая часть), автоматизированные инструменты не находят все уязвимости, даже не закрываются. Можно ожидать, что автоматизированные инструменты найдут приблизительно 35-40% secbugs, который был бы найден профессиональным pentester; то же идет для автоматизированного по сравнению с ручным обзором исходного кода.
И конечно надлежащий SDLC (Цикл безопасной разработки), включая Моделирование угроз, Анализ проекта, и т.д., поможет еще больше...
Безопасная McAfee не является решением. Услуга, которую они предоставляют, является шуткой.
Посмотрите ниже:
http://blogs.zdnet.com/security/?p=1092&tag=rbxccnbzd1
http://blogs.zdnet.com/security/?p=1068&tag=rbxccnbzd1
http://blogs.zdnet.com/security/?p=1114&tag=rbxccnbzd1
Я услышал хорошие вещи о SpiDynamics WebInspect, насколько заплаченный решения идут, а также Nikto (для бесплатного решения) и другие инструменты с открытым исходным кодом. Nessus является превосходным инструментом для инфраструктуры в случае, если необходимо проверить тот слой также. Можно взять живой CD с несколькими инструментами на нем, назвал Nubuntu (Аудитор, Спираль, или любое другое основанное на безопасности распределение работает также), и затем Google некоторые учебные руководства для определенного инструмента. Всегда, всегда удостоверяйтесь, что просканировали от локальной сети все же. Вы рискуете блокировать себя, по условию центрируются, если Вы сканируете поле от WAN без авторизации. Урок научился на горьком опыте.;)
http://www.nessus.org/nessus/ - которому поможет Nessus, предлагает способы сделать Ваши серверы лучше. Это не может действительно протестировать пользовательские приложения отдельно, хотя я думаю, что плагины относительно легко создать самостоятельно.
Смотрите на Рациональное Сканирование Приложения (раньше назывался Watchfire). Не свободный, но имеет хороший UI, мертв мощный, генерирует отчеты (сделанный на заказ и против стандартных платформ соответствия, таких как Basel2), и я полагаю, что можно написать сценарий его в сборку CI.
Для этого типа тестирования вам действительно может понадобиться какой-нибудь тестер нечеткости. SPIKE Proxy - один из нескольких нечетких тестеров для веб-приложений. Он имеет открытый исходный код и написан на Python. Я полагаю, что есть пара видео от BlackHat или DefCON об использовании SPIKE где-то там, но мне трудно их найти.
Есть пара профессиональных пакетов программного обеспечения высокого класса, которые будут выполнять тестирование веб-приложений и многое другое. Больше. Одним из наиболее популярных инструментов будет CoreImpact
. Если вы все же планируете пройти тестирование на проникновение самостоятельно, я настоятельно рекомендую вам прочитать большую часть документации проекта OWASP . В частности, руководства по проверке и тестированию / разработке безопасности приложений OWASP.
А как насчет Proxy ?
Полуавтоматическая, в основном пассивная сеть Инструмент аудита безопасности приложений, оптимизирован для точного и чувствительное обнаружение и автоматическое Аннотация, потенциальных проблем и Соответствующие охранные конструкции на основе наблюдения существующих, Пользовательский трафик в сложной сети 2.0 Среда.
обнаруживает и определяет распределение широких классов проблем безопасности, таких как динамический Международные модели доверия доверия, Вопросы включения скрипта, содержание Проблемы с обслуживанием, недостаточно XSRF И XSS защиты, и гораздо больше
RatProxy в настоящее время считается поддерживать среды Linux, FreeBSD, MacOS X и Windows (Cygwin).
I know you asked specifically about pentesting tools, but since those have been amply answered (I usually go with a mix of AppScan and trained pentester), I think it's important to point out that pentesting is not the only way to "check for security loopholes", and is often not the most effective.
Source code review tools can provide you with much better visibility into your codebase, and find many flaws that pentesting won't.
These include Fortify and OunceLabs (expensive and for many languages), VisualStudio.NET CodeAnalysis (for .NET and C++, free with VSTS, decent but not great), OWASP's LAPSE for Java (free, decent not great), CheckMarx (not cheap, fanTASTic tool for .NET and Java, but high overhead), and many more.
An important point you must note - (most of) the automated tools do not find all the vulnerabilities, not even close. You can expect the automated tools to find approximately 35-40% of the secbugs that would be found by a professional pentester; the same goes for automated vs. manual source code review.
And of course a proper SDLC (Security Development Lifecycle), including Threat Modeling, Design Review, etc, will help even more...