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

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

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

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

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

EDIT: я вижу, что Скотт Гу опубликовал в комментариях в своем блоге сообщение о том, что MVC уязвим, но мне все еще не ясно, как реализовать обходной путь.

Ответ 1

Да - ссылка на комментарий Скотта Гатри.

Суббота, 18 сентября 2010 г. 9:00 вечера от ScottGu

@Vijay,

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

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

Спасибо,

Скотт

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

Изменить: Также Скотт обсудил часто задаваемые вопросы в новом сообщении здесь.

Ответ 2

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

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-адрес для браузер должен быть оригинальным Web 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" />

работы.

Ответ 3

Этот вопрос включен в Scott Gu Часто задаваемые вопросы об уязвимости безопасности ASP.NET:

Оказывает ли это влияние на ASP.NET Web Forms и ASP.NET MVC?

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

Ответ 4

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

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

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

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

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

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

роли поставщика кэширования asp.net asp.net в файлах cookie, отключите это.

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

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

Ответ 5

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

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

Ответ 6

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