Tomcat, обслуживающий статический контент

У меня есть приложение Spring, и мне интересно, как лучше обслуживать статический контент. Я пробовал следующее:

<servlet-mapping>
    <servlet-name>default</servlet-name>
    <url-pattern>/static/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
    <servlet-name>app</servlet-name>
    <url-pattern>/</url-pattern>
</servlet-mapping>

Это работает, но поведение DefaultServlet означает, что любой запрос формы/static/PATH служит файл изwebapp/PATH, Это предоставляет огромную уязвимость, позволяющую показывать конфиденциальную информацию с помощью таких URL-адресов, как:Http: //localhost/app/static/META-INF/context.xml

Какое общее решение для этого? Должен ли я переместить конфиденциальные файлы? Написать свой собственный DefaultServlet? Или есть лучший способ обслуживания статического контента?

 Ring Ø29 сент. 2010 г., 16:40
У вас нет проблем в вашемcontext, например docBase?

Ответы на вопрос(3)

WEB-INF а такжеMETA-INF это личные папки. Клиент должен получить ошибку 404 для этого. КакMETA_INF содержимое не доступно напрямую. В противном случае переместите все конфиденциальные файлы вWEB_INF.

 BalusC29 сент. 2010 г., 16:55
Это дублированный ответ.
 Steve29 сент. 2010 г., 16:48
Я тоже вижу внутри WEB-INF
Решение Вопроса

Есть несколько лучших способов обслуживания статического контента.

Традиционный подход должен был использоватьUrlRewriteFilter переназначить URL-адреса следующим образом:

web.xml:

<filter>
    <filter-name>UrlRewriteFilter</filter-name>
    <filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
</filter>
<filter-mapping>
    <filter-name>UrlRewriteFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>
...
<servlet-mapping>
    <servlet-name>Spring MVC Dispatcher Servlet</servlet-name>
    <url-pattern>/app/*</url-pattern>
</servlet-mapping>

urlrewrite.xml:

<urlrewrite default-match-type="wildcard">
    <rule>
        <from>/images/**</from>
        <to>/images/$1</to>
    </rule>
    <rule>
        <from>/scripts/**</from>
        <to>/scripts/$1</to>
    </rule>
    <rule>
        <from>/styles/**</from>
        <to>/styles/$1</to>
    </rule>
    <rule>
        <from>/**</from>
        <to>/app/$1</to>
    </rule>
</urlrewrite>

Такой подход можно увидеть в большинстве весенних образцов.

Spring 3.0.1 представленновое приложение - он может обслуживать статический контент черезDispatcherServlet, Это можно настроить с помощью<mvc:resource> элемент в конфигурационном файле Spring. В Spring 3.0.4 он был расширен за счет поддержки нескольких параметров управления местоположением и кэшем, см.15.12.4 MVC: ресурсы.

 Bozho26 окт. 2010 г., 19:41
+1 за<mvc:resource>
 Juan Calero11 июл. 2012 г., 19:04
По моему опыту, Spring 3.0.4 необходим для распознавания<mvc:resource> тег (не 3.0.1)
 axtavt29 сент. 2010 г., 17:34
@BalusC: оба описанных подхода решают эту проблему - первый путем переназначения/* в/app/* с явными исключениями, последнее - путем подачи статического контента черезDispatcherServlet сопоставлены с/.

Вы проверяли это?/META-INF а также/WEB-INF папки должны быть общедоступныминедоступный согласно спецификации сервлета. Клиент должен был получить 404 за это. В противном случае это было бы ошибкой вDefaultServlet.

Вот выдержка изСервлет 2.5 спец:

SRV.9.5 Структура каталогов

... Кроме того, любые запросы от клиента для доступа к ресурсам вWEB-INF/ каталог должен быть возвращен сSC_NOT_FOUND(404) ответ.

а также

Файл архива веб-приложения SRV.9.6

... Также любые запросы на доступ к ресурсам вMETA-INF каталог должен быть возвращен сSC_NOT_FOUND(404) ответ.

ОбновитьХорошо, я беру свои слова обратно. Я могу воспроизвести это на последних Tomcat 6 и 7. Это определенно ошибка вDefaultServlet, Он работает нормально (возвращает 404) на Glassfish 3.0.1.

Обновление 2: Я сообщил об этом ребятам из Tomcat каквыпуск 50026.

Обновление 3: один из парней из Tomcat ответил так:

Я думаю, что этоWONTFIX.

Двигатель сервлета защищаетWEB-INF а такжеMETA-INF пути в веб-приложении (которое работает нормально), а не файлы с таким именем по произвольным путям.

На самом деле происходит то, что вы настраиваете сервлет, обслуживающий файлы общего назначения, для монтирования всего веб-приложения по другому пути - это эквивалентно настройке Apache для выполнения той же задачи. За исключением того, что DefaultServlet не является файловым сервером общего назначения - он предназначен для отображения на/и вы не можете настроить его на выполнение каких-либо действий, кроме предоставления файлов из каталога веб-приложения.

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

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

Обновление 4: они в конечном счете исправили это:

Исправления для DefaultServlet и WebdavServlet зафиксированы для 7.0.x (будет в 7.0.4+) и предложены для 6.0.x. Нужно будет проверить 5.5.x и посмотреть, нужен ли для этого бэкпорт.

 BalusC29 сент. 2010 г., 17:14
Я беру свои слова обратно, я могу воспроизвести это. Это удивительно.
 Steve29 сент. 2010 г., 17:08
Только что получил новый Tomcat 6, новый Dynamic Web Project в затмении и добавил следующееweb.xml и я могу получить доступ к META-INF: <servlet-mapping> <servlet-name> default </ servlet-name> <url-pattern> / static / * </ url-pattern> </ servlet-mapping>
 eis04 окт. 2012 г., 10:23
+1 за то, что действительно прошел весь путь и исправил
 Steve29 сент. 2010 г., 16:47
Я проверил это, и я ясно вижу свой context.xml с паролями моей базы данных внутри.
 BalusC29 сент. 2010 г., 16:54
Либо вы разместилиWEB-INF а такжеMETA-INF папки в неправильном месте (они должны быть помещены в корень веб-контента, а не в какую-то подпапку, например/static), или есть ошибка в используемой версии Tomcat.
 axtavt29 сент. 2010 г., 17:07
Tomcat 6 на самом деле работает так. Даже Spring's Petclinic образец уязвимsrc.springframework.org/svn/spring-samples/petclinic/trunk Вау просто вау.

Ваш ответ на вопрос