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