Как защитить статические файлы с помощью проверки подлинности формы ASP.NET в IIS 7.5? - PullRequest
Новая
       34

Как защитить статические файлы с помощью проверки подлинности формы ASP.NET в IIS 7.5?

33 голосов
/ 25 мая 2010

У меня есть веб-сайт, работающий на сервере IIS 7.5 с ASP.NET 4.0 на общем хосте, но с полным доверием.

Сайт представляет собой базовый «файловый браузер», который позволяет посетителям входить в систему, отображать список доступных им файлов и, очевидно, загружать файлы. Статические файлы (в основном PDF-файлы) находятся в подпапке на сайте, называемой данными, например, http://example.com/data/...

Сайт использует аутентификацию формы ASP.NET.

У меня такой вопрос: как заставить механизм ASP.NET обрабатывать запросы статических файлов в папке данных, чтобы запрос на файлы проходил проверку подлинности в ASP.NET, и пользователи не могли получить глубокую ссылку файл и файлы захвата, которые они не могут иметь?

С уважением, Эгиль.

Ответы [ 6 ]

44 голосов
/ 25 мая 2010

Если ваш пул приложений работает в интегрированном режиме, вы можете сделать следующее.

Добавьте следующее в ваш верхний уровень web.config. 

  <system.webServer>
    <modules>
      <add  name="FormsAuthenticationModule"  type="System.Web.Security.FormsAuthenticationModule" />
      <remove  name="UrlAuthorization" />
      <add  name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule"  />
      <remove  name="DefaultAuthentication" />
      <add  name="DefaultAuthentication"  type="System.Web.Security.DefaultAuthenticationModule" />
    </modules>
  </system.webServer>

Теперь вы можете использовать стандартные разрешения ASP.NET в вашем файле web.config для принудительной проверки подлинности форм для всех файлов в каталоге. 

<system.web>
    <authorization>
        <deny users="?" />
    </authorization>
    <authentication mode="Forms" />
</system.web>
13 голосов
/ 01 мая 2012

У меня была такая же проблема с получением ролей для аутентификации. Методом проб и ошибок я наконец-то заставил его работать с небольшим редактированием кода @Joel Cunningham: 

<modules runAllManagedModulesForAllRequests="true" >

Я использовал эти два сайта в качестве ссылок: http://forums.iis.net/t/1177964.aspx и http://learn.iis.net/page.aspx/244/how-to-take-advantage-of-the-iis-integrated-pipeline/

9 голосов
/ 19 мая 2014

Это старая ветка, но я с ней столкнулся и столкнулся с той же проблемой, что и Эгиль. Вот версия исправления Джоэла, включающая роли: 

<modules runAllManagedModulesForAllRequests="false">
      <remove name="FormsAuthenticationModule" />
      <add name="FormsAuthenticationModule" type="System.Web.Security.FormsAuthenticationModule" />
      <remove name="UrlAuthorization" />
      <add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule"  />
      <remove name="RoleManager" />
      <add name="RoleManager" type="System.Web.Security.RoleManagerModule" />
      <remove name="DefaultAuthentication" />
      <add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" />
</modules>
8 голосов
/ 12 мая 2015

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

Вам необходимо удалить и повторно добавить модули, поскольку по умолчанию модули не добавляются с параметрами по умолчанию. В них добавлено предварительное условие для обратной совместимости для запуска только для содержимого, обрабатываемого зарегистрированным обработчиком ASP.NET (например, .aspx pages).

По умолчанию выглядит так: 

<add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" 
         preCondition="managedHandler" />

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

Вы можете прочитать об этом в нескольких статьях, когда интегрированный конвейер был представлен в IIS 7:

Обратите внимание, что во второй статье опечатка или имя модуля (и ответ @ John) были изменены с FormsAuthenticationModule на FormsAuthentication в некоторый момент.

Набор рабочих модулей в IIS 7.5 - 8.5 для меня выглядит следующим образом: 

<system.webServer>
  <modules>
    <!-- Re-add auth modules (in their original order) to run for all static and dynamic requests -->
    <remove name="FormsAuthentication" />
    <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" />
    <remove name="DefaultAuthentication" />
    <add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" />
    <remove name="RoleManager" />
    <add name="RoleManager" type="System.Web.Security.RoleManagerModule" />
    <remove name="UrlAuthorization" />
    <add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" />
  </modules>
</system.webServer>
7 голосов
/ 12 июля 2014

Приложение:

Как заметил @eych, это также блокирует доступ к папке ~/Content (или где у вас есть CSS), ~/Scripts и т. Д.

Если вы хотите разрешить исключения - то есть разрешить доступ к определенным файлам / папкам неаутентифицированным пользователям - вы можете сделать это с помощью элемента location. Добавьте следующее к web.config: 

  <location path="Content">
    <system.web>
      <authorization>
        <allow users="*" />
      </authorization>
    </system.web>
  </location>

Обновление: Лучшее решение - оставить доступ по умолчанию - что позволит получить доступ к вашему CSS / JavaScript / и т. Д. - и применить «блокировку» (только) к папке, где хранится статический контент: 

<location path="data">
  <system.web>
    <authorization>
      <deny users="?"/>
    </authorization>
  </system.web>
</location>

Предостережение: в нашем случае (сайт MVC) нам нужно было украсить все действия нашего контроллера (кроме входа в систему) с помощью [AuthorizeAttribute]. В любом случае, это хорошая идея, но ранее в этом не было необходимости (поскольку ранее любой несанкционированный запрос был перенаправлен на страницу входа).

1 голос
/ 03 февраля 2016

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

Сначала добавьте поставщика построения страницы в файл Web.config: 

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.web> 
    <compilation>
      <buildProviders>
        <add type="System.Web.Compilation.PageBuildProvider" extension=".html"/>
      </buildProviders>
    </compilation>
  </system.web> 
</configuration>

Затем добавьте фабрику обработчика страниц: 

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.web> 
    <httpHandlers>
      <add type="System.Web.UI.PageHandlerFactory" path="*.html" verb="*"/>
    </httpHandlers>
  </system.web> 
</configuration>

Затем добавьте обработчик страницы: 

<?xml version="1.0" encoding="UTF-8"?>
<configuration> 
  <system.webServer>
    <handlers>
      <add scriptProcessor="C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" requireAccess="Script" preCondition="classicMode,runtimeVersionv2.0,bitness32" path="*.html" verb="GET,HEAD,POST,DEBUG" modules="IsapiModule" name="HtmlHandler-Classic-32" />
      <add scriptProcessor="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" requireAccess="Script" preCondition="classicMode,runtimeVersionv2.0,bitness64" path="*.html" verb="GET,HEAD,POST,DEBUG" name="HtmlHandler-Classic-64"/>
    </handlers>
  </system.webServer>
</configuration>

Это сработало для меня. (Кредит: http://www.ifinity.com.au/Blog/EntryId/66/How-To-301-Redirect-htm-or-html-pages-to-DotNetNuke-aspx-pages.)

...