tag:blogger.com,1999:blog-13756280.post4590761507982491059..comments2024-02-08T03:44:23.780-08:00Comments on Jeremiah Grossman: HTTP Response Splitting RevelationsJeremiah Grossmanhttp://www.blogger.com/profile/05017778127841311186noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-13756280.post-14293011193607954552010-10-01T14:02:07.676-07:002010-10-01T14:02:07.676-07:00Thanks.
I have been looking for info on how to so...Thanks.<br /><br />I have been looking for info on how to solve a HTTP Response Splitting which I am having - and this has been very helpful.<br /><br />Much appreciated!Nikki Mayhttp://www.wordsofvalue.com/noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-33644419646144276292009-05-20T13:58:20.831-07:002009-05-20T13:58:20.831-07:00PHP versions 5.1.2 and later provide some protecti...PHP versions 5.1.2 and later provide some protection against this exploit by ensuring that the header() function can only output a single line.<br /><br />However, it is still a good idea to run any incoming data being used in a header through a regular expression, and to protect privacy by ensuring that any cookies set do not contain user data at all.Terence Johnsonhttp://www.scribendi.comnoreply@blogger.comtag:blogger.com,1999:blog-13756280.post-36339366098617511762007-07-17T15:11:00.000-07:002007-07-17T15:11:00.000-07:00Re: IIS 6So, the webserver itself I believe is sti...Re: IIS 6<BR/><BR/>So, the webserver itself I believe is still "vulnerable".<BR/><BR/>However, IIS 6 on Windows 2003 has two different checks and balances.<BR/><BR/>(1) URL-scan is built-in, which could easily strip out CRLFs from input, given the right encoding type.,<BR/><BR/>(2) the .NET Framework does not like CRLFs in user-supplied data and will throw an I/O expection IIRC which could easily translate into an error page.<BR/><BR/>We see this with previous versions of IIS, every version of Apache, and IBM's HTTP server (basically apache) I will research Microsoft-IIS/6.0 and see what I find.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-13756280.post-24369263744457699552007-07-13T12:17:00.000-07:002007-07-13T12:17:00.000-07:00Is there built in detection of this attack in IIS6...Is there built in detection of this attack in IIS6 now? I tried this on a vulnerable site and it threw an error stating that a malacious value was found in the cookie value(an IIS error page).<BR/><BR/>Thanks for the post btw, great stuff!navairumhttps://www.blogger.com/profile/17859228017181450980noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-55920429408465441942007-07-12T06:55:00.000-07:002007-07-12T06:55:00.000-07:00ChrisP, yes, that is one of the necessary pre-cond...ChrisP, yes, that is one of the necessary pre-conditions. The others have a lot to do with "exploitability". That's the paper Arian is working on with Amit.Jeremiah Grossmanhttps://www.blogger.com/profile/05017778127841311186noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-82282931340858043382007-07-12T02:01:00.000-07:002007-07-12T02:01:00.000-07:00I proposed it to the PHPIDS project last month. No...I proposed it to the PHPIDS project last month. Not only HTTP Response splitting which is actually still based upon a CRLF injection, but also Worm signatures which behave the same way but remotely activated or inserted.<BR/><BR/>it's actually one of those things that is forgotten by many, or many did not know about. I think one of the first things I learned was CRLF injection, changing or modifying HTTP1.1 to HTTP1.0, sending arbitrary headers. A lot of servers where vulnerable to some of the same attacks with a ton of nulls or spaces/slashes.<BR/><BR/>If I find the time I was planning to write some Apache rules for it, cause it mainly falls under server protection IMHO.<BR/><BR/>Regards,<BR/><BR/>0x000000Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-13756280.post-50495223593298002232007-07-12T00:41:00.000-07:002007-07-12T00:41:00.000-07:00Chrisp:Yes, the basic premise of HTTPRS is that th...Chrisp:<BR/><BR/>Yes, the basic premise of HTTPRS is that the HTTP headers are rewritten to create two responses where only one should be (there's then some jiggery-pokery to get the 2nd response - the "malicious" one - associated with a request of your choosing that is then cached).<BR/><BR/>The usual place to look for this are any user input that finds itself in HTTP headers - usually Location (for redirects) or Cookies, but it could appear in others (although in my experience not that likley).<BR/><BR/>A good resource to read some more is http://www.packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdfAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-13756280.post-87532152144431516172007-07-11T22:28:00.000-07:002007-07-11T22:28:00.000-07:00Would you say though that the minimum necessary co...Would you say though that the minimum necessary condition for a HRS vulnerability to exist, a web app has to take user input verbatim to later use it to create an HTTP header?Anonymousnoreply@blogger.com