On Tue, 05 Jul 2011 16:30:26 +0200, Arthur Barstow <art.bars...@nokia.com>
wrote:
Anne - please add some text re the consensus of the contents point and
then I'll start the CfC.
http://dvcs.w3.org/hg/from-origin/raw-file/tip/Overview.html
Now has "The contents of this document do not necessarily reflect the
consensus of the Working Group." which I think is redundant with
"Publication as a Working Draft does not imply endorsement by the W3C
Membership." but moving on is more interesting.
On 7/1/11 1:52 PM, ext Hill, Brad wrote:
The new WebAppSec WG charter draft does include a deliverable for
secure mashups built with cross-domain framing, with the specific
intent to put forward a proposal for anti-clickjacking in this space.
However, I have concerns with nearly every aspect of this draft.
First, I am concerned about mixed goals in the problem statement. It's
definitely not in the proposed charter scope for the WebAppSec WG to
address issues like bandwidth "theft" and license enforcement. Even
for the WebApps WG, it is arguable that some of these goals go against
core Web Architecture principles. (http://www.w3.org/TR/webarch/)
Secondly, several of the goals, even if couched in terms of security,
aren't in the interest of the user. If I go to a page, I want to see
images, fonts and videos on it. Policies that prevent that from
working are actually adversarial to the user. From a basic security
principles perspective, the client-side UA is not the place for such
restrictions to be enforced, as they can be easily disabled.
Further, conflating mechanisms to protect the user (anti-clickjacking)
with mechanisms adversarial to the user (font licensing) encourages the
user to disable even the protections that they should want.
Finally, don't think the proposed mechanism here for user-protection is
adequate for many/most use cases at risk of clickjacking that web
application owners would like to deploy. A binary frame/no-frame
policy based on a whitelist of origins is both very limiting and not
terribly secure. Consider a "like", "+1" or "pay" button. These may
be framed on tens of thousands of origins, making a whitelist
unmanageable. Or they may be framed-by-permission on an origin with
tens of thousands of resources/pages/applications (forum, auction site,
etc.) where an XSS or similar in any one of which would expose the
framed content to clickjacking again.
I think it's preferable to work towards a mechanism where resources can
declare they can be framed, but only subject to some policy or set of
capabilities which guarantee clickjacking protection, visibility, etc.
I agree we should look at this more, but I think having a published draft
helps. The background of this work is actually not clickjacking, but
specifically @font-face (web font embedding mechanism) where a default
same-origin restriction is considered. This was drafted as an alternative,
opt-out mechanism, though can potentially be used for a number of other
things as well.
--
Anne van Kesteren
http://annevankesteren.nl/
