Контрольный список безопасности ASP.NET MVC

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

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

(ОБНОВЛЕНИЕ: меня больше интересует контрольный список Blackbox - "перейдите на страницу, попробуйте что-то подобное", но может быть интересен контрольный список whitebox.)

Здесь что-то я придумал до сих пор:

Контрольный список безопасности Blackbox

  • Отправить неверные/вредоносные данные ( примеры здесь < ), чтобы убедиться, что входные данные проверяются на тип, длину, формат и диапазон на javascript.
  • Отключите проверку на стороне клиента и повторите шаг выше, чтобы убедиться, что
    • вы не только проверяете с помощью javascript, но и проверяете на стороне сервера.
    • на сервере проверяется тип, длина, формат и диапазон
    • ввод свободной формы дезинфицирован
    • который включает вход, кодируется с помощью HtmlEncode и UrlEncode
  • Вставляйте чрезвычайно большой объем данных в строку запроса в соответствии с http://www.example.com/foo?bar=HugeAmountOfData, чтобы убедиться, что вы ограничиваете входные данные и выполняете пограничные проверки.
  • Посетите POST-действие через GET, чтобы убедиться, что действия "отправить форму" ограничены только POST-адресом.
  • Если это применимо, загрузите файл с неправильным размером/форматом (огромный файл, пустой файл, исполняемый файл с переименованным расширением и т.д.), чтобы убедиться, что закачки обработаны изящно.
  • (как проверить из UI?) убедитесь, что для навигации используются абсолютные URL.
  • Получите доступ к URL-адресу как пользователю без правильных разрешений, чтобы убедиться, что разрешения явно протестированы с помощью атрибутов action/controller.
  • Получите доступ к URL-адресу, предоставляющему несуществующие данные (например, к отсутствующим идентификаторам продуктов, элементам, к которым у вас нет доступа и т.д.), чтобы убедиться, что верна правильная ошибка (404 или 403 и т.д.).
  • Доступ к конфиденциальной странице через HTTP, чтобы убедиться, что она доступна только через HTTPS.

Контрольный список безопасности Whitebox

Веб-уровень.

  • В режиме отладки сломайте код так, чтобы он выдавал исключение, чтобы убедиться, что он не работает надежно. Удостоверьтесь, что вы обнаруживаете исключения и записываете подробные сообщения, но не отправляете информацию клиенту.
  • Если это применимо, убедитесь, что действия MVC ограничены только POST/GET, особой ролью пользователя, чем-либо еще?.
  • Убедитесь, что действия POST сопровождаются атрибутом [ValidateAntiForgeryToken] для предотвращения атак типа Cross-Site Request Forgery.
  • Убедитесь, что Response.Write (прямо или косвенно) никогда не используется для отображения пользовательского ввода.
  • Убедитесь, что конфиденциальные данные не передаются в строках запроса или в поля формы.
  • Убедитесь, что ваши решения по безопасности не зависят от информации заголовков HTTP.

Уровень обслуживания.

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

Уровень базы данных.

  • Убедитесь, что извлеченные сохраненные procs не используют SELECT *, но всегда явно указывают список столбцов.
  • Убедитесь, что обновленные/удаленные хранимые процедуры работают в транзакции (через @@TRANCOUNT и т.д.) и явно фиксируют/откатывают ее.

Комментарии? Поправки? Отсутствующие шаги?

Сделав его вики-сообществом, не стесняйтесь редактировать столько, сколько захотите.

Ответы

Ответ 1

Чтобы добавить к списку:

Black: DoS-атаки - используйте tinyget или аналогичный для имитации DoS-атак, посмотрите, что делает ваше приложение.

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

Белый: использование файлов cookie для конфиденциальной информации? См. Файлы cookie не используются для конфиденциальных данных и не сохраняются локально в течение заданного интервала. Черный: Sniff в папке IE IE/XYZ для файлов cookie.

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

Черный: выполните любую из атак и посмотрите, будет ли администратор автоматически уведомлен об атаке, или это только тот, кто знает об этом.

"Убедитесь, что ваши решения по безопасности не зависят от информации заголовков HTTP" - http-заголовки используются для аутентификации ntml/kerberos? Может быть, просто не используйте их глупо, не изобретайте или не полагайтесь на реферера и т.д.

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

Ответ 2

Придерживаясь главным образом специфическим для MVC материала:

  • В ASP.NET 4 понимайте <%: и MvcHtmlString.
  • Используйте HTML-помощники, когда это возможно, вместо необработанного HTML, поскольку это увеличивает вероятность того, что вы забудете кодировать (помощники делают это за вас)
  • Проанализируйте все виды использования JsonRequestBehavior.AllowGet, чтобы гарантировать, что он не сможет вернуть массив.
  • Не изобретайте все, что связано с безопасностью. Используйте проверенные, поддерживаемые, готовые реализации.
  • Не утечка информации о безопасности в robots.txt

Ответ 3

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

  • Проверить авторизацию пользователя (после проверки подлинности) для каждой чувствительной операции

  • Остерегайтесь выходного кэширования, особенно если вы реализуете свою собственную систему членства

Ответ 4

Убедитесь, что вы не слепо связываете данные формы с вашей моделью, всегда используя TryUpdateModel<T> over TryUpdateModel.