[whatwg] Security attacks on local storage
http://research.zscaler.com/2009/02/practical-example-of-cssqli-using.html http://it.slashdot.org/article.pl?sid=09/02/19/2055210 - d.
Re: [whatwg] Security attacks on local storage
On Fri, 20 Feb 2009 12:36:32 +0100, David Gerard dger...@gmail.com wrote: http://research.zscaler.com/2009/02/practical-example-of-cssqli-using.html http://it.slashdot.org/article.pl?sid=09/02/19/2055210 The subject line is rather misleading. It should be pretty clear that if a website is hacked in some way (e.g. XSS) data is exposed to the attacker. This is nothing new however. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Captions, Subtitles and the Video Element
Greg Millam wrote: * All timed text tracks encoded in the video file are added to the list, as an implicit caption element. I'm not entirely sure what you mean, but I don't think implying a new element in the HTML based on text tracks within the media file is a good idea, and nor is it necessary. Instead, the UA just needs to obtain a list of available text tracks by combining those embedded within the media file with those linked to from the HTML, and make them all available to the user. * Caption tags, when displayed, count as span class=caption.../span unless they have style associated with them (uncommon). So they can be tweaked via CSS. Whether by the author or overridden by useragent. I do not understand what you mean here. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[whatwg] Clickjacking and CSRF
In reply to Ian Hickson's call for comments from vendors[1], I wasn't subscribed at the time, so sorry for messing up thread status. We agree that we need a solution quickly, and we are working on it. As IE has already implemented it's own header, the most pragmatic route would be to extend that to make it safe, and use that as a temporary stop gap while we work on a long term solution. It would be good to have a public reference spec for both, to ensure interoperability. This reply therefore contains two parts, a discussion on the x-frame-options header, and some thoughts on the larger picture. The x-frame-options header: === This idea will work as a very specific workaround for clickjacking. It requires Web authors to opt-in, so browser vendors need to act in unison. We therefore plan to implement the same header as Microsoft has proposed, as well as to release a testsuite for this header. A couple of points regarding the implementation: We would prefer not to allow this as a meta tag, for several reasons: * By the time the meta reaches the client, the user might already have interacted with the document and clicked somewhere or XSS flaws might already have been exploited, so it gives a false sense of security. An attacker might be able to influence the loading time of the embedded document. * Documents that flicker, first display contents, and later display a warning are confusing to users. Waiting to show contents until the entire document has loaded would severely impact performance on existing web pages, and is not an option. * Meta tags cannot be included in many resources, for instance images and (most) objects. * Meta tags would not work for some types of protection, for instance for resources that redirect when not logged in, and display a page otherwise - in such cases an attacker is often trying to check if a user is logged in to a service, so a convincing spoof against that service can be launched. Supporting meta headers might therefore give web authors a false sense of security. Every cross-domain resource must be checked for the header. Imagine the following scenario: Amazon allows an iframe (A) ad, which can script itself, but not the parent page. The ad displays some game, like how many pushups can you do?. The ad hides an amazon checkout page in an iframe (B), using clickjacking techniques. If iframe B is not checked against the XSRF header, clickjacking can still occur. Note that iframe B is not cross-domain to the top page, only to its parent. A domain might have some resources that have liberal CSRF rules, and some that have strict rules. To ensure that iframe B cannot be pointing to a resource with liberal rules, which in turn points to an iframe (C) with strict rules, resources have to be checked against every ancestor all the way to the top document. data: and javascript: URIs (as well as any other domain-less protocols) must be given the domain of their embedder (if any), in order to be checkable against the XSRF header. Redirect handling must be taken into account, every step in the redirect chain must be individually checked against the header, and redirection stop if the resource doing the redirect would not be allowed in a frame. For the purpose of interoperability, the spec should state explicitly what same-origin vs third party means. * Port: Over https, different ports can mean different certificates and thus servers with varying security levels. It might be prudent to differentiate on port. * Protocol: One might want to allow https in https, but not http frames inside https. Differentiating on protocol might be wise. * Sub-domains: Sub-domains should explicitly be mentioned not to be same-origin. The disadvantage to differentiating between ports and protocols is that one would require additional header options in order to be able to include them in a server's policy. The elements it blocks should be explicitly listed, frame, iframe, object, applet, embed, as well as other elements that allow scripting. A long term solution Regarding clickjacking, we would like to see the problem in a larger context. Clickjacking is a type of CSRF attack, of which there are several. * Clickjacking/cross-framing - where cross-site content is so obscured the user thinks he is interacting with content from a different site. * Cross-posting - where one site can post data to another site and change the status of the user on the site. Typically many home routers are vulnerable to this, a POST to 192.168.1.1/ChangeDNSAddress could potentially change the setup of the user. Cross-posting includes any other non-indempotent methods such as PUT and DELETE. * Cross-authentication - where one site can request data from another site, and that request is sent with authentication tokens. An example would be a bank which redirects to the login page when not logged in, and shows content otherwise, and the
Re: [whatwg] Clickjacking and CSRF
Sigbjørn Vik wrote, On 20/02/2009 15.46: There is currently little protection against clickjacking, the x-frame-options is the first attempt. Nope, it's the second and weakest: http://hackademix.net/2008/10/08/hello-clearclick-goodbye-clickjacking/ http://noscript.net/faq#clearclick -- Giorgio Maone http://hackademix.net
Re: [whatwg] Clickjacking and CSRF
On Fri, 20 Feb 2009 16:00:09 +0100, Giorgio Maone g.ma...@informaction.com wrote: Sigbjørn Vik wrote, On 20/02/2009 15.46: There is currently little protection against clickjacking, the x-frame-options is the first attempt. Nope, it's the second and weakest: http://hackademix.net/2008/10/08/hello-clearclick-goodbye-clickjacking/ http://noscript.net/faq#clearclick I stand corrected. I was thinking too narrow-mindedly, from a browser vendor perspective. Frame busting is another existing alternative. -- Sigbjørn Vik Quality Assurance Opera Software
Re: [whatwg] Clickjacking and CSRF
Sigbjørn Vik wrote on 2/20/2009 8:46 AM: One proposed way of doing this would be a single header, of the form: x-cross-domain-options: deny=frame,post,auth; AllowSameOrigin; allow=*.opera.com,example.net; This incorporates the idea from the IE team, and extends on it. Have you taken a look at ABE? http://hackademix.net/wp-content/uploads/2008/12/abe_rules_03.pdf For cross-domain resources, this means that a browser would first have to make a request with GET and without authentication tokens to get the x-cross-domain-options settings from the resource. If the settings allow, a second request may be made, if the second request would be different. The result of last request are handed over to the document. Have you considered using OPTIONS for the pre-flight request, similar to how Access Control for Cross-Site Requests does it? http://www.w3.org/TR/access-control/#cross-site2 - Bil
Re: [whatwg] How to remember VIDEO tag mute setting.
Am Mittwoch, den 18.02.2009, 03:05 -0400 schrieb Biju g...@il: I dont want to mute volume of computer because I want to hear sounds from other running apps. So I only mute the volume on the VIDEO tag control while testing Firefox nightly. But the irritating thing is I have to do it for every page visit, as Firefox dont remember my mute setting. I'd suggest filing a bug within Mozilla's Bugzilla. (CC'ed the video implementor) Cheers -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] Security attacks on local storage
On Fri, 20 Feb 2009, David Gerard wrote: http://research.zscaler.com/2009/02/practical-example-of-cssqli-using.html http://it.slashdot.org/article.pl?sid=09/02/19/2055210 As Anne noted, this appears to be a bogus claim. I do not intend to change the spec here. If anyone sees an actual localStorage threat here, please let me know. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Captions, Subtitles and the Video Element
On 20.2.09 05:54, Lachlan Hunt wrote: Greg Millam wrote: * All timed text tracks encoded in the video file are added to the list, as an implicit caption element. I'm not entirely sure what you mean, but I don't think implying a new element in the HTML based on text tracks within the media file is a good idea, and nor is it necessary. Instead, the UA just needs to obtain a list of available text tracks by combining those embedded within the media file with those linked to from the HTML, and make them all available to the user. I think I agree with this; that caption or whatever would magically appear in the DOM as media data is downloaded (and in an unpredictable manner, from the point of view of the page author) seems baroque and unexpected. Jeff
