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

Question

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

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

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

---

Вот кое-что, что я до сих пор придумал:

Контрольный список безопасности черного ящика

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

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

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

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

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

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

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

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

---

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

Делая это вики-сообществом, вы можете редактировать столько, сколько захотите.

Answer 1

Добавить в список:

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

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

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

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

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

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

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

Answer 2

Придерживаюсь в основном материала, специфичного для MVC:

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

Answer 3

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

Answer 4

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

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

• Следите за кэшированием вывода, особенно если вы внедрили собственную систему членства