- From: Bil Corry <bil@corry.biz>
- Date: Wed, 10 Feb 2010 16:50:05 -0800
- To: Aryeh Gregor <Simetrical+w3c@gmail.com>
- CC: Maciej Stachowiak <mjs@apple.com>, Julian Reschke <julian.reschke@gmx.de>, Anne van Kesteren <annevk@opera.com>, Thomas Roessler <tlr@w3.org>, W3C WebApps WG <public-webapps@w3.org>, public-web-security@w3.org
Aryeh Gregor wrote on 2/10/2010 3:21 PM: > On Wed, Feb 10, 2010 at 4:37 AM, Bil Corry <bil@corry.biz> wrote: >> Another threat is an attacker crafting a malicious payload in the Host header, hoping that it gets logged then viewed via a web browser. > > That's just straight XSS. I left it open-ended as I don't know what is being used to consume the log data (text editor, Java app, custom app, etc) and it could be someone is using regex or an xml tool to parse the log data. Given that, I envisioned the attack could extend beyond XSS to also include buffer overflows, recursive regex/xml poisoning, etc. The simple solution is to only accept the host headers you expect. >> And some webapps conditionally show debugging information based on the host header, so that the production hostname has a generic error page and the staging hostname produces a full stack trace. Simply forging the host header allows an attacker to view the full debugging information. > > I'd be surprised if this were common enough to be worth worrying about. I've seen it in both my work as a developer and my work as a pentester. It may not be common, but it does exist. On one site the net effect is the cookies expire in weeks instead of minutes, but on another site, the password reset token that is normally emailed to the user is instead displayed on the page (a debugging shortcut for QA). Not so good for a financial-sector website. - Bil
Received on Thursday, 11 February 2010 00:50:37 UTC