MVC 2 AntiForgeryToken - Почему симметричное шифрование + IPrinciple?

Question

Недавно мы обновили наше решение до MVC 2, и это обновило способ работы AntiForgeryToken. К сожалению, это больше не подходит для нашей платформы AJAX.

Проблема в том, что MVC 2 теперь использует симметричное шифрование для кодирования некоторых свойств пользователя, включая свойство Name пользователя (из IPrincipal). Мы можем безопасно зарегистрировать нового пользователя с помощью AJAX, после чего последующие вызовы AJAX будут недействительными, поскольку маркер защиты от подделки изменится, когда пользователю будет предоставлен новый участник. Это также может произойти в других случаях, например, когда пользователь обновляет свое имя и т. Д.

Мой главный вопрос: почему MVC 2 вообще беспокоится об использовании симметричного шифрования? И тогда почему он заботится о свойстве имени пользователя на основном сервере?

Если мое понимание верно, то подойдет любой случайный общий секрет. Основной принцип заключается в том, что пользователю будет отправлено печенье с некоторыми конкретными данными (HttpOnly!). Затем этот файл cookie необходим для соответствия переменной формы, отправляемой обратно каждому запросу, который может иметь побочные эффекты (обычно POST). Поскольку это предназначено только для защиты от межсайтовых атак, легко создать ответ, который бы легко прошел тест, но только если у вас был полный доступ к cookie. Поскольку злоумышленник не будет иметь доступа к вашим пользовательским файлам cookie, вы защищены.

Каким преимуществом при проверке содержимого cookie является использование симметричного шифрования? То есть, если я уже отправил файл cookie HttpOnly, злоумышленник не сможет его переопределить (если только в браузере нет серьезных проблем с безопасностью), так почему же мне нужно проверить его еще раз?

Подумав об этом, он кажется одним из тех «добавленных слоев безопасности», но если ваша первая линия обороны упала (HttpOnly), то злоумышленник все равно пройдет второй уровень, когда иметь полный доступ к коллекции файлов cookie пользователей и может просто олицетворять их напрямую, вместо использования косвенной атаки XSS / CSRF.

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

Answer 1

Он был добавлен для обеспечения большей защиты в случае, когда один поддомен пытается атаковать другой - bad.example.com пытается атаковать good.example.com.Добавление имени пользователя затрудняет bad.example.com возможность связаться с good.example.com за кулисами и попытаться заставить его сгенерировать токен от вашего имени.

В дальнейшем возможно, что cookieбудут удалены, так как это не является строго необходимым для правильного функционирования системы.(Например, если вы используете проверку подлинности с помощью форм, этот файл cookie может служить файлом cookie анти-XSRF вместо того, чтобы требовать от системы создания второго файла cookie.) Файл cookie может быть выдан только в случаеанонимные пользователи, например.

Answer 2

Помимо сценария "злой поддомен", описанного Леви, рассмотрим злоумышленника, имеющего учетную запись на целевом сайте. Если CSRF-токен не кодирует специфичную для пользователя информацию, сервер не может проверить, что токен был создан исключительно для вошедшего в систему пользователя. Затем злоумышленник может использовать один из своих законно приобретенных CSRF-токенов при создании поддельного запроса.

При этом анонимные токены при определенных обстоятельствах принимаются ASP.NET MVC. См. Почему ValidateAntiForgeryTokenAttribute разрешает анонимные токены?