HttpAntiForgeryException обрабатывается как 403 и 500 в зависимости от того, включены ли пользовательские ошибки - PullRequest
Новая
       1

HttpAntiForgeryException обрабатывается как 403 и 500 в зависимости от того, включены ли пользовательские ошибки

0 голосов
/ 20 января 2012

Недавно мы внедрили защиту от CSRF на веб-сайте, над которым работаем в ASP.Net MVC 3.

Используя немного разных методов, у нас есть рабочее решение.

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

Когда пользовательские ошибки включены, мы получаем 403, когда выключен установленный код состояния 500.

Исключением является throw, это исключение HttpAntiForgeryException, которое должно быть 500 из моей проверки источника MVC.

Он создается внутри атрибута ActionFilterAttribute, оборачивает ли это исключение внутри 403?

IIS делает что-то странное?

Любые мысли приветствуются.

Приветствия

1 Ответ

0 голосов
/ 02 марта 2012

У меня реализовано решение MVC 3 для защиты от CSRF, и я никогда не получаю код 403, когда намеренно пытаюсь выполнить проверку (подавляя файлы cookie на стороне клиента после получения и перед отправкой).

Проверкасделано для действия, имеющего атрибут ValidateAntiForgeryToken.CutomErrors устанавливается с помощью RemoteOnly, затем On, затем Off.Протестировано дважды, первый раз на сервере разработки Cassini, второй раз на IIS6.

Я всегда получал код ответа 500.

Полагаю, проблема в обработке пользовательских ошибок, которые вы используете.Вам также следует проверить, есть ли у вас httpModule, выполняющий какую-либо настраиваемую логику для событий ошибок.(Маловероятно, если вы используете атрибут MVC HandleError, так как эта обработка MVC customError перехватывает ошибки перед обработкой HttpModule, которая затем никогда не видит ошибок.)

Без дополнительных подробностей в вашем вопросе о том, какой механизм обработки customError вы используете,трудно дать больше указаний.

Шахта не является ни стандартом MVC (использующим HandleError в качестве атрибута контроллера, атрибута действия или глобального фильтра), ни классическим asp.net.Это тоже не Эльма.Я обрабатываю ошибки в событии Application_Error по «историческим» причинам (и мне было легче поддерживать обработку ошибок ISS 6 и 7, что мне нужно сделать до завершения миграции наших серверов).Код моей логики обработки ошибок в событии Application_Error: 

var statusCode = 500;
var ex = Server.GetLastError();
if (ex != null)
{
    var httpEx = ex as HttpException;
    if (httpEx != null)
    {
        // HttpAntiForgeryException is HttpException and gets received here,
        // so its statusCode is what I get here.
        statusCode = httpEx.GetHttpCode();
    }
}
// Some logging logic then
if (!Context.IsCustomErrorEnabled)
    return;

Response.ClearContent();
Response.StatusCode = statusCode;
// Rendering custom error page in response then
Server.ClearError();
...