- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 30 May 2008 13:40:55 -0700
- To: Bjoern Hoehrmann <derhoermi@gmx.net>
- CC: "WAF WG (public)" <public-appformats@w3.org>
Bjoern Hoehrmann wrote: > * Jonas Sicking wrote: >> First of all it is very possible that the server itself, or the scripts >> running on the server, performs actions that the server administrator is >> not aware of. For example an administrator might not realize that the >> server supports the PUT action such that other sites can't just POST to >> a CGI script, but also replace the script using PUT. >> >> Second, even if the administrator is aware of the server performing a >> harmful action for certain headers or methods, it can be very hard to >> change this. The current spec has an all-or-nothing approach. To enable >> cross-site POST you also are forced to deal with all other methods, >> weather you want them or not. > > Well, let's first be clear about the setup here, to use the PUT example: > > +---------------+ +------------------+ > | Attacker |-----------------| Compromised site | > +---------------+ +------------------+ > | / | > [Can't PUT] +->> trusts >>+ | > | / \ | > +---------------+ +------------------+ > | Victim server |<---[Can PUT!]---| Privileged User | > +---------------+ +------------------+ > > So the victim server would already be configured to tell Privileged User > and Attacker apart, otherwise the attacker could PUT directly and would > not care about cross site requests. It can't be enough to compromise the > other site as otherwise the attacker could PUT directly aswell (e.g. the > site stores username and password in a cookie, attacker reads out cookie > and uses them to authenticate with the victim server) So first off I think a lot of sites are going to "trust" *, so there is no need to compromise a site, just set up your own. Second, even if you compromise a site, you can only steal the users cookies for *that* site, not the cookies for the victim server. / Jonas
Received on Friday, 30 May 2008 20:43:48 UTC