Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Double EL expression evaluation in JSP MessageTag [SPR-5308] #9981

Closed
spring-projects-issues opened this issue Nov 18, 2008 · 1 comment
Closed
Assignees
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

Jarek Bojar opened SPR-5308 and commented

I think that, spring's MessageTag contains a fairly serious security vulnerability.
'Arguments' attribute is internally evaluated in MessageTag using ExpressionEvaluationUtils. If we are using JSP 2.0 then el expressions are potentially evaluated twice: first by JSP engine, second by MessageTag. This can lead to el expression injection (something similar to sql injection).
Consider the following example:

In message bundle we have message:
msg,welcome=Welcome {0} on our home page!

In JSP we use MessageTag to print this message with user name applied as argument:
<spring:message code="msg,welcome" arguments="${userBean.firstName}"/>

If malicious user supplies an el expressions instead of his first name, he can gain access to sensitive data.
For example, he can enter ${initParam.someParam} and gain access to init parameters defined in web.xml.
Through ${pageContext.servletContext.applicationContext} he can discover server type and some internal server configuration.
Potentially he can discover some other sensitive data accessible by EL expressions.
Additionally EL expressions are not escaped by spring's HtmlUtil.escapeHtml(...).

I think that there should be a way to completely disable EL expression evaluation in MessageTag, because it is not needed when using JSP 2.0 (with builtin el evaluation).


Referenced from: commits b8d8633, 62ccc8d, 9772eb8

1 votes, 2 watchers

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

Sorry, we completely forgot to update this issue back last year...

There is a web.xml init-param called "springJspExpressionSupport" now, which can be set to "false" in order to deactivate Spring's JSP expression support entirely. As of Spring Framework 3.1, when running on a Servlet 3.0 container, we automatically detect the need for Spring's JSP expression parsing depending on the declared Servlet version in web.xml (it'll be off by default for Servlet 2.4+ deployments, declaring the Servlet 2.4+ xsd in web.xml). And as of Spring Framework 3.2, Spring's own JSP expression mechanism is effectively deprecated and therefore off by default in all non-Servlet-3.0 scenarios as well.

Juergen

@spring-projects-issues spring-projects-issues added type: enhancement A general enhancement in: web Issues in web modules (web, webmvc, webflux, websocket) labels Jan 11, 2019
@spring-projects-issues spring-projects-issues added this to the 3.0.6 milestone Jan 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants