DO NOT REPLY [Bug 8005] New: - Bad Param passing with jsp:include

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8005>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8005

Bad Param passing with jsp:include

           Summary: Bad Param passing with jsp:include
           Product: Tomcat 4
           Version: 4.0.2 Final
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: Major
          Priority: Other
         Component: Servlet & JSP API
        AssignedTo: [EMAIL PROTECTED]
        ReportedBy: [EMAIL PROTECTED]


Consider:

<jsp:include page="header.jsp" flush="true">
<jsp:param name="title" value="<%= title %>" />
</jsp:include>

If title is "Tom & Jerry" it will not be passed correctly to the header.jsp.
Looking at the tmp java file that this jsp is converted into before being
compilied, I see something like:

{
String _jspx_qStr = "";
_jspx_qStr = _jspx_qStr + "?title=" +  title ;
JspRuntimeLibrary.include(request, response, "header.jsp" + _jspx_qStr, out, true); 
}

The problem should be obvious now. Parameter values are _not_ being encoded
before constructing the query string to be passed to the included jsp. This
means that any value containing an ampersand will get mangled.

Also, from what I can tell, the same problem applies if the parameter value is
hardcoded. i.e.

<jsp:include page="header.jsp" flush="true">
<jsp:param name="title" value="Tom &amp; Jerry" />
</jsp:include>

The JSP 1.2 spec claims that these "Standard Actions" are XML. Which means that
"Tom &amp; Jerry" should be legal.  The spec has little to say about encoding
for parameters specified as expressions though. Also, if this case I would
expect "Tom & Jerry" to be received by the called jsp. i.e. the parser should
see "Tom &amp; Jerry" and decode it to unicode (whatever) and pass that.

There is a also a security aspect to this bug. If an attacker can control a 
parameter value that is explicitly passed by a jsp to another jsp, they would be
able to override any request parameters that may have been added directly by the
appliction. (i.e. request parameters added to the request object via jsp:include
calls, not request parameters submitted as part of a HTTP POST/GET operation).
Just ask if you need more explaination.

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>