Hi
On 16 Oct 2004 at 14:27, V.Benjamin Livshits wrote:
I've been seeing a lot of redirects like the ones below in J2EE
programs.
1. response.sendRedirect(request.getParameter("REFERRER"));
If you really mean that there is a parameter named REFERRER (and not
the HTTP request header, which is, BTW, spelled "Referer" [sic!]),
then this is a classic example for the security vulnerability called
"HTTP Response Splitting" (see the paper "Divide and Conquer - HTTP
Response Splitting, Web Cache Poisoning Attacks, and Related Topics"
by yours truly at:
http://www.sanctuminc.com/pdf/WhitePaper_HTTPResponse.pdf).
One of the consequences of this vulnerability is indeed the ability
to run an XSS attack against IE in a redirection scenario, which is
exactly what you have here (it's all in the paper).
Note that without using HTTP Response Splitting, you stand a
challenge in doing XSS for IE in a redirection scenario, because IE
does not parse the 3xx response body - it follows the Location header
and ignores the body.
2. response.sendRedirect(request.getRequestURI());
3. response.sendRedirect(request.getServletPath() + toPath);
Again, if toPath uses user input (such as
toPath=getParameter("toPath")), then this may be vulnerable to HTTP
Response Splitting (see above).
Since the URL the user is being redirected to comes from the HTTP
header, I was wondering if forging parts of the header may lead to a
cross-site scripting exploit of some sort. Clearly, it would be
dangerous to use this data as part of SQL statements. However, I have
trouble imagining XSS exploit scenarios.
Thanks,
-Ben
