See also: IRC log
<scribe> scribe: Josh_Soref
<scribe> scribenick: timeless
<bhill> we will pass around the wireless mic
<bhill> and are lucky to have the top W3C scribe in the room
bhill: Brad Hill, Pay Pal, Co-Chair
puhley: Peleus Uhley, Adobe
DanD: Dan Druta, AT&T
dveditz: Dan Veditz, Mozilla
ekr: Eric Rescorla, Co-Chair
Arno_: Arnaud Braud, France Telecom, observer
JeffH: Jeff Hodges, PayPal
Josh_Soref: Josh Soref, RIM, observer, scribe
gioma1: Giorgio Maone (on phone)
<bhill> Clickjacking Threats
puhley: for those on the phone, there's a click jacking page
[ puhley describes the Clickjacking Threats page ]
[ Content overlays ]
puhley: overlay attacks
... transparent overlay attacks
... there are basically 4 different attacks
... flash player has a screen scraping solution
... it'll write out a dialog to the screen
... and then it will ask the renderer what's actually shown
... to see if it's really showing
... but as we add content separation
... we don't want to allow content to screen scrape
... other solutions include X-Frame-Options
... Frame Busting
... another type of attack is Scrolling attack
... in this, the victim content is completely visible
... top layer of content
... but you scroll it offscreen so only the answers are visible
... but you put a fake question to the left
... "Do you like chocolate"
[ Everyone likes chocolate ]
puhley: a downside
... of the solution of putting questions in the center of the page
... is that users think it's coming from the system
... which means that users trust the question more than it should
dveditz: there are two kinds of questions
... the browser can relatively easily ensure its content won't be click-jacked
... but it's harder to protect the correct conveyance of two different web contents
puhley: does the user need to know the origin of content?
... and making sure the question is tied to the piece of content with which it's associated
... a reason that flash renders itself
... instead of a modal dialog
... is if you're on a page with ads on the side
... you don't want a malicious ad on the side to convince the user that it's CNN
... another attack is rapid content replacement
... make a dialog fully visible, but only for a fraction of a second
... convince a user to click rapidly
... then swap in the attack for a short period
... a countermeasure
... is to require a dialog be visible for a set number of seconds
... (Flash Player)
... it creates a problem for users
dveditz: Mozilla has a counter visible
puhley: there are tradeoffs in any solution
... another version is repositioning the trusted window
... you're doing screen scraping
... the window is visible for 3 seconds
<dveditz> (the impt point was that users complain about that kind of solution)
puhley: but in the right hand corner
... and then you scroll it to the center of the screen
... and then back to the corner
... one thing David brings up in his paper is Phantom mouse cursors
... i'm not sure he sent a link to the demo to the list
... basically you create a floating div tag with a mouse cursor
... which is at a fixed offset from the real mouse cursor
... and the real mouse cursor has an invisible cursor
... and you get the real mouse cursor over the dangerous dialog
... but the fake one is over "Do you like chocolate?"
... Another attack is Drag and drop
... this is more specific to certain victim windows
... one of the top 10 web attacks from last year included a DnD attack
... for people doing frame busting, people play tricks with event handlers
... using 204 event codes
... tell the browser "No Content"
... try to use malicious event handlers
... if the browser creates a super window
... can i create a listener to it?
... Trusted Dialog extensions
... Say the dialog is bright yellow
... you render yellow on the page around it
... and it looks like your content is part of the trust
... maybe extending the two lines into a longer fraction of a paragraph
... Trusted User interfaces
... any solution needs to be careful about how much trust it conveys
... that something isn't equivalent to the SSL dialog
... Brad posted that there's no distinct level of trust
... for the last one, i recorded a general thing "does the user understand what they're looking at?"
... I list some possible solutions for some of them
... this is designed to be the aggregation of ideas
JeffH: this is the problem space
bhill: status codes and event handlers
... people are afraid of being able to turn off scripting in iframes
... since it turns off frame-busting
<bhill> gioma1: would you like to discuss your submission, either voice or here on irc?
<bhill> I can project the irc channel for the room
<bhill> or we can just go over the paper ourselves
<gioma1> I'm unable in voice, I hear very badly. But I'm open to any question about the paper in IRC.
bhill: There is another attack
... where you can use the rapid click attack
... in the context of two browser windows
... or opening a dialog in the browser context
... trusted-window underneath untrusted-window
... and that allows bypass of X-Frame-Options
<bhill> gioma1: we'll review the paper here voice, then, and ask questions on irc
bhill: probably most of us here are familiar with NoScript
... most prominently it offers the ability to turn off scripts per context
... it's popular among security conscious individuals
... it also has ClearClick
... and it's the most prominent implementation
... Flash Player has something specific
... but ClearClick is more general
... The ClearClick WAS 2012 paper
... proposes an on-by-default mechanism
<gioma1> ClearClick WAS 2012 paper
bhill: the ClearClick technology is implemented mostly in terms of HTML5 technology
... and requires very few browser hooks
... ClearClick works by registering a listener that captures mouse/keyboard/dnd events
... so it can see them before they're delivered to browser content
... implemented with a mozilla specific event
... the second stage is a Fast-track bypass
... to check if the window is unlocked
... i.e. Trustworthy against itself
... Parent chain check
... Rapid Fire check
... Obstruction check
... takes a screenshot of reasonably sized (roughly 300x200px)
... and comparing the content the user clicking
... with the rendering the user sees
... there's no policy-channel between the server and the plugin
ekr: the larger the window the less good things get
... if all i'm changing is the price
<gioma1> I'd like to clarify
<gioma1> that the size of the screenshot has an upper bound
<gioma1> of 320x200 for perf reasons,
<gioma1> but the lower bound is set by the document's inherent size
<gioma1> (so very tiny button gadgets like "Like!" work)
ekr: the case i'm thinking of
... Amazon Purchasing
... the thing being obscured is quite large
bhill: in the case of a PayPal dialog
... you could change just the price or the name of the user
ekr: this style strategy seems to require site interaction
... indicating how much tolerance it has
<gioma1> btw, the size grows in case of a form to include the whole form
bhill: that's less of an oversight on the part of ClearClick
Josh_Soref: what tolerance does one get if it's the size of the form
... is it still x%?
... the concern is that if only a few pixels (the $$ number) are changed
... and the form is "very big"
... then %-wise relative to the protected pixel area, the variation may be below the threshold
<gioma1> it used to be no tolerance
<gioma1> At-the-moment (3 or 4 weeks) it's 18%, configurable.
<bhill> configurable by you, or by the target content?
<gioma1> By the tool even at runtime, so currently by me but...
<gioma1> a policy channel would be a benefit for several site-customizations which
<gioma1> would increase both accuracy and sensitivity
bhill: an additional check gioma1 sent on the mailing list, after he sent the paper.
... is for phantom-cursor, is that if the cursor has been changed, it triggers
... Generally, when the difference is significant, ClearClick presents the user with a comparison dialog
... where the user can choose to proceed or stop
... he's also looking into mozAfterPaint
... in order to address timing based attacks
... I'll read his conclusion:
<bhill> I asked the room who uses ClearClick
<bhill> several hands went up
<bhill> people agreed that "used to see false positives a lot, lately it is very very good, don't see them anymore"
<bhill> timeless is trying to generate a warning on bugzilla where he had previously seen them
<gioma1> in facts, it's the effect of the recent tolerance introduction and other tweakings regarding viewport decoration detection.
bhill: that we haven't seen false positives in a long time
... is fairly encouraging
... and then having a way for a site being able to specify what it wants protected
... we could standardize this
<bhill> alternate download: http://lists.w3.org/Archives/Public/public-webappsec/2012May/att-0021/ClearClick_WAS2012.pdf
<bhill> we will take a 10 minute break
<bhill> back at 32 after the hour
<bhill> thanks gioma!
gopal: Gopal Raghavan, Nokia
tanvi: Tanvi Vyas, Mozilla
bhill: this is another approach i proposed on the list a couple of months ago
... it's much less comprehensive than ClearClick
... the basic idea is that
... the Web Application could declare -this control is clickjacking protected-
... it could have a countdown, or a slider
... while it's being interacted with, it would have to be topmost
... visible, stationary
... examples could be a new element type, or add a new attribute
... examples of how this might work
... the action the user needs to do to confirm the action is Slide
dveditz: that's a problem for a Screen Reader
bhill: i think a lot of these attacks aren't applicable to screen readers
... luckily/unluckily they aren't a target
... but there would be the ability to degrade gracefully
... it could act as a normal button
... or the AA could support the feature
DanD: what happens if you have two competing protected elements
bhill: they only have to be topmost while your click is being delivered to an element
<JeffH> what is link to list of this meeting's reg'd attendees ?
bhill: the click is only being delivered to one element at a time
ekr: i'm just starting to think about the underlying theory of the mechanism
... it seems to be force the user to take some time to see it
... and take some time to watch it
bhill: yes, and have the ability to abort
ekr: i wonder how much drop off you'd get
bhill: i don't have user studies on this yet
... what would be feasible, and what would UAs be willing to do
... it isn't applicable to everything
dveditz: it doesn't fix DnD
... but it has low battery/perf overhead
puhley: for an html element
... you set up a div tag
... with content in it
bhill: you could have a new request
... but if you're on a laggy network
... you don't want to click and wait for a resource
paulc: as your host, i'm noting there are sweets outside
... and once the html group gets there, they'll be gone
ekr: are there other legitimate reasons
... for why it would be obscured
... it almost seems like
... if it would have changed when i click the control
... it's probably a bad case
bhill: the difference is
... you have less complexity
... i was trying to have to do constant monitoring
... constant screen shots
... that's an unacceptable requirement
... on a mobile device
ekr: i put my finger on this slider
... and you do a Reflow
... you redraw that section of the screen
... and we expect the user to figure out what changed
Josh_Soref: that's sort of like what clearclick's compare-dialog does
[ bhill scrolls to example 2 ]
bhill: here there's a clown store text with a like below
... but clicking the like button
... then can show "Slide to like Acme Inc."
ekr: in this case, there's a reason why we'd want to change the content
DanD: you may have a different approach, as a two factor user interaction
... using two actions
bhill: why couldn't an overlay site train you to do that?
DanD: i'd be happy to have something that surfaces out of an overlay
... the user would hopefully say "i won't trust that page,
... if the trusted element is different"
puhley: if the slider slides instead of the finger
... is that trusting?
bhill: we had comments from michal zalewski
dveditz: what if who changes it?
... we can only protect mixed origin
... if we only have one origin, and that page moves
... in current browsers, you can create a dragging attack
bhill: my requirements forced the control to be stationary
... now, what if the protected element is rendered offscreen?
dveditz: the nice thing is that the browser could have a hint about how to re-render
gopal: are you also considering orientation changes?
bhill: does it shift while your finger is down?
bhill: I proposed we could take you to a lightbox experience
dveditz: that's fine with checking out
... but if it's a like button
... or click an ad
... then it's more disruptive
... but those probably aren't using forms
... click fraud on an ad wants to get you there as fast as possible
bhill: having backchannels with the site communicating what it wants to protect
DanD: did you do user studies?
bhill: i have not yet
dveditz: those slides don't appear to be on the archive
bhill: let me send that out
[ Drawbacks of X-Frame-Options ]
bhill: sometimes you don't want to share information to some parties
... Allow-From doesn't help
... the merchant that could generate a clickjack
... is the same that would be generating a sale
... the person embedding the +1/like button
... is the person who benefits
dveditz: can you embed a like for someone else?
bhill: i think you can
... sometimes iframes are better
... the screenshot approach is sometimes nice
... but sometimes your attention is elsewhere
... there's a problem with false positives
... that can be reduced
... and interactions are hard
... we tolerate ClearClick compare dialogs
... but people outside this room have no idea what it means
... we have low deployment rates
... ClearClick probably has 1‱
... it's very small
dveditz: if ClearClick was split out from NoScript, it could probably have higher deployment
bhill: Adaptive UI randomization
... click jacking depends on same-origin
... it depends on consistent layout
... if you randomize the UI
... you can impinge the ability of the attacker
... that was proposed by Bill Curry (PayPal)
... one of the first proposals to the list
... but the attacker can send clicks to multiple locations
dveditz: deployment on NoScript is a bit over 1%, but less than 2%
bhill: that's quite impressive
... and successful attacks in 1% of cases is still a profitable business
... Refining Randomization
... we can do recording of clicks
... and do analysis to detect fraud
... / clickjacking
... on the backend we create a bucket based on target
<dveditz> the most popular "user-chosen" add-on has around 10% deployment
bhill: for like, the likee
... for pay, the payee
... look at first click miss rates bucket-by-bucket
<dveditz> there are some ride-along add-ons that are more popular, that users didn't really select. e.g. the Java Console add-on
bhill: assume some natural rate
... this protects against popunder and close attacks
... we can't distinguish one-off attacks from random noise
... but we can identify campaigns
... if they start doing click jacking
... we'll see the first click rates jump
<dveditz> don't quote me on the numbers, I'm not one of our metrics guys. Just trying to eyeball the published "users" number on addons.mozilla.org but I don't know if they're measured the same way we measure Firefox users
bhill: Sensitivity of Detection
[ Graphic: Sensitivity of Clickjacking Detection ]
dveditz: this isn't preventing fraud
bhill: it's detecting after the fact
Josh_Soref: they can do more
... they can reverse the charges/likes
... and penalize the account
ekr: the enclosing page can track the mouse
bhill: if the user doesn't see this interface
... they're seeing an overlay
... they'll have a 66% miss rate
... if it's only getting clickjacks
... and we can distinguish at the backend
DanD: this is an analytics capability
... assuming everything else works
... you can reduce the natural conversion rate to as little as 1% through clickjacking
... with 3 or 4 positions
... Adaptive Responses
... what if i try to put my competitor's store into the dog house?
... If you detect this, you can have a graduated response
... popup with X-Frame-Options
... Add a CAPTCHA or re-verify credentials
dveditz: do you guys check referers?
... i'm curious as to whether a reliable origin header is useful
... if you're trying to attack a rival
bhill: the button would have to encode the refering frame
dveditz: you may or may not get a referer on that today
Josh_Soref: if there's no referer, the server can require more UI
bhill: you can't use this for WebMail, or the FlashControlPanel
... or Nascar
... if you can't bucketize your targets
... for webmail/flashcontrolpanel
... it's expensive, you need to be able to do the analytics
JeffH: or already have it existing
bhill: a lot of the targets already have the capabilities in house
... david hong said the attacker could try to disperse the attack
... some of this involves determining the natural misclick rate independently
... instead of case-by-case calculation
... the biggest attack is the partial reveal attack
... "Click the Sleepy Frog to Win"
... but ClearClick will find that in a heartbeat
... combining the statistical backend bucketization
... and apply it to clearclick
... the page could say "if you think you're going to have a ClearClick warning"
... "send the report to a feedback URI"
... a policy hint saying "report clickjacking to url" where the url encodes the transaction
... that makes false positives disappear
... you never stop users from interacting
... they can learn
... no confusing dialogs
... small install base can protect everyone
... penalize the account commiting fraud based on highly sensitive information
... randomization isn't for everyone
... high cost, only usable in certain UIs
... primary targets are in its "sweet spot"
... Combines well with client-side techniques
... reporting loop + backend- fraud analysis approach can remove some weaknesses of heuristic client-side techniques
DanD: it could be chatty
bhill: it could be pretty simple
... instead of a dialog in ClearClick
... it's a single Ping with a unique identifier
dveditz: a META with a report URI
bhill: META clickjack-report uri
dveditz: browsers that know do it
... browsers that don't ignore it
bhill: the report isn't much difference from CSP
... we only ship on violation
... that hasn't been a problem in bandwidth
puhley: we're assuming a page that has already CSFP
... for PayPal, you have 1-click buys
... what does paypal need to encode?
bhill: payee, amount
... the no-opt-in has the high bar
... the web is complicated
... how do we know we aren't breaking a large part of the web
... does gioma1 have telemetry on false positives?
puhley: for the submit button/slider
<dveditz> I doubt it, people would scream about tracking or somesuch
puhley: the page would have to be designed to fit the slider protection
<gioma1> I've got *voluntary* reports, could try to extract some stats for next meeting.
<dveditz> the population of people interested in NoScript is almost exactly the sort that would notice and complain about extra connection attempts unrelated to their task at hand
bhill: gioma1, it would be really cool if we could get the overall rate of warning dialogs
... what percentage of sites generate warning dialogs
... and how many times / year does the average (opt-in) user see a dialog
<gioma1> bhill, I could extrapolate from people who uses the "Report" button
<dveditz> that kind of non-specific telemetry is generally accepted
<gioma1> are you suggesting to instrument current ClearClick to send anonymous usage stats?
puhley: for the use case
... who would use it
... we didn't define a User Persona
<JeffH> gioma1: i think the short answer is "sure"
puhley: we were talking about <input type
... you have a PayPal page
... and a pay now button
... the assumption is the attacker is using an iframe
... the victim page is by definition iframed
... how does the page define that it's opting into the click-jack protection
... it could just be a header
... but the page has to define which button is click-jack protected
... would <input type="clickjackprotected">
... be sufficient instead of a page header
... there are pay now buttons on very large pages
... with full receipts
... in clickjacking, a fraction of the page has been rendered
dveditz: are we only talking about opt in at this point?
... the nice thing about ClearClick is that it doesn't require opt in
... only Facebook/PayPal will do it
puhley: we have 3 levels
... server side
... 1. clearclick - browser for all pages
... 2. opt in "this is a sensitive page"
... -- slider
... 3. server side with heuristics
bhill: 1.5, opt in for all pages, with policy channel to refine it
... not sure if there's a precedent for @w3 level
... a compatibility list like ie8
... deliberately fallback to ie7 mode
... i wonder if we could identify that certain sites always generate warnings
... and opt them out
... i'm tossing ideas out
DanD: the challenge is to educate the user community
... on the real
JeffH: that will never happen
DanD: having multiple options with UI implications will have user confusion
puhley: https in the location bar is an indication
... we changed once every 5 years and still confuse users
DanD: the protected element
... is a good way to give to a developer
... but it can be abused
... someone may overuse it
... and not realize they're causing harm
bhill: that just means genuine sites get to show their own ui
... but it doesn't protect
... fraud sites
... the risk is that the end user will assume the right site is involved
dveditz: most click jacking is based on size of frame
... could we do something based on frame size?
... if the page is too small
... it might play with protected content
... it could be in CSP
bhill: something like ClearClick with Hints+Policy+Feedback
... we could get very good for the whole web
... but what do you do when there's the "This is BAD"
... that's fine for PayPal/Facebook
... we could have the dialog for ClearClick
... i love the technology
... i hate the failure mode
puhley: i could say "deliver+give report"
Josh_Soref: instead of showing a warning, redirect framed page to a browser-hosted page that can't be attacked, which explains the situation
... there is no harm
bhill: unless it's a false positive, then the user is really freaked out
Josh_Soref: browser vendors can use that to improve huristics
bhill: if we do ClearClick and opt in
... that's a tiny percentage of the web
... if we opt everyone in by default
... is there a way we can
... Could we have browser manufacturers to investigate false positives?
... or just add a hard block?
puhley: i haven't used ClearClick enough
... majority of pages are simple
... it's just Hulu/Gaming sites
<gioma1> the default tolerance (in ClearClick terms) for opt-out standalone deployments could be set relatively high
<gioma1> (like the current 18%, which looks to be doing very well)
<gioma1> and websites who care could tweak it to be stricter
gopal: does the slider consider touch events?
Josh_Soref: it's a mock-up, browser implementer could choose how to do that
JeffH: how big a problem is clickjacking per se?
... puhley notes that most web pages are "simple"
... how much this is an issue on a global issue should inform this
bhill: maybe it's nice to opt in by default
... but maybe the only people who care would be willing to opt in
puhley: there's a small number of sites who are concerned
... but they have a large number of users
JeffH: but that can inform how it's approached
... thinking about the userbase and the entire set of sites
... v. scoping to high value/high expertise sites
... and what's sufficient to hand them
... may be less work for a group such as this
... if this is a tangled mess
bhill: how conservative do we have to be in terms of not breaking anything else out there?
bhill: i lean to very
... we could certainly lean to a mechanism that is only opt in
... and maybe we could later apply by default
dveditz: if we had an opt in mechanism, we could get pretty radical
bhill: you could monitor but not enforce for all pages
... and you could get a ton of data
<dveditz> (and if it sucks then people won't opt-in)
bhill: and calculate false positive rates
... if you already have to build the technology for some sites
dveditz: gioma1 mentioned he has an 18% tolerance
... he could track what it would be at 5% / 10% / 20% / ...
... and he wouldn't need to collect the sites
... just "of the sites i fired, how many would i have fired at this level"
<gioma1> how? by randomizing the tolerance?
<JeffH> can u hear dveditz's verbal response?
dveditz: assume you compare, get a number and compare to your tolerance
... report what the difference rates are as a population
<gioma1> No I didn't hear. oh, I get it, by recomparing at different rates.
<gioma1> (maybe in background)
<dveditz> I assume you compare once and get a "difference number"
<bhill> so we could start the technology as opt-in and only apply it to sites that provide policy/hints
<dveditz> which you then say "if (diff > tolerance) warning();"
<dveditz> but you can save that diff in buckets
<bhill> but run it in the background and get really large telemetry numbers on how often it would trigger on the rest of the web
<bhill> at different sensitivities
<bhill> and use that to later make a decision as to whether to opt-in the entire web, and at what sensitivity
<bhill> and perhaps collect, voluntarily, what sites would break and have a compatibility opt-out list baked-in
<gioma1> bhill, wait, someone did something similar
<gioma1> let me find the paper...
<gioma1> these guys built a scanner based on ClearClick to analyze Clickjacking's prevalence on the web
<gioma1> (I discovered it last night while refining my references)
<bhill> so giorgio, would you be willing to begin working on a w3c draft describing the clearclick technology in a browser-agnostic manner
<JeffH> good paper to reference, thanks gioma1
<bhill> with mechanisms for resource owners to provide hints/policy to the enforcement mechanism, and a way for the mechansim to report back to the resource owner
<gioma1> bhill, I'd like it (be soft on deadline, though :) )
<bhill> we can look for a co-editor - that's usually a good idea, anyway
<gioma1> bhill, you?
<bhill> I'd be willing to do it, but have to consult w/w3c staff on whether that is a conflict with my job as co-chair
<bhill> so we are going to break for lunch for the moment
<bhill> I think we should summarize this on the list, make a proposal
<bhill> and I'd like to propose gioma1 as an initial editor, and find another co-editor
<bhill> I think a browser person might be a better choice than myself since they'd know the guts of the implementation details
<bhill> but let's solicit on the list. David Huang might also be a better choice than I if he's free.
<bhill> thanks very much, Giorgio.
<gioma1> bhill, my pleasure
<bhill> we're going to be doing test development following lunch, so you can get some sleep if it's' that time of day there.
<scribe> scribe: bhill
<tanvi> i'm working on the csp tests
<puhley> I am working on converting CGIs to PHP. I started on the bottom of the list and I am working my way back up.
<odinho> Ms2Ger's testharness.js testrunner
<odinho> RRSAgent: draft minutes
<puhley> I am working on access-control-sandboxed-iframe-denied.cgi, access-control-sandboxed-iframe-allow.cgi, and access-control-basic-whitelist-response-headers.cgi
<gopal> CORS has similar tests in opera and webkit folder. Our goal is it consolidate the tests and bring one set of tests to cors1.0 folder.
<gopal> I am working on testRunner, this will help us run all the rest with one click.
<odinho> I'm working on opera/js/basic.htm I*m removing it from using resources/cors-headers.php, because I just want all the tests to use cors-makeheader.php instead.
<puhley> Moving on to access-control-sandboxed-iframe-denied-without-wildcard.cgi
<odinho> I can review stuff if anyone wants.
<gopal> apt-get install hgview if you want some visualization of hg repo
<gopal> Try out the testRunner
<gopal> hg pull, you should have webappsec/tests/testRunner
<gopal> in your vm, add a symlink, ln -s /home/webappsec/tests/testRunner
<gopal> then http://www.w3c-test.org/testRunner/index.html
<gopal> I assume you have www.w3c-test.org in your /etc/hosts.
<gopal> If you add your .html file to MANIFEST, testRunner will pick it up automatically.
<odinho> If someone wants to help me with converting sync tests to async ones. THat'd be A+. Just ask, I'll point you to places to start.
<odinho> Hmmm. Actually CORS DOES work with Firefox(!), but withCredentials does not. Wat?
<odinho> Anyone know anything?
<gopal> For testing we should be using the following hosts and ports:
<gopal> The following are "live" e.g. for testing:
<gopal> The following ports are "live" e.g. for testing:
<gopal> source http://www.w3.org/2008/webapps/wiki/Testing_Requirements
<gopal> Add these hosts to your /etc/hosts and /etc/apache2/ports.conf
<tanvi> hg push is giving me a connecction timeout