Я надеюсь, что кто-то сможет помочь мне понять эту проблему и нужно ли мне предпринять какие-либо дополнительные шаги для защиты моего приложения.
Учитывая эту уязвимость, она, похоже, влияет на серверы, которые соответствуют следующим критериям:
- Служить с сервера, который использует сжатие на уровне HTTP
- Отразить пользовательский ввод в телах ответа HTTP
- Отразить секрет (например, токен CSRF) в телах ответа HTTP
Также представляется, что шаги по смягчению в порядке эффективности:
- Отключение HTTP-сжатия
- Разделение секретов с пользовательского ввода
- Рандомизирующие секреты за запрос
- Маскировка секретов (эффективное рандомизация с помощью XORing со случайным секретом для каждого запроса)
- Защита уязвимых страниц с помощью CSRF
- Спрятать длину (путем добавления случайного числа байтов к ответам)
- Ограничение скорости запросов
В представлении моей страницы я @Html.AntiForgeryToken вспомогательный метод @Html.AntiForgeryToken который создает соответствующие входные данные и @Html.AntiForgeryToken cookie при посещении формы. От взгляда на то, что делает этот вспомогательный метод, создается впечатление, что каждый раз, когда загружается страница, создается новый уникальный маркер, который, как представляется, соответствует пункту 3 в шагах смягчения, а действие использования токена CSRF в первую очередь соответствует точке 5,
Отключение HTTP-сжатия, по-видимому, широко расценивается как "не очень хорошее для производительности" и из некоторых других ресурсов, которые я читал, укорачивание длины может вызвать проблемы для таких функций, как загрузка файлов (что используется на этой странице)
Итак, после всего этого, единственное, что я могу сейчас по-настоящему рассмотреть, - это разделение секретов от пользовательского ввода. Я думал о том, что, возможно, попытаюсь поставить значение токена CSRF на сеанс..... или я полностью переосмыслил это и является текущей версией "@Html.AntiForgeryToken", достаточно подходящей для защиты нас?
