Есть много хороших статей о проектировании и разработке для безопасности (и даже куча сообщений на 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и т.д.) и явно фиксируют/откатывают ее.
Комментарии? Поправки? Отсутствующие шаги?
Сделав его вики-сообществом, не стесняйтесь редактировать столько, сколько захотите.
