-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael,
On 9/15/2010 3:05 PM, Michael Coates wrote: > http://michael-coates.blogspot.com/2010/09/danger-of-jsp-includes-and-parameter.html Can I ask this stupid question: why are you grabbing data from the request using a variable parameter name? (From your article, not from your message, since there wasn't enough in your OP): WEB-INF/preContet.jsp <div id="lessonTitle"> <b>Lesson:</b><br/> <%=request.getParameter(lessonName)%><br /> <b>Objective:</b><br/> <%=request.getParameter(lessonObjective)%> </div> Where is the "lessonObjective" variable defined? Is that something you chose not to show in your post, or is that a typo that you're missing quotes around the word "lessonObjective"? > Clearly we could perform output encoding within preContent.jsp; however, > if the application never intended for lessonName to be a user controlled > piece of data, then this is an unexpected and dangerous behavior. This is the general rule when XSS is in question: always escape. If you don't want your web application to be vulnerable to XSS attacks, you'll have to be careful. I think what you're really trying to say is "it's easy to overlook the fact that <jsp:include> uses URL parameters to pass data, and that an include inherits the original request, so URL parameter data goes right through". > It seems to me that the method used to request parameters from an > included jsp file should not "fail over" to the URL if the jsp:include > does not provide the parameter. There is no "fail over": the included JSP actually gets both parameters - -- you are just ignoring one of them by calling request.getParameter() instead of request.getParameterValues(). Read section SRV.8.3 of the servlet spec (v2.5) (emphasis mine): " The include method of the RequestDispatcher interface may be called at any time. *The target servlet of the include method has access to all aspects of the request object*, but its use of the response object is more limited. [...] " "all aspects of the request object" includes the request parameters, whether they are GET or POST, or some from the client/user or from the including page. The JSP specification (v2.1) says this about <jsp:include> in section JSP.5.4 (emphasis mine): " The first syntax just does a request-time inclusion. In the second case, the values in the param subelements are used to *augment* the request for the purposes of the inclusion. " Note the use of the word "augment" to imply that the original request information is available to the included JSP. I found this while reading the spec for you in SRV.8.1.1: " Parameters specified in the query string used to create the RequestDispatcher take precedence over other parameters of the same name passed to the included servlet. The parameters associated with a RequestDispatcher are scoped to applyonly for the duration of the include or forward call. " I haven't tested this, but it seems to indicate that the including JSP can "hide" the original parameters from the included JSP, so my statement above about having multiple "lessonObjective" parameters available to the included page might not be accurate. So, all I've done here is show you that this is all very spec-compliant. I haven't really said anything about "danger". Yes, this is dangerous to naive developers, and it also seems relatively easy to make a mistake as you have pointed out. Might I suggest another approach? Instead of doing an "include", try doing an "import". The import occurs before compilation, and therefore can force the enclosing JSP to define certain variables -- and then use them directly, rather than using URL parameters to pass data around. This also solves a perennial problem that readers of this list may recognize: GET parameters are often fraught with difficulty when the character encoding is taken into account: using non-numeric URL parameters can drive you insane. There's another technique you can use, too: you can use request attributes instead of parameters. This offers the same "protection" in that the client cannot somehow override the code and/or take advantage of a poorly-written JSP to force some non-validated data onto the page. I agree with Mikolaj's comment about never being able to trust data coming from request parameters. Hope that helps, - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyRPtMACgkQ9CaO5/Lv0PALpQCfXY8aySD2l60rGG8qtkfJTIC2 A9AAnjeUXUsH1q9KgrvBO37TK2uIUH1t =AzBx -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
