java - que - tomcat 6

Tomcat que sirve contenido estático

Question

Tengo una aplicación de Spring y me pregunto cuál es la mejor manera de ofrecer contenido estático. He probado lo siguiente:

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

Esto funciona, pero el comportamiento del DefaultServlet significa que cualquier solicitud de la forma /static/PATH sirve el archivo desde webapp/PATH . Esto expone una vulnerabilidad masiva, permitiendo que la información confidencial se muestre con URL como: http: //localhost/app/static/META-INF/context.xml

¿Cuál es la solución común para esto? ¿Debo mover los archivos confidenciales? ¿Escribir mi propio DefaultServlet? ¿O hay una mejor manera de servir contenido estático?

Answer 1

Hay varias formas mejores de servir contenido estático.

El enfoque tradicional era usar un UrlRewriteFilter para reasignar las URL de la siguiente manera:

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>

Este enfoque se puede ver en la mayoría de las muestras de primavera.

Spring 3.0.1 introdujo una nueva versión : puede servir contenido estático a través de DispatcherServlet . Se puede configurar usando el elemento <mvc:resource> en el archivo de configuración de Spring. En Spring 3.0.4 se amplió con soporte para múltiples ubicaciones y opciones de control de caché, consulte 15.12.4 mvc: resources .

Answer 2

WEB-INF y META-INF son carpetas privadas. El cliente debe obtener un error 404 para esto. Como el contenido de META_INF no se puede acceder directamente. De lo WEB_INF mueva todos los archivos confidenciales en WEB_INF .

Answer 3

¿Lo has probado? Se supone que las carpetas /META-INF y /WEB-INF son públicamente inaccesibles según la especificación del servlet. El cliente debería haber obtenido un 404 para esto. De lo contrario, habría sido un error en DefaultServlet .

Aquí hay un extracto de la especificación de Servlet 2.5 :

Estructura de directorio SRV.9.5

... Además, cualquier solicitud del cliente para acceder a los recursos en el directorio WEB-INF/ debe devolverse con una SC_NOT_FOUND(404) .

y

Archivo de Archivo de la Aplicación Web SRV.9.6

... Además, cualquier solicitud para acceder a los recursos en el directorio META-INF debe devolverse con una SC_NOT_FOUND(404) .

Actualización : OK, recupero mis palabras. Puedo reproducir esto en los últimos Tomcat 6 y 7. Definitivamente es un error en DefaultServlet . Funciona bien (devuelve 404) en Glassfish 3.0.1.

Actualización 2: He informado esto a los chicos de Tomcat como el número 50026 .

Actualización 3: uno de los chicos de Tomcat respondió como:

Estoy pensando que esto es un WONTFIX .

El motor de servlet protege las rutas WEB-INF y META-INF en la aplicación web (que funciona bien), no los archivos de ese nombre en rutas arbitrarias.

Lo que está sucediendo aquí es que está configurando un servlet de servicio de archivos de propósito general para montar toda su aplicación web en una ruta diferente; es equivalente a configurar Apache para que haga lo mismo. Excepto que DefaultServlet no es un servidor de archivos de propósito general: está diseñado para ser asignado a / y no se puede configurar para hacer nada más que servir archivos fuera del directorio de la aplicación web.

Supongo que estás tratando de solucionar un problema introducido asignando otro servlet a /* , que básicamente está tratando de evitar el funcionamiento de un motor de servlet. Cómo acceder a los recursos estáticos al mapear un servlet de control frontal global en / * tiene un ejemplo de una mejor manera de abordar las cosas si esto es lo que estás tratando de hacer.

Los consejos para volver a montar DefaultServlet en Tomcat parecen haber existido mientras Tomcat haya existido, por lo que quizás necesitemos bloquearlo (para que la gente no pueda crear accidentalmente configuraciones inseguras) o permitir el montaje de directorios específicos (dentro o fuera de la aplicación web) , y romper si tiene acceso a los recursos de la raíz cuando se asigna a una sub-ruta en cualquier caso.

Actualización 4: finalmente lo arreglaron:

Las correcciones para DefaultServlet y WebdavServlet están comprometidas para 7.0.x (estarán en 7.0.4+) y propuestas para 6.0.x. Tendrá que verificar 5.5.x y ver si también se requiere un backport para eso.