- From: Adam Barth <w3c@adambarth.com>
- Date: Wed, 19 Jan 2011 15:22:32 -0800
- To: "sird@rckc.at" <sird@rckc.at>
- Cc: public-web-security@w3.org, Sid Stamm <sid@mozilla.com>, Brandon Sterne <bsterne@mozilla.com>
You're blowing my mind Eduardo. I'll look at that in more detail, but parsing HTML in JavaScript doesn't seem like the best approach. :) Adam On Wed, Jan 19, 2011 at 3:20 PM, sird@rckc.at <sird@rckc.at> wrote: > Oh btw, the way it works is by parsing HTML by itself. > > If the DOM provided this events, then that would avoid the requirement > of parsing the DOM :) > > -- Eduardo > > > > > On Wed, Jan 19, 2011 at 5:19 PM, sird@rckc.at <sird@rckc.at> wrote: >> Hi Adam! >> >> I did a script that does this a few years ago: >> http://secinn.appspot.com/pstzine/read?issue=4&articleid=8 >> >> Mod Security is using it now as a demo, and there are a few sessions >> about it in OWASP Summit in Portugal next month. >> >> Greetings!! >> -- Eduardo >> >> >> >> >> On Wed, Jan 19, 2011 at 5:17 PM, Adam Barth <w3c@adambarth.com> wrote: >>> 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:23:33 UTC