Re: XSS mitigation in browsers

> 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.

Opera exposes all the needed events, albeit to privileged user scripts only:

http://www.opera.com/docs/userjs/specs/#evlistener

What are the cons to exposing something like that to web content?
Having those for cross-browser extension development would be nice anyway :)

Mozilla is implementing a more limited but related feature set as well:

https://bugzilla.mozilla.org/show_bug.cgi?id=587931

--
Giorgio Maone
http://maone.net


Adam Barth wrote, On 20/01/2011 0.17:
> 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:48:04 UTC