Chris, Thanks for looking into this situation. I agree with your ultimate conclusion of user/developer education. There is a strong push within security education programs to always treat user controlled data as dangerous until validated/encoded. We just need to remember in JSPs that anytime the request.getParameter() is used that it is possible, even if unintended, that user controlled data could enter into play.
Thanks! Michael On 9/16/10 11:33 AM, Christopher Schultz wrote: > Michael, > > On 9/15/2010 6:33 PM, Michael Coates wrote: > > On 9/15/10 2:46 PM, Christopher Schultz wrote: > >> > >> 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". > > > Yes, exactly. Well said. > > Glad we agree :) > > This is one of those definite "gotchas" in the servlet specification. In > re-reading the specs, it was unclear until a certain section whether the > <jsp:include> could be used to include arbitrary content from anywhere > (like http://www.google.com/). If the "include" instruction actually > makes a new http request (like I believe Apache httpd SSI's do), then > you are safe from the behavior you describe. It appears that this > features has been designed to only use resources that are local to the > webapp, and to actually be processed using the current request object. > > Unless you read the spec (or get a strong hint from being familiar with > the servlet API), this is behavior is definitely surprising. I usually > believe in the "principle of least surprise", but in this case, I'm not > sure there's anything to be done about it other than attempt to educate > users. > > -chris --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
