Является ли 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
?