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

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

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

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

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

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

Источник

6 ответов

Решение

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

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

@Vijay,

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

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

Спасибо,

Скотт

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

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

Источник

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

Влияет ли это как на ASP.NET Web Forms, так и на ASP.NET MVC?

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

Источник

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

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" />

работает.

Источник

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

Обновление заметки: перемещена ссылка на пост, относящийся к 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, отключите это.

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

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

Источник

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

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

Источник

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

Источник
Другие вопросы по тегам