> I agree - but this is because what they are asked to do is hard. There > are two things we can do about that - we can make the thing they are > trying to do easier, or we can provide another easier thing they can do > as well, which helps when they get the first thing wrong. That's the > approach we are taking.
Yes, both approach attempts to make things easier as well. The question is "how much easier do you want to make it?" SSP indeed does make it easier to protect against XSRF by blocking cross-site POST requests. Things would be even easier if SSP applied universally (including GET requests) instead of only in certain circumstances. > > XSS 'can' be solved > > by proper input validation, and XSRF attacks 'can' be solved by using > > random identifiers in the links that perform an operation or examining > > the Referer HTTP header. > > Note that Referer checking is not a solution, a) because it's optional > for privacy reasons, and b) because there are existing ways to fake one > (e.g. using Flash, I believe). Which still leaves random identifiers... (but this is getting off- topic). > Indeed. But there are multiple good reasons to put modifications behind > a POST request, including existing browser behaviour preventing > resubmission of POSTs. So it's something they may already be doing anyway. Browsers preventing resubmission is only an issue for non-idempotent requests (and even then, non-idempotent requests have been done over GET). The problem in this discussion is we are debating a point based on a very one-sided view of the problem and what developers are capable of. We know that the problem exists, and we know what developers need to do in order to fix the problem. We can argue for a very long time as to the merits of whether or not to protect GET, but the real kicker will be whether or not the solution ends up helping. The same is true for the argument of always doing operations over POST - we can argue for a while but it's all about what developers are actually doing. With POST, I think that the evidence points towards the fact that developers perform operations through GET, even though the HTTP spec suggests otherwise. > That's why we have the <button type="submit"> element, which allows > arbitrary HTML inside > it.http://htmlhelp.com/reference/html40/forms/button.html Learn something new every day. Did not know about that one. Thanks. On another note, there is the issue of policy files vs. headers. Evert has expressed a preference for policy files (in this discussion) and I tend to agree with him - our work used with policy files. Adobe used policy files for flash. Work by Justin Schuh also used policy files (see http://taossa.com/index.php/2007/02/17/same-origin-proposal/ - this gives another related proposal). I think, especially with reference to Request-Source, that getting rid of the header and using a policy file would be a good idea. Glenn. _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
