[EMAIL PROTECTED] wrote: > In terms of the safe vs. unsafe requests, perhaps I can lend some > insight. The whole reason we have these XSS and XSRF attacks in the > first place is because developers have messed up.
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. > 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). > 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. 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. > Related to the POST vs. GET arguments above is the fact that the only > way of doing a POST request currently is by submitting a form. While > browsers have gotten better at being able to customize the appearance > of a submit button, they are still in no way perfect, and hence some > of the visual style approaches that are possible on things like > <a>...</a> are not possible on the<input> submit element. The re- > arranging of the text (going from between the opening and closing<a> > element to inside the value attribute of the input element) also > contains several restrictions. A lot of HTML is usable inside the<a> > and</a> but only plain-text is allowed inside the value attribute of > the input element. That's why we have the <button type="submit"> element, which allows arbitrary HTML inside it. http://htmlhelp.com/reference/html40/forms/button.html Gerv _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
