Существуют ли лучшие практики для тестирования безопасности в Agile магазин развития?

голоса
9

Что касается Agile развития, каковы лучшие практики для тестирования безопасности на выпуск?

Если это ежемесячный выпуск, есть магазины делают PEN-тесты каждый месяц?

Задан 05/08/2008 в 16:05
источник пользователем
На других языках...                            


4 ответов

голоса
1

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

Ответил 05/08/2008 в 18:19
источник пользователем

голоса
1

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

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

Ответил 05/08/2008 в 18:50
источник пользователем

голоса
1

Модульное тестирование , программирование обороны и много журналов

Модульное тестирование

Убедитесь, что тест, который вы единичный как можно раньше (например, пароль должен быть зашифрован перед отправкой, то SSL туннель работает, и т.д.). Это позволит предотвратить ваши программист случайно делает программу небезопасной.

Программирование обороны

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

  • это печенье на пользователя действует?
  • он до сих пор в настоящее время вошли в систему?
  • являются параметры функции защищены от инъекции SQL? (Даже если вы знаете, что вход порождаются собственных функций, вы испытаете все равно)

логирование

Войти все, как сумасшедшие. Ее легче удалить журналы затем добавить их. Пользователь вошел в системе? Войти его. Пользователь нашел 404? Войти его. Администратор отредактировать / удалить сообщение? Войти его. Кто-то был в состоянии получить доступ к ограниченной странице? Войти его.

Не удивляйтесь, если ваш файл журнала достигает 15+ Мб во время стадии разработки. Во время бета-тестирования, вы можете решить, какие журналы удалить. Если вы хотите, вы можете добавить флаг, чтобы решить, когда определенное событие регистрируется.

Ответил 18/08/2008 в 03:40
источник пользователем

голоса
2

Каков ваш домен приложения? Это зависит.

Так как вы использовали слово «Agile», я предполагаю, что это веб-приложение. У меня есть хороший легкий ответ для вас.

Пойти купить копию Burp Suite (это # ​​1 Google результат для «отрыжки» --- верного одобрения!); это будет стоить вам 99EU, или ~ $ 180USD, или $ 98 Обама долларов, если вы будете ждать до ноября.

Отрыжка работает как прокси-сервер. Вы просматриваете через веб-приложение, с помощью Firefox или IE или любой другой, и он собирает все хиты, которые вы создаете. Эти хиты надоедают в функцию под названием «Intruder», который является веб-fuzzer. Нарушитель будет выяснить все параметры, которые вы предоставляете каждый из обработчиков запросов. Затем он будет пытаться сумасшедшими значениями для каждого параметра, включая SQL, файловую систему, и HTML метасимволы. На типичной сложной формы пост, это будет генерировать около 1500 хитов, которые вы будете выглядеть через, чтобы идентифицировать страшно --- или, что более важно в контексте Agile, новые --- ошибочные ответы.

Fuzzing каждый обработчик запросов в веб-приложение на каждой итерации релиз является # 1, что вы можете сделать, чтобы повысить безопасность приложений без возбуждения формального «SDLC» и добавив численность персонала. Кроме того, проверить ваш код для основных веб-приложений безопасности горячих точках:

  • Используйте только параметризованные подготовленные операторы SQL; никогда не просто конкатенации строк и кормить их к вашей ручке базы данных.

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

  • Используйте длинные случайные идентификаторы труднодоступные догадки в любом месте вы в настоящее время используете идентификаторы строк просто целочисленные в параметрах запроса, и убедитесь, что пользователь X не может видеть данные пользователя из Y просто угадывая эти идентификаторы.

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

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

  • Используйте Bcrypt --- и ничего --- хранить хеширования паролей.

Ответил 10/09/2008 в 22:19
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more