- From: Adam Barth <w3c@adambarth.com>
- Date: Wed, 19 Jan 2011 15:17:07 -0800
- To: "sird@rckc.at" <sird@rckc.at>
- Cc: public-web-security@w3.org, Sid Stamm <sid@mozilla.com>, Brandon Sterne <bsterne@mozilla.com>
On Wed, Jan 19, 2011 at 2:58 PM, sird@rckc.at <sird@rckc.at> wrote: > Couldn't the same be done with simply a script element? No need for > webkit (browser) support. I believe you can block external script loads using the beforeload event, but I don't know how you would be able to block inline scripts or inline event handlers purely in script. Another approach, of course, is to add "before" events for these operations as well to allow for programatic control. Adam > On Wed, Jan 19, 2011 at 4:42 PM, Adam Barth <w3c@adambarth.com> wrote: >> Hi public-web-security, >> >> I'm not sure if this the right forum for discussing new browser >> features that help mitigate cross-site scripting. If not, please feel >> free to point me to a better forum. >> >> As I'm sure many of you are aware, various folks from Mozilla have >> proposed Content Security Policies >> <https://wiki.mozilla.org/Security/CSP> as a way of improving the >> security of web pages by including a security policy. I'm interested >> two aspects of CSP: >> >> 1) Cross-site scripting mitigation >> 2) Notification of policy violations >> >> The simplest design I could think of that achieves those goals is >> described on this wiki page: >> >> https://trac.webkit.org/wiki/HTML%20Security%20Policy >> >> The design is largely inspired by CSP, but different in a few ways: >> >> 1) Instead of using HTTP headers, the policy is expressed in HTML. Of >> course, authors will want to place the policy as early as possible in >> their document, so we're using a meta element, which can be placed in >> the head of the document. >> >> 2) Instead of exposing policy levers for every kind of resource load, >> this proposal only lets the author control the source scripts. This >> focus on scripts is motivated by wanting to prevent the attacker from >> injecting script into the page. >> >> 3) Instead of reporting violations to the server via HTTP, this >> proposal simply generates a DOM event in the document. The author of >> the page can listen for the event and wire it up to whatever analytics >> the author uses for other kinds of events (e.g., mouse clicks). >> >> Let me know if you have any feedback on this proposal. In general, >> I'm more interested in feedback that leads to simplification rather >> than feedback that leads to more complexity. >> >> Thanks! >> Adam >> >> >
Received on Wednesday, 19 January 2011 23:18:13 UTC