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

Re: XSS mitigation in browsers

From: <sird@rckc.at>
Date: Wed, 19 Jan 2011 16:58:41 -0600
Message-ID: <AANLkTimw6EvgMeJJXHAC2YSxneVqrdC_YiMsTfaqiz5J@mail.gmail.com>
To: Adam Barth <w3c@adambarth.com>
Cc: public-web-security@w3.org, Sid Stamm <sid@mozilla.com>, Brandon Sterne <bsterne@mozilla.com>

Couldn't the same be done with simply a script element? No need for
webkit (browser) support.

-- Eduardo

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 22:59:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:25 UTC