-----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
