2012-04-25 15 views

Respuesta

3

Verifique este aspecto Seguridad/Seguridad con Menudo evaluation of SpEL (google docs link) a la que probablemente hace referencia el artículo que enlaza (para el caso específico de SpEL).

Describen cómo ciertas etiquetas JSP de primavera evalúan dos veces expresiones EL. En estos casos, es posible que el usuario envíe datos al servidor en forma de SpEL, p. como un parámetro de petición con valor ${bean.val} (URL codificada)

http://...?exp=$%7Bbean.val%7D 

páginas interiores JSP, la expresión ${param.exp} se resolverán al texto ${bean.val} que por sí mismo es seguro. Sin embargo, si esa expresión reside dentro de un atributo de una etiqueta JSTL de primavera, ese valor resuelto se puede evaluar nuevamente, p. en el spring:message etiqueta:

<spring:message message="${param.exp}" /> 

resultará en el valor ${bean.val} ser pasado a través de la etiqueta spring:message que evaluará el método bean.getVal(). Por lo tanto, ahora tenemos un código enviado por el cliente y que se ejecuta en el servidor.

+1

por favor ver el mucho más alto vota respuesta a continuación, que es el real – blackdrag

+0

@blackdrag gracias, ya lo he leído. Tanto esta publicación como Pieter proporcionan dos respuestas diferentes a la pregunta original "¿Alguien puede arrojar más luz sobre esto, por favor?". Esta respuesta (casi hace un año ahora) con suerte proporciona algunos detalles sobre cuál era realmente la vulnerabilidad, mientras que la respuesta de Pieter describe el historial de SpringSources al tratar con él y las versiones de primavera en las que se resuelve este problema. OMI ambos "arrojan luz" de diferentes maneras y ambas son respuestas "reales". – krock

+0

Estoy de acuerdo, ambos arrojaron luz sobre el tema.Solo que está corregido desde antes de 2012. Falta la información más valiosa de que el informe ya estaba desactualizado en el momento en que se solicitó. Es por eso que ya no considero la respuesta como "real". – blackdrag

27

El descubrimiento de Aspect Security se encontró en enero de 2013, pero la solución que publicó SpringSource se puso a disposición en 2011 cuando se descubrió por primera vez. Dan Amodio de Aspect Security informó a SpringSource sobre la posibilidad de ejecución remota de código.

SpringSource actualiza nuestro informe de seguridad 12-06-2012 de la constatación de Aspecto de Seguridad - pero la solución/mitigación que aparece en el aviso original sigue siendo aplicable: http://support.springsource.com/security/cve-2011-2730

Esta vulnerabilidad sólo afecta a las versiones de Spring Framework:

• 3.0.0 a 3.0.5 - la actualización a 3.0.6 aquí resolvería el problema. • 2.5.0 a 2.5.6.SEC02 (versiones de la comunidad): la actualización a 2.5.6.SEC03 aquí resolvería el problema. • 2.5.0 a 2.5.7.SR01 (clientes de suscripción): la actualización a 2.5.7.SR02 aquí resolvería el problema.

Esto se ha corregido en todas las versiones de cara al futuro - la versión actual de Spring Framework es 3.2, lanzado en diciembre de 2012.

Gracias,

-Pieter (SpringSource)

Cuestiones relacionadas