Любой встроенный способ предотвратить подделку межсайтовых запросов (CSRF) в ASP .NET 4.0 (не MVC)? - PullRequest
Новая
       1

Любой встроенный способ предотвратить подделку межсайтовых запросов (CSRF) в ASP .NET 4.0 (не MVC)?

2 голосов
/ 30 сентября 2011

Существует ли какой-либо встроенный способ предотвращения подделки межсайтовых запросов (CSRF) на веб-сайтах ASP .NET 4.0 на основе веб-форм (, а не MVC )? Я вижу, что фреймворк генерирует скрытые поля формы __EVENTVALIDATION и __VIEWSTATE, и я зашифровал их с помощью machineKey и viewStateEncryptionMode = "Always" в моем файле web.config. Тем не менее, не ясно, могут ли они на самом деле предотвратить CSRF-атаки. Я протестировал перекрестную публикацию (через PostBackUrl в форме asp: Button), где я изменил скрытые зашифрованные поля формы __VIEWSTATE, __EVENTVALIDATION и __PREVIOUSPAGE (дополнительно для перекрестных публикаций), а другие чувствительные поля формы все еще достигли моего блока обработки кода позади , Я ожидал, что структура обнаружит измененные зашифрованные поля и выдаст ошибку. К вашему сведению, я сохранил aspx в формате .html, изменил эти скрытые поля формы и повторно использовал форму (теперь в формате .html) для имитации атакующего. Таким образом, я все еще мог бы публиковать в своих чувствительных формах / полях, потому что (начало предположений) .html файлы не проходят через механизм обработки ASP.NET? (/ конец спекуляции)

Если такого встроенного механизма не существует, есть ли фрагменты кода для быстрого создания прототипов / использования? Я могу легко создать уникальный идентификатор для каждого пользователя, хэшируя идентификатор пользователя, и даже установить скрытую переменную формы для этой переменной c #. Но ASP.NET 4.0 механика

  • Также устанавливая эту переменную c # как cookie

и

  • Проверка, если значение cookie == значение формы при последующих запросах (для достоверности)

мне непонятно.

1 Ответ

1 голос
/ 14 октября 2011

Я не знаю, как сделать это в рамках, но вы можете сделать это самостоятельно проще, чем ваш пост предлагает.

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

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

...