Re: XSS mitigation in browsers

On Wed, Jan 19, 2011 at 3:45 PM, Giorgio Maone <g.maone@informaction.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.
>
> 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?

Those events, specifically, are problematic to expose directly to web
content.  For example, the BeforeScript event contains the contents of
the script element, which would allow a malicious web site to read the
contents of any URL.  For example, if a document on attacker.com
contains a script element that points to
https://mail.example.com/inbox, the attacker can read the contents of
the user's email inbox.

With some work, of course, we could polish up these events and have a
workable system.  There are two disadvantages to an event-only design:

1) To maximize security, you'll want to start listening to these
events as early as possible in your page.  That means you either need
to include all the code for your security policy inline at the top of
every page or you'll need to block loading the page on fetching an
external script.

2) Writing a correct JavaScript program that enforces a reasonable
security policy is somewhat tricky.  For example, we have a bunch of
implementation experience with postMessage that shows that folks often
write incorrect regular expressions when trying to filter messages.
By using a more declarative policy language with a restricted syntax,
we make it harder for folks to shoot themselves in the foot.

> Having those for cross-browser extension development would be nice anyway :)

Indeed, but that's a non-goal for this feature.

> Mozilla is implementing a more limited but related feature set as well:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=587931

Thanks for the pointer.

Adam


> 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 Thursday, 20 January 2011 00:16:50 UTC