W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2009

[whatwg] Clickjacking and CSRF

From: Aryeh Gregor <Simetrical+w3c@gmail.com>
Date: Fri, 17 Jul 2009 18:34:08 -0400
Message-ID: <7c2a12e20907171534g4168f484lbf9fadfd1ef98b28@mail.gmail.com>
On Fri, Jul 17, 2009 at 6:21 PM, Brandon Sterne<bsterne at mozilla.com> wrote:
> No, that feature is not part of the current design, though nothing is
> set in stone. ?Couldn't you achieve the same effect (verifying your
> policy isn't blocking wanted things) by simply testing the pages in a
> CSP-supporting browser and watching for violations (in the client or on
> the report-uri server)?

Only if I visit every single page in the whole complicated app that
users might visit.  With all their settings.  Which might or might not
be practical.

On Wikipedia, for instance, users are allowed to specify custom
scripts to load, kind of like server-side Greasemonkey.  That will
certainly break if we prohibit external script loads, but we can't
really assess the extent of the problem in the current spec without
actually enabling the feature and (possibly) breaking everything.
(How we'd handle this at all, I'm not sure.  We might need to allow
registered users to opt out, or use a more lenient policy.  But that's
a separate issue.)

More generally, it would be a pain to do a full audit of the code and
all extensions to find all instances of inline script, and all the
other assorted possible violations that might be occurring.  We could
do it with a test browser, yes, but we'd only catch the most common
cases that way.  The code running on Wikipedia is somewhere over
700,000 LOC, it wouldn't be trivial at all to manually find all the
places where violations could possibly be generated.

I think the ability to have violations reported without actually
preventing them would be very useful to ease deployment in existing
apps.
Received on Friday, 17 July 2009 15:34:08 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:14 UTC