Производительность и безопасность сопоставлений и модулей приложений-обработчиков ASP.NET MVC

Я только что прочитал интересную статью. В основном это говорит о том, что вы должны точно настроить параметры IIS для каждого приложения двумя способами:

сопоставления обработчиков - удалить все неиспользуемые приложением
модули - удалить все неиспользуемые приложением

Хорошо, я разрабатываю ASP.NET уже некоторое время, даже на работе, и мы никогда не делали этого на производственной среде afaik. Я понимаю представленные теоретические преимущества - минимизацию "поверхности" приложения (безопасности) и повышение производительности. Но мне действительно интересно, если вы делаете это в реальной жизни (реальные проекты для ваших клиентов, а не проекты с концептуальной концепцией). Каковы недостатки этого (возможно, maintanability?). И самый важный вопрос - стоит ли это? Является ли, например, увеличение производительности даже видимым?

Кроме того, если вы считаете это хорошей практикой, представьте какой-нибудь хороший и последовательный способ (или укажите мне учебник), как именно вы это делаете - как вы решаете, какое пребывание и что удалить.

Например, минимальный, но рабочий набор для приложения ASP.NET MVC 3, который использует настраиваемую аутентификацию (основанную на сеансе, не полагающуюся на Forms auth, Windows auth и т.д.), нет веб-сервисов и подобных функций?

ИЗМЕНИТЬ

Я нашел эту статью: http://madskristensen.net/post/Remove-default-HTTP-modules-in-ASPNET.aspx

В нем Скотт Гатри говорит:

В общем, вы можете получить очень небольшие выигрыши в производительности, используя этот подход, хотя я бы, вероятно, не рекомендовал этого делать. Причина в том, что некоторые функции ASP.NET(формы auth, role, caching и т.д.), Конечно, перестанут работать после удаления модулей, от которых они зависят. Попытка выяснить, почему это произошло, часто может сбивать с толку.

Но все же никаких измерений, практик (я не совсем уверен в аргументе "вы можете быть удивлены позже" ):

Ответ 1

Для чего стоит Рекомендации по безопасности для IIS 8:

Установите только те модули IIS, которые вам нужны.

IIS 8 состоит из более чем 40 модулей, которые позволяют вам добавлять нужные модули и удалять любые модули, которые вам не нужны. если ты установите только те модули, которые вам нужны, вы уменьшите площадь поверхности, которая подвержена потенциальным атакам.

Периодически удалять неиспользуемые или нежелательные модули и обработчики.

Ищите модули и обработчики, которые вы больше не используете и не удаляете их из вашей установки IIS. Стремитесь сохранить свою поверхность IIS площадь как можно меньше.

Обзор модулей IIS также содержит ссылку на модули IIS с разделом "Потенциальные проблемы при удалении этого модуля" для каждого модуля. Например, если модуль DefaultAuthentication удален:

Некоторые функции ASP.NET могут не работать для анонимных запросов, если режим аутентификации ASP.NET является Forms. Кроме того, событие DefaultAuthentication.OnAuthenticate не будет создано.

Ответ 2

<modules runAllManagedModulesForAllRequests="false">
  <!-- disable authorization section -->
  <remove name="UrlAuthorization" />
  <!-- disable unused authentication schemes -->
  <remove name="WindowsAuthentication" />
  <remove name="PassportAuthentication" />
  <!-- disable ACL file and directory check -->
  <!-- <remove name="FileAuthorization" /> -->
  <!-- We don't use ASP.NET Profiles -->
  <remove name="Profile" />
  <!-- We don't provide any WCF service -->
  <remove name="ServiceModel" />
  <!-- Remove modules not used by ASP.NET MVC + jQuery -->
  <remove name="ScriptModule-4.0" />
</modules>

Ответ 3

Это напрямую не отвечает на ваш вопрос, но, отвечая на еще один вопрос на SO, я только что узнал о воздействии на производительность MVC на наличие Включен модуль перезаписи URL.

При создании URL-адреса (например, с помощью метода, например Html.ActionLink), в некоторых случаях MVC проверяет, запрошенный URL был переписан модулем URL Rewrite. Если это в случае, если результат обрабатывается так, чтобы он правильно соответствовал URL-адресу запрошенный клиентом. Акт проверки того, был ли URL-адрес перезаписанная имеет нетривиальную стоимость (поскольку она включает проверку сервера переменные). ASP.NET MVC 3 проверяет, отключена ли перерисовка URL и может кэшировать этот факт, тем самым избегая необходимости проверять сервер переменные для каждого запроса. Если URL Rewrite включен, MVC будет для проверки серверных переменных, даже если переписывание не произошло конкретный запрос, поэтому, если вы не используете URL Rewrite, вы должны повернуть это отключено.

Итак, вот пример, даже если вы не используете модуль, это может повлиять на ваше приложение.

Однако я бы подумал, что если у вас есть проблемы с безопасностью с определенными модулями или обработчиками, с которыми мне пришлось бы согласиться с Скоттом Гу, вы, вероятно, не заметите (если только вы не обращаетесь с 1 миллионом запросов в день или что-то еще) и было бы лучше потратить на это время настройку профилей кэша (базы данных и содержимого).

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

Ответ 4

С точки зрения производительности, это отличная передовая практика. Часто, однако, есть и другие факторы, которые следует учитывать.

Большинство приложений расширяются с течением времени. Если вы не используете функцию сейчас, вы можете в будущем. Когда вы это сделаете, я могу представить, что кто-то забывает изменить настройки IIS, в результате чего ваша производственная среда будет работать дольше.
Производственные среды часто не находятся в руках разработчиков.

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

б. Чем короче руководство по выпуску, тем лучше. Добавление ненужных (в данном случае, тривиальных) шагов для повышения производительности может привести к просмотру шагов.

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

Ответ 5

Во-первых, я буду честным здесь, и буду ясно, что я не сделал этого, но в одном случае (подробнее об этом ниже).

Вы должны учитывать, что с точки зрения безопасности это не проблема. Если вы знаете, что не используете набор функций, почему их следует подвергать?

Теперь вернемся назад к сентябрю 2010 года. Была серьезная уязвимость: оракул asp.net. У меня есть несколько сообщений в блоге, один на asp.net padding oracle: влияние на asp.net MVC и PHP

Обратите внимание, что это может повлиять на PHP, даже если asp.net активно не использовался.

Итак, проблема была в обработчиках, которые обычно не используются в asp.net MVC. Фактически, на нескольких клиентских серверах/приложениях, которые я обрабатывал в то время, мы отключили обработчики. Уязвимость закрыта, прежде чем MS выкатит свое решение; приложения не были затронуты, поскольку мы не использовали ни одного из обработчиков.

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