- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 19 Jul 2011 23:01:13 +1000
- To: Chris Weber <chris@lookout.net>
- Cc: Amit Klein <aksecurity@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>, Henrik Nordström <henrik@henriknordstrom.net>, Lisa Dusseault <lisa.dusseault@gmail.com>
Right. I think my concern at this point is that whatever we put into the spec, it's likely to be outdated fairly soon. I could see publishing a separate RFC (one that updates HTTP) to address this class of problem if/when that's possible; otherwise my gut feeling is that the most we can do is put a warning in that describes the problem, and list some mitigation strategies, stressing that they're not a complete fix. Make sense? On 17/07/2011, at 5:23 PM, Chris Weber wrote: > On 7/16/2011 11:03 PM, Mark Nottingham wrote: >> My understanding was that these holes had been closed, and that while there are undoubtedly still some clients out there that allow Host headers to be set, it's not an attractive attack to make now. What's the current state of things? >> >> >> On 17/07/2011, at 3:48 PM, Amit Klein wrote: >> >>> In the past (and this may re-incarnate) it was possible for clients to >>> provide arbitrary Host headers with HTTP requests, thus rendering the >>> Host header verification defense somewhat useless. See e.g.: >>> http://archive.cert.uni-stuttgart.de/bugtraq/2006/09/msg00090.html >>> >>> > > Most of these holes have been closed. Save for the exceptions where similar bugs will probably continue to surface, which is sounds like Amit was alluding to, as something recently did <http://weblog.rubyonrails.org/2011/2/8/csrf-protection-bypass-in-ruby-on-rails>. > > Having servers verify the Host header still seems valuable as defense in depth but not as the panacea of course. > > -Chris > -- Mark Nottingham http://www.mnot.net/
Received on Tuesday, 19 July 2011 13:01:45 UTC