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

Question

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

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

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

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

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

РЕДАКТИРОВАТЬ

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

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

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

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

Answer 1

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

Answer 2

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

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

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

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

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

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

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

Answer 3

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

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

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

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

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

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

Answer 4

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

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

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

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

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

Answer 5

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

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

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

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

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