W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2014

Re: Remove paths from CSP?

From: Michal Zalewski <lcamtuf@google.com>
Date: Wed, 12 Feb 2014 00:38:04 -0800
Message-ID: <CAN44M3W2_NFyS2w_A=o=+TBbLZzaUwNnwSrAYw30YBTxwQG8Rw@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, Odin Hørthe Omdal <odinho@opera.com>, Adam Barth <w3c@adambarth.com>, Dan Veditz <dveditz@mozilla.com>, Brad Hill <bhill@paypal-inc.com>, Garrett Robinson <grobinson@mozilla.com>
I think that paths are mostly useful for scripts, so that you don't
end up with random JSONP interfaces that accept arbitrary callback
function names as permissible script sources.

I suspect that without paths, CSP is still very much useful for
detecting login state. For example, depending on your login state,
many Google services will or will not redirect you to
https://accounts.google.com/.

More broadly, login state can be probed pretty trivially without CSP
across virtually all major web services. You can usually find a script
or an image that returns 403 or redirects to the login page if you are
not logged in, or loads successfully (invoking onload or creating
measurable side effects) if you are.

The ability to specify full URLs seems a bit more sketchy because of
the problem outlined by Egor; I'm actually a bit surprised that we
support that. An interesting corner case, of course, would be websites
that invent their own parameter passing schemes by abusing the path
syntax (/foo=1/bar=2, etc). This is relatively rare, but not rare
enough.

/mz
Received on Wednesday, 12 February 2014 09:36:06 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:04 UTC