Re: [whatwg]
They would be great additions, thanks. 2. scriptwillexecute/scriptdidexecute events Notice that Opera has a richer set of eventsof this kind (exsposed to "privileged" User Scripts, though, AFAIK), allowing for much more control over the executing scripts, no matter if from script elements, event handlers or URLs: http://www.opera.com/docs/userjs/specs/#evlistener Cheers -- G Jonas Sicking wrote, On 17/08/2010 6.15: Hi All, I'd like to propose a couple of simple features to make
Re: [whatwg] img as a layout tool to describe the displayed region of a CSS background-image
I believe the spec is trying to stigmatize old-times spacer images used to layout other HTML elements, like which are overly ugly and meaningless now that there's nothing you can't layout by CSS. -- G Ingo Chao wrote, On 28/04/2010 13.31: http://dev.w3.org/html5/spec/Overview.html#the-img-element "The img must not be used as a layout tool. In particular, img elements should not be used to display transparent images, as they rarely convey meaning and rarely add anything useful to the document." An img with a given transparent image for src cuts an area of a sprite. ( = img as a layout tool to describe the displayed region of a CSS background-image.) Is this usage of the img element considered invalid (non-conforming)? Thanks.
Re: [whatwg] fyi: Strict Transport Security specification
Hi, fwiw, NoScript 1.9.8.9 (next stable release, to be published during the incoming week), will support STS according to the current specification. I had heard just yesterday from a leader Asian e-commerce player who wants to deploy it as soon as possible (even in the beginning of October). I'm chatting with their security staff right now, and they're enthusiast of this development (especially of WebKit support). Cheers -- Giorgio Maone http://hackademix.net http://noscript.net =JeffH wrote, On 20/09/2009 1.59: Of possible interest to public-html@ & whatwg@ denizens... [apologies for duplication] --- Forwarded Message Date:Fri, 18 Sep 2009 18:00:50 -0700 From:=JeffH To: public-weba...@w3.org cc: Jeff Hodges , Adam Barth , Collin Jackson Subject: fyi: Strict Transport Security specification Hi, We wish to bring the following draft specification to your attention.. Strict Transport Security (STS) <http://lists.w3.org/Archives/Public/www-archive/2009Sep/att-0051/draft-hodges- strict-transport-sec-05.plain.html> It specifies a refined approach to that described by Jackson and Barth in.. ForceHTTPS: Protecting High-Security Web Sites from Network Attacks https://crypto.stanford.edu/forcehttps/ An experimental implementation of STS will be appearing in the Google Chrome dev channel in the not-too-distant future.. Google Chrome 4.0.211.0 (dev channel) Sid Stamm (of Mozilla) has a Firefox extension presently implementing an earlier revision of this specification (a soon-to-appear v2.0 of the extension will implement the present spec version).. Force-TLS 1.0.3 https://addons.mozilla.org/en-US/firefox/addon/12714 Sid also discusses this approach in this blog post.. Locking up the valuables: Opt-in security with ForceTLS <http://blog.mozilla.com/security/2009/07/27/locking-up-the-valuables-opt-in-se curity-with-forcetls/> We are interested in bringing this work to W3C WebApps Working Group as a Recommendation-track specification. We are willing to license it under W3C terms, we understand that it may change due to implementer or public feedback, and that should it be of interest to other implementors, we're willing to contribute to editorial and test suite efforts. We're looking forward to the WebApps WG's feedback and comments. Thanks, =JeffH PayPal InfoSec Team Collin Jackson Carnegie Mellon University Adam Barth University of California Berkeley --- End of Forwarded Message
Re: [whatwg] cross-domain scrollIntoView on frames and iframes
Peter Kasting wrote, On 05/04/2009 0.54: On Sat, Apr 4, 2009 at 12:56 PM, timeless wrote: sounds like a security nightmare. Can you be less vague? We've had a number of security people vet this already, so specific complaints would be very helpful. PK It would make clickjacking attacks more precise, by exactly positioning the frame content where the attacker wants it to be. Not that you cannot already be pixel-precise by using absolute positioning inside an overflow: hidden div... Let's say it would make them even more script-kiddies friendly. -- Giorgio Maone
Re: [whatwg] Clickjacking and CSRF
On Fri, 20 Feb 2009 19:36:47 +0100, Bil Corry wrote: 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 I am not quite certain what you are referring to, the document is a ruleset for how to express what is allowed and disallowed. Do you mean that clients should be using a URL list, or that servers should be using this particular grammar to decide which headers to send with their URLs? For a domain wide policy file a document like this might work well though. ABE is meant to be configured in 3 ways: 1. With user-provided rules, deployed directly client-side 2. With community-provided rules, downloaded periodically from a trusted repository 3. As a site-wide policy deployed on the server side in a single file, much like crossdomain.xml See http://hackademix.net/2008/12/20/introducing-abe/ and especially this http://hackademix.net/2008/12/20/introducing-abe/#comment-10165 comment about site-provided rules and merging. -- Giorgio Sigbjørn Vik wrote, On 23/02/2009 11.42: On Fri, 20 Feb 2009 19:36:47 +0100, Bil Corry wrote: 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 I am not quite certain what you are referring to, the document is a ruleset for how to express what is allowed and disallowed. Do you mean that clients should be using a URL list, or that servers should be using this particular grammar to decide which headers to send with their URLs? For a domain wide policy file a document like this might work well though. 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 Good point. Trying to use OPTIONS for existing servers might break them, a GET might be safer. Then again, OPTIONS shouldn't break anything, GETs might have side-effects where OPTIONS don't, and an OPTIONS reply typically has a much smaller payload than a GET reply. In the case of a reply to a pre-flight request where the user agents has cookies but the server replies that contents are the same with or without cookies, an OPTIONS request would require two requests, a GET only one. OPTIONS is probably more in the spirit of HTTP though. Either could work, the idea is the same. Which would be better would have to be researched empirically, but OPTIONS might be the better candidate.
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] Dealing with UI redress vulnerabilities inherent to the current web
Bil Corry wrote, On 18/02/2009 21.31: Boris Zbarsky wrote on 2/18/2009 9:27 AM: And really no different from: if (window != window.top) window.top.location.href = window.location.href; in effect, right? This last already works in all browsers except IE, which is presumably why IE felt the need to add another way to do it. Supposedly, a future release of IE8 will fix this (see Issue #4): http://ha.ckers.org/blog/20081007/clickjacking-details/ I doubt we'll see a "fix" for ;) -- G
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
Ian Hickson wrote, On 18/02/2009 12.43: 3) Add an on-by-default mechanism that prevents UI actions to be taken when a document tries to obstruct portions of a non-same-origin frame. By carefully designing the mechanism, we can prevent legitimate uses (such as dynamic menus that overlap with advertisements, gadgets, etc) from being affected, yet achieve a high reliability in stopping attacks. This seems difficult to get right in practice, and browser vendors seem reluctant to go down this road. Incidentally, NoScript's ClearClick is a working implementation of this "difficult" approach, effective also with same-origin plugin content (like in the original Clickjacking PoC by RSnake & Grossman). http://noscript.net/faq#clearclick -- G Ian Hickson wrote, On 18/02/2009 12.43: On Thu, 25 Sep 2008, Michal Zalewski wrote: Problem definition: a malicious page in domain A may create an IFRAME pointing to an application in domain B, to which the user is currently authenticated with cookies. The top-level page may then cover portions of the IFRAME with other visual elements to seamlessly hide everything but a single UI button in domain B, such as "delete all items", "click to add Bob as a friend", etc. It may then provide own, misleading UI that implies that the button serves a different purpose and is a part of site A, inviting the user to click it. Although the examples above are naive, this is clearly a problem for a good number of modern, complex web applications. Proposed fixes: 1) Create a HTTP-level (or HTTP-EQUIV) mechanism along the lines of "X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes" that permits a web page to inhibit frame rendering in potentially dangerous situations. Pros: - Super-simple Cons: - "Opt-in", i.e. currently vulnerable sites remain vulnerable unless action is taken - Can't be used for cases where IFRAME content mixing has a legitimate purpose (for example, cross-domain gadgets, certain types of mashups) In particular, this breaks Image Search tools from various vendors as well as navigation aids like the Reddit toolbar. - Adds yet another security measure (along with cross-domain XHR, MSIE8 XSS filters, MSIE P3P cookie behavior, Mozilla security policies) that needs to be employed correctly everywhere to work - which is very unlikely to consistently happen in practice - Along with the aforementioned security features, threatens to result in HTTP header or HTML HTTP-EQUIV size bloat that some sites may care about. This solution is what IE8 has apparently chosen to use. Specifically, IE8 will recognise an HTTP header or pragma directive with the name "X-Frame-Options", and will process it as follows: If the value is a case-insensitive match for "deny" and the browsing context being navigated is not a top-level browsing context, replace the document with a UA-defined error message. If the value is a case-insensitive match for "sameorigin" and the browsing context being navigated is not a top-level browsing context and the origin of the top-level browsing context is not the same as the origin of the document in question, replace the document with a UA-defined error message. (The "sameorigin" rule seems like it should check all ancestor browsing contexts, not just the top-level one, because otherwise a site X, e.g. images.google.com, showing a frame with a document on site Y, e.g. hostile.example.com -- which might happen e.g. on something like Google Image Search -- would be able to embed another page from site X, e.g. your image search preferences, and do clickjacking on it.) This feature could also be extended to apply to other resources, e.g. scripts, images, style sheets, fonts, to prevent them from being used cross-origin. This would help, e.g., with securing scripts that contain private data. 2) Add a document-level mechanism to make "if nested else " conditionals possible without Javascript. One proposal is to do this on the level of CSS (by using either the media-dependency features of CSS or special classes); another is to introduce new HTML tags. This would make it possible for pages to defend themselves even in environments where Javascript is disabled or limited. This is an interesting idea, though it would be subsumed by Hallvord's suggestion with Origin given below, in conjunction with idea 1 above in the absence of Origin information. 3) Add an on-by-default mechanism that prevents UI actions to be taken when a document tries to obstruct portions of a non-same-origin frame. By carefully designing the mechanism, we can prevent legitimate uses (such as dynamic menus that overlap with advertisements, gadgets, etc) from being affected, yet achieve a high reliability in stopping attacks. This seems difficult to get right in practice, and brow
