Thought I'd get involved in the conversation (full disclosure: I'm involved with the SOMA paper that Terri has been discussing).
The point of both lines of work (both yours and ours) is to attempt to restrict the number of XSS and XSRF vulnerabilities which exist in the web today. We have gone about it in different ways, both of which have merrit in each of their own areas. With our approach, the configuration is centralized, and does not rely on developers to differentiate between safe and unsafe operations. With your approach, the network overhead is less and you allow configuration on a per-page granularity. 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. 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. 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. 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. In our work, we realized that the developer could not be relied upon to do things correctly all the time and hence we chose the approach of protecting against GET requests. 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. This may have potential side-effects for visually impaired users and other groups as well. I don't believe we can quite rely on JavaScript yet to solve this either, as a lot of screen readers don't support full JavaScript. The way I see it, in order to make a usable site which is also visually appealing, the only choice right now is GET. It would be good to work together to come out with a policy that protects against XSS and XSRF. Both our proposals attempt to do this, but in slightly different ways. Is it possible to combine features of both in developing an even better solution? I'm willing to work with you to accomplish this goal. We have posted our code on our website (http://ccsl.carleton.ca/ software/soma). We believe our code may be of use to you, as we encountered some of the same issues in attempting to write a policy checker add-on. Your implementation would probably be easier if you implemented the shouldLoad method of the nsIContentPolicy interface (and just checked for TYPE_SCRIPT) instead of attempting to parse to find the <script> tags. This interface also allows you to easily implement enforcement of the other headers involved in your proposal. In conclusion: We need to make sure that SSP benefits developers who are not security concious (because there SSP will prevent the most vulnerabilities). While the temptation is there to assume the developer will code securely, that assumption is the whole reason we have XSS and XSRF in the first place. _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
