On Jul 10, 8:47 am, [EMAIL PROTECTED] wrote: > The problem is that although solutions exist > to both of these problems, developers have not properly implemented > the solution. With your approach of SSP and safe requests, you are > again relying on the developer to use the solution correctly, and put > all modifications behind a POST request. You have not removed the > reliance on the developer to code correctly, just simply shifted it to > a different 'thing' that they have to do.
Perhaps I am misunderstanding this point. Are you suggesting that an ideal model wouldn't require that web developers do anything differently than they currently are? Site Security Policy is intended to be a belt-and-suspenders tool to protect sites and users, but we are still advocating that developers keep their web applications free of vulnerabilities. > From previous conversation > with Terri, asking for an example of where a GET request can be used > to affect change on a web-site is asking for us to find a security > vulnerability in a website, since this is basically the definition of > a XSRF. Large sites are going to be well protected against this type > of thing, but I'm sure if you look at any of the recent CERT > vulnerabilities regarding XSRF or XSS you'll notice that they are all > exploitable through GET requests. The restriction of CSRF protection to POST was not because we think CSRF isn't common via GET, it is because there are too many ways that cross-site GETs are possible, and in current legitimate use, to make mitigating them worthwhile. _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
