Аудит безопасности приложений веб-приложения .NET?

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

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

Каждому в вашей ситуации доступны следующие варианты:

1. Проверка кода,
2. Статический анализ кодовой базы с помощью инструмента,
3. Динамический анализ приложения во время выполнения.

Митчел уже указывал на использование Fortify. Фактически, у Fortify есть два продукта, охватывающих области статического и динамического анализа - SCA (инструмент статического анализа, который будет использоваться при разработке) и PTA (который выполняет анализ приложения по мере выполнения тестовых примеров во время тестирования).

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

Для начала можно начать с OWASP. Перед изучением Руководство по разработке OWASP настоятельно рекомендуется ознакомиться с принципы безопасности (версия 3.0 находится в черновом варианте; 2.0 можно считать стабильной). Наконец, вы можете подготовиться к выполнению первое сканирование вашей кодовой базы.

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

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

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

Если вы попросите кого-нибудь проверить ваш дизайн и требования к безопасности (от чего именно вы пытаетесь защитить?) С полным доступом к коду и всем деталям, это будет более ценно, чем какой-то тест черного ящика. Потому что, если ваш дизайн неправильный, не имеет значения, насколько хорошо вы его реализовали.

Лучшее, что можно сделать:

• Найм специалиста по безопасности для анализа исходного кода
• Второй лучший вариант - нанять охранника / компанию по тестированию на проникновение для анализа черного ящика.

Следующие инструменты помогут:

• Инструменты статического анализа Fortify / Ounce Labs - Обзор кода
• Рассмотрите такие решения, как защищенный объект HP WebInspects (надстройка VS.NET).
• Покупка сканера приложений черного ящика, такого как Netsparker, Appscan, WebInspect, Hailstorm, Acunetix или бесплатной версии Нетспаркер

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

Мы несколько раз использовали Telus для тестирования на проникновение и были впечатлены результатами.

Могу я порекомендовать вам связаться с Artec Group, Компас безопасности и Veracode и ознакомиться с их предложениями ...