Re: [OT] Protecting against HTTP response splitting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Konstantin, On 4/20/2011 11:56 AM, Konstantin Kolinko wrote: 2011/4/20 Christopher Schultz ch...@christopherschultz.net: I was considering scouring the URL/URI specs for exactly what characters are allowed but then decided that I didn't really care: I was mostly concerned with thwarting a response-splitting attack and avoiding \r and \n does that. See HTTP spec on what is allowed in headers. It's in the RFC 822, ARPA Internet Text Messages, not the HTTP spec. This isn't intended to be an outgoing HTTP header value validator. Technically, this is over-engineered because it looks for /either/ \r /or/ \n, rather than \r\n which should be the only way to exploit such a vulnerability. :) You are wrong. This way is not the only one. I suppose my implementation may be both simplistic and draconian. For example, a header value such as This isCRLF my value is perfectly valid and does not represent a response-splitting attack, though it would trigger an error from my filter. Also, header values are allowed to contain CRs and LFs, just not next to each other. I'm okay with violating both of these provisions since my application doesn't make use of them. I'm interested in where you see another opportunity to split an HTTP response using HTTP headers. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2wNrcACgkQ9CaO5/Lv0PBblgCePNngKWEhiCemVvnDMj+TR1WN 1tkAnRroXgx6KFVIkyEY2DkbaSX/DecT =0RHt -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Protecting against HTTP response splitting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Konstantin, On 4/19/2011 4:37 AM, Konstantin Kolinko wrote: 2011/4/19 Christopher Schultz ch...@christopherschultz.net: Looks like I must override sendRedirect because otherwise the setHeader call implemented in Response.sendRedirect isn't intercepted by the wrapper class. For those interested, see below for the implementation I came up with. if(containsCRorLF(value)) throw new IllegalArgumentException(Header value must not contain CR or LF characters); It would be better to check that all characters are correct ones rather than check for two specific incorrect characters. Checking for \r \n only might be not enough. Though that depends on where the value comes from. I was considering scouring the URL/URI specs for exactly what characters are allowed but then decided that I didn't really care: I was mostly concerned with thwarting a response-splitting attack and avoiding \r and \n does that. This isn't intended to be an outgoing HTTP header value validator. Technically, this is over-engineered because it looks for /either/ \r /or/ \n, rather than \r\n which should be the only way to exploit such a vulnerability. :) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2u6U0ACgkQ9CaO5/Lv0PCvdACgjm/Q/3IrBC318Bb0wi+WDjee v78AoLjj9uj6mDiRWik8WV/3pQWqDXiB =IgDT -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Protecting against HTTP response splitting
2011/4/20 Christopher Schultz ch...@christopherschultz.net: I was considering scouring the URL/URI specs for exactly what characters are allowed but then decided that I didn't really care: I was mostly concerned with thwarting a response-splitting attack and avoiding \r and \n does that. See HTTP spec on what is allowed in headers. This isn't intended to be an outgoing HTTP header value validator. Technically, this is over-engineered because it looks for /either/ \r /or/ \n, rather than \r\n which should be the only way to exploit such a vulnerability. :) You are wrong. This way is not the only one. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Protecting against HTTP response splitting
2011/4/19 Christopher Schultz ch...@christopherschultz.net: Looks like I must override sendRedirect because otherwise the setHeader call implemented in Response.sendRedirect isn't intercepted by the wrapper class. For those interested, see below for the implementation I came up with. if(containsCRorLF(value)) throw new IllegalArgumentException(Header value must not contain CR or LF characters); It would be better to check that all characters are correct ones rather than check for two specific incorrect characters. Checking for \r \n only might be not enough. Though that depends on where the value comes from. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Protecting against HTTP response splitting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sebb, Just saw your response from a few weeks back... (and responded directly instead of to the list.. it's been a long day). On 4/1/2011 6:16 PM, sebb wrote: I may be missing something here, but can't you use the ctor: URL(URL context, String spec) and pass in a dummy context with a suitable protocol? Maybe. The URL may or may not be fully-qualified, relative, etc. I'm leaning more towards just protecting against control characters in a header: there's no need to do a complete URL-parse to check for response splitting. A simple filter that wraps the response and overrides either sendRedirect or setHeader(String, String) should do it. I'd have to check to see how the two interact... whether calling sendRedirect on a wrapped response will also set the header on the wrapped response or set the header at a higher level where the wrapper won't get called. I'll post whatever I come up with. Thanks, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2s6o8ACgkQ9CaO5/Lv0PDikgCgtGkHVIGl1mJwIAXBiQ4V0qq8 auUAoIoIrsaH8LHn+U/pEVbFQK09y71D =AMLs -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Protecting against HTTP response splitting
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
All,
On 4/18/2011 9:51 PM, Christopher Schultz wrote:
I'm leaning more towards just protecting against control characters in a
header: there's no need to do a complete URL-parse to check for response
splitting.
A simple filter that wraps the response and overrides either
sendRedirect or setHeader(String, String) should do it.
I'd have to check to see how the two interact... whether calling
sendRedirect on a wrapped response will also set the header on the
wrapped response or set the header at a higher level where the wrapper
won't get called.
Looks like I must override sendRedirect because otherwise the setHeader
call implemented in Response.sendRedirect isn't intercepted by the
wrapper class.
For those interested, see below for the implementation I came up with.
Enjoy,
- -chris
import java.io.IOException;
import java.net.MalformedURLException;
import javax.servlet.Filter;
import javax.servlet.FilterConfig;
import javax.servlet.FilterChain;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpServletResponseWrapper;
/**
* Prevents the application from setting HTTP headers that include
* CR or LF characters. Specifically throws a MalformedURLException
* for the sendRedirect method which is already declared to throw
* IOException.
*/
public class HttpResponseSplittingPreventionFilter
implements Filter
{
public void init(FilterConfig config)
{
}
/**
* Performs the filtering operation provided by this filter.
*
* @param request The request being made to the server.
* @param response The response object prepared for the client.
* @param chain The chain of filters providing request services.
*/
public void doFilter(ServletRequest request,
ServletResponse response,
FilterChain chain)
throws IOException, ServletException
{
if(response instanceof HttpServletResponse)
response = new Wrapper((HttpServletResponse)response);
chain.doFilter(request, response);
}
/**
* Called by the servlet container to indicate that a filter is being
* taken out of service.p
*/
public void destroy()
{
}
class Wrapper
extends HttpServletResponseWrapper
{
Wrapper(HttpServletResponse response)
{
super(response);
}
public void sendRedirect(String location)
throws IOException
{
if(containsCRorLF(location))
throw new MalformedURLException(CR or LF detected in
redirect URL: possible http response splitting attack);
super.sendRedirect(location);
}
public void setHeader(String name, String value)
{
if(containsCRorLF(value))
throw new IllegalArgumentException(Header value must
not contain CR or LF characters);
super.setHeader(name, value);
}
public void addHeader(String name, String value)
{
if(containsCRorLF(value))
throw new IllegalArgumentException(Header value must
not contain CR or LF characters);
super.addHeader(name, value);
}
private boolean containsCRorLF(String s)
{
if(null == s) return false;
int length = s.length();
for(int i=0; ilength; ++i)
{
char c = s.charAt(i);
if('\n' == c
|| '\r' == c)
return true;
}
return false;
}
}
}
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk2s66gACgkQ9CaO5/Lv0PDcSgCfbJnJkhqAYeZ/i7TgdGqX9adr
BZ4An1G8gf8EAdV6ywyo0b7c6PWqg+AD
=9kiL
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Protecting against HTTP response splitting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ronald, On 3/31/2011 8:21 PM, Christopher Schultz wrote: On 3/31/2011 7:05 AM, Ronald Klop wrote: I would say that some proper input validation solves your problem. Does new URL(redirectURL).toString() give an exception on invalid url's? new URL(String) will throw a MalformedURLException if there are illegal characters in the URL. I suppose that's good enough for my purposes: the only returnURLs that should be generated should be coming from our own application, and if they are broken, it's a bug. If a MalformedURLException is thrown, it should be due to some sort of malicious use and the user is better off getting a nasty error than just about anything else. Apparently, it's more complicated than that... at least when it comes to my particular application... we want to keep the URLs as short as possible, they they are not fully-qualified in most cases. Instead, they are webapp-relative and blindly passing them into the java.net.URL constructor fails even for real URLs because they have no protocol. Now, I could add code to fully-qualify them, but then I'd be doing work I'm already asking the container to do for me (since HttpServletResponse.sendRedirect is required to fully-qualify the URL anyway) and I'd prefer to rely on the container for that task -- it's likely to do a better job, anyway :) I think I'm doing to standardize on simply scanning for troublesome characters like \r and \n and throwing a MalformedURLException or something like that. If anyone else has any good ideas or Warnings about what might be a naive sanitization check, I'd be glad to hear them. Thanks, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2V5gsACgkQ9CaO5/Lv0PBgfwCeOrioFeSvp8iUJ51a9qJqAny3 8QkAn0c12aRinn7eoGUoAgA2uYydVQA/ =bwLF -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Protecting against HTTP response splitting
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Leon,
On 4/1/2011 1:49 AM, Leon Rosenberg wrote:
On Fri, Apr 1, 2011 at 2:21 AM, Christopher Schultz
ch...@christopherschultz.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ronald,
On 3/31/2011 7:05 AM, Ronald Klop wrote:
I would say that some proper input validation solves your problem.
Does new URL(redirectURL).toString() give an exception on invalid url's?
new URL(String) will throw a MalformedURLException if there are illegal
characters in the URL.
This will work for 'correct urls', however, you don't necessary need
to send correct urls, and I suppose you don't want to:
Consider this, struts1 like action:
public ActionForward execute(ActionMapping mapping, FormBean bean,
HttpServletRequest req, HttpServletResponse res) throws Exception {
//do something useful
res.sendRedirect(pageResult?page=1);
return null;
}
This is not a syntactically correct url, but it will work in all
browsers and save you a lot of stress in multi-url (i18n) portals.
I would solve your problem by having multiple entry points for the
actions which than can specify the final redirect path.
Yeah, I was thinking about this, too... instead of passing the actual
URL, just have a list of predefined URLs like home or display or
whatever and then just pass-around a symbolic name... that way, the
worst a malicious user can do is get the wrong name and go to a
different part of the webapp... instead of being able to redirect to
evilsite.com.
That requires more work, of course, and may be the ultimate solution we
choose... but it's not going to work for some particular actions because
they really can be redirected to an arbitrary location within our
webapp, and enumerating those would not really be possible.
Thanks,
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk2V5sAACgkQ9CaO5/Lv0PA7cgCglfyxvxL2wzNeTJIOiWsmrCqA
CV4AoLgdmc3bG5I19J2tf9BLDxXme1Sh
=iQAo
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Protecting against HTTP response splitting
2011/4/1 Christopher Schultz ch...@christopherschultz.net: I think I'm doing to standardize on simply scanning for troublesome characters like \r and \n and throwing a MalformedURLException or something like that. You'd better scan for allowed characters. The \r and \n are not the only ones where the things may go wrong. If anyone else has any good ideas or Warnings about what might be a naive sanitization check, I'd be glad to hear them. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Protecting against HTTP response splitting
On 1 April 2011 15:49, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ronald, On 3/31/2011 8:21 PM, Christopher Schultz wrote: On 3/31/2011 7:05 AM, Ronald Klop wrote: I would say that some proper input validation solves your problem. Does new URL(redirectURL).toString() give an exception on invalid url's? new URL(String) will throw a MalformedURLException if there are illegal characters in the URL. I suppose that's good enough for my purposes: the only returnURLs that should be generated should be coming from our own application, and if they are broken, it's a bug. If a MalformedURLException is thrown, it should be due to some sort of malicious use and the user is better off getting a nasty error than just about anything else. Apparently, it's more complicated than that... at least when it comes to my particular application... we want to keep the URLs as short as possible, they they are not fully-qualified in most cases. Instead, they are webapp-relative and blindly passing them into the java.net.URL constructor fails even for real URLs because they have no protocol. I may be missing something here, but can't you use the ctor: URL(URL context, String spec) and pass in a dummy context with a suitable protocol? Now, I could add code to fully-qualify them, but then I'd be doing work I'm already asking the container to do for me (since HttpServletResponse.sendRedirect is required to fully-qualify the URL anyway) and I'd prefer to rely on the container for that task -- it's likely to do a better job, anyway :) I think I'm doing to standardize on simply scanning for troublesome characters like \r and \n and throwing a MalformedURLException or something like that. If anyone else has any good ideas or Warnings about what might be a naive sanitization check, I'd be glad to hear them. Thanks, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2V5gsACgkQ9CaO5/Lv0PBgfwCeOrioFeSvp8iUJ51a9qJqAny3 8QkAn0c12aRinn7eoGUoAgA2uYydVQA/ =bwLF -END PGP SIGNATURE- - 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
Re: [OT] Protecting against HTTP response splitting
Op woensdag, 30 maart 2011 22:12 schreef Christopher Schultz ch...@christopherschultz.net: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, I was playing around with findbugs today and saw a security warning I've never seen before: HTTP parameter directly written to HTTP header output in [somefile.java]. I read a bit more into it and the warning was correct, I was doing something akin to the following: response.sendRedirect(request.getParameter(returnURL)); Aside from not running the redirect through response.encodeRedirectURL, there's another potential problem, there: the user can specify a return URL that breaks the HTTP response and can do some evil things. I verified that I can break my own response in this way by adding %0d%0a and then more stuff to my returnURL parameter and I magically escaped the Location header of the response. The suggested mitigation is to URL-encode the value before putting it into the header. I was wondering if anyone was doing anything like this and has a suggestion for allowing the UI to control it's own return to URLs in a safe way. We'd like to use returnURL values that allow for query parameters to be passed-back to the target URL so we can't just blindly URL-encode the URL otherwise those parameters will become part of the URL and not the query string. I suppose I could also just look for and replace whitespace, which is not legal in a URL anyway. Any other thoughts of suggestions? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2TjpgACgkQ9CaO5/Lv0PDAwQCfa8sSdRzAE7ZNjv0P1s/qD95L FGEAnjA8ZbobU/8s90lE2huLx/+B2smV =vJ6w -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org I would say that some proper input validation solves your problem. Does new URL(redirectURL).toString() give an exception on invalid url's? Ronald.
Re: [OT] Protecting against HTTP response splitting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ronald, On 3/31/2011 7:05 AM, Ronald Klop wrote: Op woensdag, 30 maart 2011 22:12 schreef Christopher Schultz response.sendRedirect(request.getParameter(returnURL)); Aside from not running the redirect through response.encodeRedirectURL, there's another potential problem, there: the user can specify a return URL that breaks the HTTP response and can do some evil things. I verified that I can break my own response in this way by adding %0d%0a and then more stuff to my returnURL parameter and I magically escaped the Location header of the response. I would say that some proper input validation solves your problem. Does new URL(redirectURL).toString() give an exception on invalid url's? I hadn't thought of using the URL class... I'll check that out and let you know. Thanks, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2UjbsACgkQ9CaO5/Lv0PBE7QCfV77tnlhrugrclpMnbCcgtXXf NkQAmwSVAposD625LWo253f6Au3rxaKr =tOxL -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Protecting against HTTP response splitting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ronald, On 3/31/2011 7:05 AM, Ronald Klop wrote: I would say that some proper input validation solves your problem. Does new URL(redirectURL).toString() give an exception on invalid url's? new URL(String) will throw a MalformedURLException if there are illegal characters in the URL. I suppose that's good enough for my purposes: the only returnURLs that should be generated should be coming from our own application, and if they are broken, it's a bug. If a MalformedURLException is thrown, it should be due to some sort of malicious use and the user is better off getting a nasty error than just about anything else. Thanks, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2VGn4ACgkQ9CaO5/Lv0PBk5gCdF5DMiC7/BrXTxDHayWzChU9W Dc8AoKq1E+6Y2NVTbTuS0vn1NtMhzo0C =2Kss -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Protecting against HTTP response splitting
On Fri, Apr 1, 2011 at 2:21 AM, Christopher Schultz
ch...@christopherschultz.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ronald,
On 3/31/2011 7:05 AM, Ronald Klop wrote:
I would say that some proper input validation solves your problem.
Does new URL(redirectURL).toString() give an exception on invalid url's?
new URL(String) will throw a MalformedURLException if there are illegal
characters in the URL.
This will work for 'correct urls', however, you don't necessary need
to send correct urls, and I suppose you don't want to:
Consider this, struts1 like action:
public ActionForward execute(ActionMapping mapping, FormBean bean,
HttpServletRequest req, HttpServletResponse res) throws Exception {
//do something useful
res.sendRedirect(pageResult?page=1);
return null;
}
This is not a syntactically correct url, but it will work in all
browsers and save you a lot of stress in multi-url (i18n) portals.
I would solve your problem by having multiple entry points for the
actions which than can specify the final redirect path.
regards
Leon
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
[OT] Protecting against HTTP response splitting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, I was playing around with findbugs today and saw a security warning I've never seen before: HTTP parameter directly written to HTTP header output in [somefile.java]. I read a bit more into it and the warning was correct, I was doing something akin to the following: response.sendRedirect(request.getParameter(returnURL)); Aside from not running the redirect through response.encodeRedirectURL, there's another potential problem, there: the user can specify a return URL that breaks the HTTP response and can do some evil things. I verified that I can break my own response in this way by adding %0d%0a and then more stuff to my returnURL parameter and I magically escaped the Location header of the response. The suggested mitigation is to URL-encode the value before putting it into the header. I was wondering if anyone was doing anything like this and has a suggestion for allowing the UI to control it's own return to URLs in a safe way. We'd like to use returnURL values that allow for query parameters to be passed-back to the target URL so we can't just blindly URL-encode the URL otherwise those parameters will become part of the URL and not the query string. I suppose I could also just look for and replace whitespace, which is not legal in a URL anyway. Any other thoughts of suggestions? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2TjpgACgkQ9CaO5/Lv0PDAwQCfa8sSdRzAE7ZNjv0P1s/qD95L FGEAnjA8ZbobU/8s90lE2huLx/+B2smV =vJ6w -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
