Является ли ASP.NET MVC уязвимым для атаки оракула?

Question

Является ли ASP.NET MVC 2 уязвимым для атаки oracle padding ? Если так, какой обходной путь должен быть реализован? Похоже, что инструкции в блоге Скотта Гу предназначены только для веб-форм.

Я пробовал это:

<customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="/Home/ErrorPage" />

однако, http://www.example.com/PageThatDoesNotExist по-прежнему возвращает стандартную страницу ошибки 404.

РЕДАКТИРОВАТЬ : Я вижу, что Скотт Гу разместил в комментариях под своим постом в блоге, что MVC уязвим, но мне все еще не ясно, как именно реализовать обходной путь.

Answer 1

Да - связь с комментарием Скотта Гатри.

Суббота, 18 сентября 2010 г., 21:00, СкоттГу

@ Виджай,

Будет ли затронут ASP.NET MVC?

Да - затронуты все версии ASP.NET, включая ASP.NET MVC.

Спасибо,

Скотт

Я вижу, что вы видели комментарий, но если вы запустите скрипт vbs на вашем сервере, он должен сообщить вам, если это все еще проблема.

Редактировать: Кроме того, Скотт обсудил часто задаваемые вопросы в новом сообщении здесь .

Answer 2

Я опубликовал свой полный обзор этого (после дополнительного исследования) на моем блоге .

Примечание об обновлении: перемещена ссылка на пост, относящийся к asp.net MVC

---

Я твердо верю, что проблема с 404 связана с WebResources и ScriptResources(который может отключить для asp.net MVC btw), поскольку они, вероятно, дают 404 секунды, когда соответствующий ресурс не найден (что будет нормальным ответом на допустимый отступ, который дает неверный путь / имя ресурса).

Другие коды ошибок и сообщения могут быть проблемой для других функций asp.net, но заканчивающиеся на 404 только потому, что вы нажали URL, не связанный с каким-либо специальным обработчиком, не должны вызывать проблему.

Также обратите внимание на то, что я упомянул в этом ответе: Насколько серьезна эта новая уязвимость безопасности ASP.NET и как ее можно обойти?

, если приложение является asp.Для net MVC нам не нужны webresources.axd и / или scriptresources.axd, поэтому их можно отключить.Мы также не используем viewstate.

роли кэшей провайдера asp.net 'кэшируют' в файлах cookie, отключите его.

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

Как упоминал Аристос, для идентификатора сеанса вcookie, случайный для пользовательского сеанса, поэтому его нужно будет прослушивать у пользователя с целевым уровнем безопасности и взламывать, пока этот сеанс активен.Даже тогда, если вы полагаетесь на аутентификацию для назначения / авторизации пользовательских операций, это влияние будет минимальным / во многом зависит от того, для чего используется Session в этом приложении.

Answer 3

Этот вопрос входит в список часто задаваемых вопросов Скотта Гу об уязвимости безопасности ASP.NET :

Влияет ли это как на веб-формы ASP.NET, так и на ASP.NET MVC?

Да - опубликованный эксплойт может использоваться против всех типов приложений ASP.NET (включая веб-формы и MVC).

Answer 4

По вашему маршруту по умолчанию вы можете / должны добавить это для начала

routes.MapRoute("Catch All", "{*path}", new { controller = "Home", action = "ErrorPage" });

Изменить 2

проблема заключается в части redirectMode="ResponseRewrite" без этого,это работает.

с использованием маршрута, хотя и решит 1 часть проблемы, где путь не может быть найден (404)

следующей части, как существующие пути с неверными идентификаторами или другими данными,можно исправить с помощью

<customErrors mode="On" defaultRedirect="/Home/ErrorPage" />

что именно делает redirectMode="ResponseRewrite"?

Редактировать: что он делает.

redirectMode

• ResponseRedirect: указывает, что URL-адрес, на который должен направлять браузер, должен отличаться от исходного URL-адреса веб-запроса.
• ResponseRewrite: указывает, что URL-адрес браузера должен быть исходным URL-адресом веб-запроса.

Это имеет значение только для .NET 3.5 SP1 и .NET 4.0.

Редактировать 101:

Для redirectMode = "ResponseRewrite" ASP.NET внутренне вызывает Server.Execute (...), который не работает с маршрутами MVC, поэтому для MVCэто работает только со статическим файлом HTML.

<customErrors mode="On" defaultRedirect="~/Views/Shared/error.htm" redirectMode="ResponseRewrite" />

работает.

Answer 5

Патч для этой ошибки был выпущен в Центре обновления Windows.

http://weblogs.asp.net/scottgu/archive/2010/09/30/asp-net-security-fix-now-on-windows-update.aspx

Answer 6

У вас есть настройка действия маршрута / контроллера для возврата страницы ошибки для маршрута /Home/ErrorPage?