Uploaded image for project: 'Spring Framework'
  1. Spring Framework
  2. SPR-5308

Double EL expression evaluation in JSP MessageTag

    Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Major
    • Resolution: Complete
    • Affects Version/s: None
    • Fix Version/s: 3.0.6, 3.1 RC1
    • Component/s: Web
    • Labels:
      None
    • Last commented by a User:
      false

      Description

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

        Activity

        Hide
        juergen.hoeller Juergen Hoeller added a comment -

        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

        Show
        juergen.hoeller Juergen Hoeller added a comment - 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

          People

          • Assignee:
            juergen.hoeller Juergen Hoeller
            Reporter:
            jbojar Jarek Bojar
            Last updater:
            Juergen Hoeller
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Days since last comment:
              4 years, 44 weeks, 4 days ago