W3C home > Mailing lists > Public > public-web-security@w3.org > January 2011

Re: XSS mitigation in browsers

From: Adam Barth <w3c@adambarth.com>
Date: Wed, 19 Jan 2011 15:22:32 -0800
Message-ID: <AANLkTin4Gur+Jg=RGgyuRyoowsXV_YrkYHDm1tU+grz6@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 19 January 2011 23:23:33 GMT