Re: [whatwg] Modifying the URL inside beforeunload event
I believe I have a legitimate use-case (described in comment #9) for needing to change the URL in beforeunload. I am probably at least partly to blame for the browsers not letting you do that - I reported several onbeforeunload attacks some 8 years ago. Sorry!:-) In general, there is a security-driven desire to prevent a website from trapping visitors and not allowing them to navigate away. This not just a matter of nuisance attacks, but when employed in a clever way, can be a powerful tool for phishing if you can convince the user to type in a known URL and then spoof the page transition. If we end up allowing navigation to be aborted or modified from within unload-related events, we need to keep that in mind. /mz
Re: [whatwg] Modifying the URL inside beforeunload event
It's probably OK to replace the URL of the previous page if it otherwise doesn't interfere with the ongoing navigation. The old attacks predated the pushState / replaceStates API altogether. /mz On Sun, Nov 2, 2014 at 1:43 PM, cowwoc cow...@bbs.darktech.org wrote: On 02/11/2014 12:28 PM, Michal Zalewski wrote: I believe I have a legitimate use-case (described in comment #9) for needing to change the URL in beforeunload. I am probably at least partly to blame for the browsers not letting you do that - I reported several onbeforeunload attacks some 8 years ago. Sorry!:-) In general, there is a security-driven desire to prevent a website from trapping visitors and not allowing them to navigate away. This not just a matter of nuisance attacks, but when employed in a clever way, can be a powerful tool for phishing if you can convince the user to type in a known URL and then spoof the page transition. If we end up allowing navigation to be aborted or modified from within unload-related events, we need to keep that in mind. /mz Hi Michal, I had a feeling this was security related :) Correct me if I'm wrong, but don't the attacks you mentioned rely upon access to history.back()/forward()? Would it be safe to allow history.replaceState() while forbidding the other two? Meaning, we would allow a page to rewrite its own address but not other pages' addresses. Gili
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
input writeonly type=password I think that one huge problem with this is that the attacker will have many other, indirect ways to get the value even if you protect direct access to the field. Two most obvious options include: 1) Change the action value for the form to point to evil.com, where evil.com is in attacker's control, 2) Change the action of the form to GET while keeping the same method, let it submit, and then examine location.search. 3) Change the action value of the form and the name of the password field so that the posted data is interpreted by the server as an attempt to, say, post a comment. I worry that there's actually more, and that a lot of nasty taint tracking heuristics would be required to make it go away. /mz
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
1) Change the action value for the form to point to evil.com, where evil.com is in attacker's control, I hope that this is mitigated by the `form-action` CSP directive, which allows the site to control the valid endpoints for form submission, and `connect-src`, which allows the same for XHR, EventSource, WebSockets, etc. 3) Change the action value of the form and the name of the password field so that the posted data is interpreted by the server as an attempt to, say, post a comment. Again, mitigated (but by no means avoided) by path restrictions on the `form-action` CSP directive. Fair enough - although I worry that the likelihood of people using this in conjunction with tightly-scoped per-document CSP (versus the far more likely scenario of just having a minimal XSS-preventing site-wide or app-wide policy that will definitely not mitigate #3 and probably do nothing for #1) are pretty slim. We're effectively adding a mechanism that works well only if you remember about a fairly counterintuitive gotcha, which realistically means that it won't be used correctly something like 90%+ of the time. Cheers, /mz
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
Fair enough - although I worry that the likelihood of people using this in conjunction with tightly-scoped per-document CSP (versus the far more likely scenario of just having a minimal XSS-preventing site-wide or app-wide policy that will definitely not mitigate #3 and probably do nothing for #1) are pretty slim. In fact, the XSS-preventing part is probably a stretch. Facebook and Twitter are often mentioned as the two most significant customers for CSP, but both use unsafe-inline and unsafe-eval. On top of that, note that #3 is not defeated by origin-scoped rules - you need to specify full paths. Honestly, if we're creating a mechanism that implies that a degree of protection is provided for password fields, we should either make it work on its own, *or* at the very minimum require a CSP with form-action specified, and otherwise warn or better yet, break fields flagged as writeonly. /mz
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
So I might have started this on the wrong foot, but let's consider the broader threat model. What do we want to protect against? 1) XSS stealing the passwords / CC numbers entered by the user manually? This is probably not possible with this proposal; the evil payload may construct a form where the writeonly attribute is not set. 2) XSS stealing the passwords entered by the password manager? To do this, I feel that we need a taint-tracking system coupled with a password manager that remembers that some passwords can go only into writeonly fields, and which URLs and methods they need to be submitted to. The CSP solution + blocking GET feels like a crutch that won't work in practice; my main concern is that writing site-wide policies is hard as-is, and that the likelihood of well-scoped per-page policies, especially with path granularity, is low. But if we go the CSP route, breaking writeonly fields if form targets are not policed may be the best we can do. (Also note that my attack #3 will work simply if XSRF tokens are user- but not action-bound, which is a common pattern.) I also expect many other corner cases to crop up when others look at the implementations later on. 3) Regular compromised renderers / malware stealing the data manually entered or automatically populated by the browser? Not doable. 4) Future Chrome origin-bound sandboxed renderers stealing the data manually entered by the user? Probably not doable, by analogy with #1. 5) Future Chrome origin-bound sandboxed renderers stealing the data auto-populated by the password manager? Feels like for this, we need taint tracking; otherwise, the renderer can ask for the password under false pretenses, perhaps after loading a sub-page with different or no CSP rules. We could try giving the renderer a token that is converted to a password on an ongoing request by the network stack, but there is no way to confirm that the request is being made to the right destination and in good faith. ... The reason why I was previously skeptical of proposals of write-only fields is pretty much because the threat model is so complicated and the solutions are so fragile - but maybe I'm in the wrong on this. /mz
Re: [whatwg] AppCache Content-Type Security Considerations
Yup, from the perspective of a significant proportion of modern websites, MIME sniffing would be almost certainly a disaster. I'm not suggesting sniffing, I'm suggesting having a single well-defined algorithm with well-defined fixed signatures. For formats that don't have signatures, this doesn't work, obviously. We probably can't support a well-defined algorithm for detecting documents that have distinctive signatures while safely supporting formats that don't have them (because there is always a possibility that the non-structured format with user-controlled data could be used to forge a signature).
Re: [whatwg] AppCache Content-Type Security Considerations
We probably can't support a well-defined algorithm for detecting documents that have distinctive signatures while safely supporting formats that don't have them (because there is always a possibility that the non-structured format with user-controlled data could be used to forge a signature). It can be argued that the burden of detecting this should be placed on the server before sending out the response, but this would be a fairly major shift in what is currently assumed to be the web security model (with detrimental effect on tens of thousands of existing web apps); on top of that, it would cripple some legitimate uses of the non-structured formats: for example, there may be perfectly legitimate reasons why a text/plain or text/csv document also matches a signature for HTML. In general, in the past, in pretty much every single instance where browsers tried to second-guess Content-Type or Content-Disposition headers - be it through sketchy proprietary content-sniffing heuristics or through well-defined algorithms - this ended up creating tons of hard-to-fix security problems and introduced new burdens for web developers. It looks elegant, but it's almost always a huge liability. I think that most or all browsers are moving pretty firmly in the other direction, enforcing C-T checking even in situations that historically were off-limits (script, style, object, etc), based on strong evidence of previous mishaps; to the extent that the spec diverges from this, I suspect that it will be only a source of confusion and incompatibility. /mz
Re: [whatwg] AppCache Content-Type Security Considerations
I disagree. Much of the Web actually relies on this today, and for the most part it works. For example, when you do: img src=foo ... ...the Content-Type is ignored except for SVG. Well, img is actually a fairly special case of content that is difficult for attackers to spoof and that can't be easily read back across domains without additional CORS headers. But I believe that in Chrome and in Firefox, C-T checks or other mitigations have been recently added at least script, link rel=stylesheet, and object / embed, all of which lead to interesting security problems when they are used to load other types of documents across origins. Similar changes are being made also for a couple of other cases, such as a download. /mz
Re: [whatwg] AppCache Content-Type Security Considerations
I think that's Ian's point, that for those file types, we need CT, but for others, like manifest files, and image and plugins we shouldn't need. If we take this route, I think we'd be essentially making sure that many web applications that are safe today will gradually acquire new security bugs out of the blue as the UA magic signature detection logic is extended in the future (as it inevitably will - to account for new plugins, new formats with scripting capabilities or other interesting side effects, etc). An out-of-band signalling mechanism has far superior security properties compares to an in-band one, given how many if not most web apps are designed today. It may be that they are designed the wrong way, but the security rules were never particularly clear, and serving content off-domain added a lot of complexity around topics such as auth, so I think it's best to be forgiving and accommodate that. The examples of CSV exports, text documents, and several more exotic things aside, most JSONP APIs give the attacker broad control over the first few bytes of the response. /mz
Re: [whatwg] Zip archives as first-class citizens
Two implementation risks to keep in mind: 1) Both jar: and mhtml: (which work or worked in a very similar way) have caused problems in absence of strict Content-Type matching. In essence, it is relatively easy for something like a valid user-supplied text document or an image to be also a valid archive. Such archives may end up containing files that the owner of the website never intended to host in their origin. 2) Both schemes also have a long history of breaking origin / host name parsing in various places in the browser and introducing security bugs. /mz
Re: [whatwg] Priority between a download and content-disposition
This is about how the Web works, not browser UIs. If I click a link on www.computerviruses.com, and it prompts me to save a file to disk, I make my decision of what to do with the file based on the context of the link I clicked. In my experience, the web is a lot more complicated than that. There are many interesting corner cases here, including but not limited to downloads initiated by other documents / windows (say, http://lcamtuf.coredump.cx/fldl/). With content sniffing, we have learned the hard way that second-guessing the intent of the owner of a server in terms of the way the content should be interpreted by the browser will almost always bite back. I think we're making the same mistake here (and in several other areas, too). /mz
Re: [whatwg] Priority between a download and content-disposition
I think I raised this on several other threads; in essence, countless websites permit users to upload constrained file formats, such as JPEGs or GIFs used as profile images. With content sniffing attacks, we've already seen that it's relatively trivial for attacker to make files that are both valid images, and also pretend to be some other, more dangerous file format. Because many browsers prominently display the origin of a download and it's the only security indicators users really have, I think it's harmful to permit something like: a href='http://www.facebook.com/.../user_profile_image.jpg' download='important_facebook_update.exe' In fact, given the security problems it creates and the fact that they will be difficult to fully mitigate without establishing some sort of a new 'opt-out' mechanism akin to X-Content-Type-Options (to which most of the Internet will remain oblivious), I'm not entirely sure if the value of download= (which seems dubious, TBH) justifies the risk. /mz
Re: [whatwg] Priority between a download and content-disposition
Downloads are associated with the site the link is on, not the domain the resource is served from. If users click a download link and the file comes from s3.amazonaws.com, they didn't come from Amazon; they came from your page. I don't believe that's the case in most browser UIs. In fact, I don't think it should be. For example, if I search for something on google.com, and this takes me a page that serves Content-Disposition: attachment; filename=impotant_google_update.exe, we don't want to imply that Google endorsed that, right? /mz
Re: [whatwg] [mimesniff] Treating application/octet-stream as unknown for sniffing
There are substantial negative security consequences to sniffing content on MIME types that are commonly used as default fallback values by web servers or web application developers. This includes text/plain and application/octet-stream. /mz
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
Any feedback on this revised approach?
My vague concern is that the separation is a bit fuzzy, beyond saying
that window.opener will be null... if that's the only guaranteed
outcome, then maybe that should be spelled out more clearly? The
degree of separation between browsing contexts is intuitive in the
case of Chrome, given the underlying implementations, but will it be
the same for Internet Explorer or Firefox or Safari?
Let's assume that there is no Chrome-style process isolation, and that
this is only implemented as not giving the target=_unrelated document
the ability to traverse window.opener. If the document's opener lives
in an already-named window (perhaps unwittingly), it won't be
prevented from acquiring the handle via open('',
'name_of_that_window'), right? That may be unexpected.
The same goes the other way - the spec subtly implies that because
window.open('foo', '_unrelated') returns null, the opener will not be
able to mess with the opened window, but that's not guaranteed given
that the reference may be leaked by other means, right?
/mz
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
Several questions: 1) How would this mechanism work with named windows (which may be targeted by means other than accessing opener.*)? In certain implementations (e.g., Chrome), the separation in this namespace comes free, but that's not given for other browsers. There are ways in which the attacker could, for example, load GMail in a window that already has window.name set. 2) What would be the behavior of a rel=unrelated link with target= pointing to an existing iframe on the page? Could it work in any useful way? 3) What about the same with target= pointing to an existing window? Would that window become isolated? What would happen to the 'back' button / history.back()?
Re: [whatwg] Proposal: location.parentOrigin
Tab suggests (on IRC) that this should just be tied to sandbox=, which seems reasonable at first blush. Sandbox is opt-in (which means we'd start revealing origins in existing settings without a warning); and has other serious constraints which preclude it from some existing use cases (e.g., no plugins). /mz
Re: [whatwg] Proposal: location.parentOrigin
I can think of some fringe scenarios where disclosing parent origins may be somewhat undesirable. One example may be a double-bagged advertisement, where the intent is to not tell the advertiser about the top-level page the ad is embedded on (visited site - iframe pointing to the ad provider site - iframe with embedded advertiser content). Not sure if there's anything more convincing, but perhaps it's desirable to obtain constent from parents before populating the array (e.g. iframe discloseorigin=yes). If a member of the chain doesn't consent, the corresponding element of the array is null / undefined / an empty string? /mz
Re: [whatwg] Proposal: location.parentOrigin
In fact, in the vein of opt-in disclosure perhaps something like
discloselocation={none|origin|full} would be more convenient - in
which case, you get something like
window.parentLocations[n].{origin|href|hash|...}
I constantly fear that origin scoping for security mechanisms is too
coarse-grained in many use cases, because the complexity of what lives
in any single origin is growing pretty rapidly. Sites put
attacker-controlled content inside framed gadgets or advertisements,
and can't be reasonably expected to understand that if such a frame is
navigated to in a particular way, it may circumvent an origin-scoped
check.
/mz
Re: [whatwg] DND: proposal to expose origin
The security problems with drag-and-drop are significantly more pronounced than just the banking scenario you are describing. Because the drag-and-drop action is very similar to other types of legitimate interaction (e.g., the use of scrollbars), many practical content-stealing attacks have been demonstrated (e.g., theft of anti-XSRF tokens). Consequently, I believe that Chrome disallows drag-and-drop between non-same-origin frames completely, and Firefox is planning to do the same (https://bugzilla.mozilla.org/show_bug.cgi?id=605991). I strongly suspect that given the broad and serious exposure, I think this should be the default; with certain origins being able to specify that they want to allow cross-origin drag-and-drop, perhaps leveraging this API. /mz
Re: [whatwg] meta name=referrer
It would be nice if this could be done orthogonally to rel=noreferrer, and in a way that's link-specific instead of global to the whole page; for example, a rel=originreferrer, a rel=alwaysreferrer. There is a fairly strong security benefit of policing it on document- or even origin-level: it's exceedingly easy to miss an outgoing link or a Referer-sending subresource (including img, iframe, link rel=...) otherwise. It's roughly the same reason why we have CSP, even though policing the markup is theoretically possible without it. /mz
Re: [whatwg] Proposal for improved handling of '#' inside of data URIs
What about javascript: URLs?
Right now, every browser seems to treat javascript:alert('#') in an
intuitive manner.
This likely goes beyond data: and javascript:, so I think it would be
useful to look at it more holistically.
/mz
Re: [whatwg] Proposal for improved handling of '#' inside of data URIs
[ Julian Reschke ] Observation: javascript: IMHO isn't a URI scheme (it just occupies a place in the same lexical space), so maybe the right thing to do is to document it as historic exception that only exists in browsers. In one of its modes, it's roughly equivalent to data: (javascript:h1foo), so I'm not sure the distinction is really that strong. Maybe. Or it makes sense to do it one at a time :-). My only concern is that treating them separately had some funny side effects in the past - for example, right now, the origin inheritance for documents created from about:blank, data:.., and javascript:... URLs are completely different in current implementations, for no good reason. [ Daniel Holbert ] However, fragment identifiers don't have any special significance in javascript: URIs, so the javascript: handler ends up requesting the full URI, ignoring any distinction between the pre-# and post-# part. In the above use case, you could imagine # having the same purpose as for data, in principle. /mz
Re: [whatwg] input type=password... restrict reading value from JS?
For the last 10+ years, password inputs have been accessible from scripts, with nary a complaint. If I have this code: Denying access to password fields from JavaScript is actually a somewhat interesting security enhancement when you consider the behavior of password managers. Right now, if you exploit an XSS on https://www.mybank.com, you can navigate the browser to the login form, wait for the user name and password field to be autocompleted, grab the data, and effectively turn your transient access into long-lived credentials theft. Unfortunately, the problem is not that easy to fix: denying access to the field does not prevent the attacker from changing the form submission URL after autocompletion to achieve the same; or even simply changing method from POST to GET, setting target=foo, and leveraging same-origin access to the post-submit page to read back the password-containing URL. /mz
Re: [whatwg] input type=password... restrict reading value from JS?
How about deleting the value if the input type is changed away from the secure password input type AND that the secure password can only be submitted to a similar URI. Right now, for interoperability, password managers allow a good amount of fuzziness when matching forms, and I do not believe they pay a lot of attention to form method, allow the URL and fields to change slightly, etc. So it's hard to tell an XSS-injected password form from the real deal. Instead of a complicated technical solution, some browsers require a distinctive user gesture before autocompleting login forms. But then, other vendors believe that this is unacceptable from usability perspective. /mz
Re: [whatwg] Content-Disposition property for a tags
On Linux you may have comprehensive mailcap lists in /etc, or better yet the filename extension to MIME type mappings used by httpds. Which still don't necessarily map to the behavior of every single file manager; some of them come with their own rules (heck, even mc does that IIRC), some rely on /usr/bin/file. Plus, the solution needs to be portable. It's really non-trivial, and the the current approach taken by Firefox works only in rudimentary cases. /mz
Re: [whatwg] Content-Disposition property for a tags
I don't think the issue raised was about getting people to save files, though. If you can get someone to click a link, you can already point them at something that sets the HTTP C-D header. The origin of a download is one of the best / most important indicators people have right now (which, by itself, is a bit of a shame). I just think it would be a substantial regression to make it possible for microsoft.com or google.com to unwittingly serve .exe / .jar / .zip / .rar files based on third-party markup. Firefox and MSIE display the origin fairly prominently, IIRC; Chrome displays it in some views. But deficiencies of current UIs are probably a separate problem. /mz
Re: [whatwg] Content-Disposition property for a tags
At least in the case of Firefox for that particular case on Windows the filename will be sanitized... Yes, but Firefox is an exception, not a rule; and even that mechanism is very imperfect (it relies on explicit mappings that are not guaranteed to be in sync with other OS components; when downloading a less known MIME type, like image/jpeg2000, the user is still in trouble). /mz
[whatwg] Revising the content handling logic of object and embed
Hi folks, The HTML4 spec said that on object and embed tags, Content-Type overrides type=. All browser vendors implemented a different behavior, however, where type= almost always overrides Content-Type. Plugin vendors, in turn, missed that almost part, built extensive security mechanisms, and promoted use cases where one site can embed Flash movies, PDF documents, simple multimedia, and so on, from another, untrusted source without suffering substantial security consequences. For example, Flash exposes allowScriptAccess, allowNetworking, and allowFullScreen parameters that can be used to sandbox the loaded content: object data=http://somewhere_funny/; type=application/x-shockwave-flash param name=allowScriptAccess value=never param name=allowNetworking value=never param name=allowFullScreen value=never /object People embraced this approach in web discussion forums, on online blogs, etc. Unfortunately, there is the almost part: in some originally undocumented cases, browsers permit the attacker to override explicit type= based on URL file extensions, content sniffing, or Content-Type. This makes the aforementioned popular use case dangerous, because any site that wishes to embed a security-restricted Flash movie may end up embedding a Java applet instead, and Java has unconditional access to the DOM of the embedding page via DOMService. While it can be argued that it's the websites and plugin vendors that are doing it wrong, the issues with HTML4 spec and actual browser behavior contributed to it, and it may be prudent to fix the mess. HTML5 spec makes an attempt to explicitly sanction the current behavior, where neither the embedding nor the hosting party have control over how the content will be displayed, in the specification for the object element. Given the aforementioned situation, I think this is harmful and needs to be revised. In my opinion, the preferred outcome would be to make type= authoritative when specified, or provide an alternative way of ensuring specific routing of the retrieved content on markup level. In addition, to resolve existing problems with non-plugin content being interpreted as plugin data (e.g. http://xs-sniper.com/blog/2008/12/17/sun-fixes-gifars/), it would also be prudent to provide servers a way to demand rendering only if Content-Type provided by the server, and type= in the markup, match. Thoughts? /mz
Re: [whatwg] Lifting cross-origin XMLHttpRequest restrictions?
As suggested above, could a header be required on compliant browsers to send a header along with their request indicating the originating server's domain? Yes, but it's generally a bad practice to release new features that undermine the security of existing systems, and requiring everybody to change their code to account for the newly introduced vectors. Theoretically, GET or OPTIONS should have no side effects, so DoS potential aside, they could be permitted with no special security checks. In practice, much of the Internet uses GET for state-changing actions; or nominally uses POSTs, but does not differentiate between the two in any specific way; plus, the problem of IP auth / Intranet probing remains. Bottom line is, opt-in is offered in several other places; and opt-out solution seems unlikely at this point, I would think? /mz
Re: [whatwg] Lifting cross-origin XMLHttpRequest restrictions?
Servers are already free to obtain and mix in content from other sites, so why can't client-side HTML JavaScript be similarly empowered? I can see two reasons: 1) Users may not be happy about the ability for web applications to implement an unprecedented level of automation through their client (and using their IP) - for example, crawling the Intranet, opening new accounts on social sites and webmail systems, sending out spam. While there is always some ability for JS to blindly interact with third-party content, meaningful automation typically requires the ability to see responses, read back XSRF tokens, etc; and while servers may be used as SOP proxies, the origin of these requests is that specific server, rather than an assortment of non-consenting clients. The solution you propose - opt-out - kinda disregards status quo, and requires millions of websites to immediately deploy workarounds, or face additional exposure to attacks. For opt-in, you may want to look at UMP: http://www.w3.org/TR/2010/WD-UMP-20100126/ (or CORS, if you do not specifically want anonymous requests). 2) It was probably fairly difficult to sandbox requests fully so that they are not only stripped of cookies and cached HTTP authentication, but also completely bypass caching mechanisms (although UMP aims to achieve this). /mz
Re: [whatwg] @sandbox and navigation top
Perhaps we want an allow-frame-busting directive? In the implementation we have an allow-navigation bit that covers navigation |top| as well as window.open, etc. Maybe we want a more general directive that twiddles this bit? I'm wondering if sites want to have control over the type of navigation: navigating the top-level context versus opening a new window? In particular, I am thinking about ads in embeddable gadgets (on social sites, or in places such as Docs, Wave, etc): you do not want the gadget to interfere with the presentation of the page by triggering disruptive and unsolicited top frame transitions (as this could be used for a crude DoS - in fact, IIRC, there is some history along these lines), but you may bey OK with a pop-up ad following a click. /mz
Re: [whatwg] @sandbox and navigation top
Can a frame in @sandbox ever navigation the top-level frame? If not, that would make it hard to use @sandbox to contain advertisements, which want to navigate |top| when the user clicks on the ad. Ads would want to be able to do that, but user-controlled gadgets shouldn't. I suppose the top-level page should be able to specify, and the entire @sandbox chain would need to be traversed to make the call (so that @sandbox included on example.com that is prohibited from messing with the top-level frame can't just create a nested frame without the restriction, and bypass the check). I assume that chain-style checking is already a part of the spec, as we obviously don't want other restrictions to be removed in a similar manner? /mz
Re: [whatwg] some thoughts on sandboxed IFRAMEs
Not escaping is so easily and quickly discovered that I really don't think that's a problem. The same argument could be made for not escaping , but I don't think it's valid in practice - particularly for (hypothetically) constrained input fields. That would be great. I think Adam proposed we have a separate sandbox=... toggle for this. Whether it's on or off by default probably doesn't matter much. Adam's feedback (not quoted here, but in the same thread as the e-mail to which this is a reply) suggests that this is actually a bad idea, so I've not changed this. There are obvious, existing usage cases where sites struggle to prevent automated resource loading across domains - e.g., almost every HTML-supporting mail client; so it strikes me that if we go along with this reasoning because a perfect solution may not exist, we're also effectively saying that what they are doing should not be attempted at all (then what's the alternative? one should probably be a part of HTML5). If there's no HTML, there's no need for a sandbox, so the simplest solution is just to escape the s and s. Which people fail at, big time. There are 50,000+ entries on xssed.com, many of them against big sites presumably developed by skilled developers with the help of sophisticated frameworks - microsoft.com, google.com, amazon.com, ebay.com, etc. It is a really low-effort tweak to accommodate it here, and it may offer a very significant security benefit, so...? Keep in mind that pretty much every web application already needs to safely generate unique, unpredictable tokens - for session identifiers that guard authenticated sessions. If they can't get it right, they are hosed anyway - but problems here are not horribly common, in my experience at least, and web app frameworks do a decent job of helping developers by providing token-generating facilities. Pretty much the same can be said of escaping text. Also, based on Adam's comments, it seems that things aren't really as rosy as all that for token generators. I think the difference is huge; in a typical web framework, you need to explicitly escape every single piece of potentially dangerous attacker-controlled input to stay safe - and because people tend to do some validation at input stage, it's very difficult to audit for it. Escaping also needs to be very different depending on the context (URLs need to be encoded differently than HTML parameters, and differently than standalone text). So even though your framework may provide several escape() functions, it's very easy to get it wrong, and people constantly do. OTOH, if your framework provides a get_token() function, there's really not that much to using it properly. I'm coming from a background of doing lots of security reviews for existing applications, so while I appreciate that the difference may be subtle, the real-world error patterns speak to me pretty strongly; and I do think that insufficient escaping is drastically more common than used, but insufficiently unpredictable XSRF tokens. /mz
Re: [whatwg] some thoughts on sandboxed IFRAMEs
I've introduced srcdoc= to largely handle this. There is an example in the spec showing how it can be used. Yup, sounds good. This has been proposed before. The concern is that many authors would be likely to make mistakes in their selection of random tokens that would lead to significant flaws in the deployment of the feature. srcdoc= is less prone to errors. Only and characters need to be escaped. If the character is not escaped, then a single character in the input will cause the comment to break. My counterargument, as stated later in the thread, is quite simple: the former *forces* you to implement a security mechanism, else the functionality will break. You can still use a bad token, but you are required to make the effort. In that regard, the comparison to XSRF is probably not valid; a vast majority of XSRF bugs occurs not because people pick poor tokens (in fact, that's really a majority), but because they don't use them at all. From that perspectiv, srcdoc=... is very similar to XSRF - people will mess it up simply by not thinking about the correct escaping. That said, I am not really arguing against srcdoc=...; I think it's an OK feature. My point is simply that I would love to see less fragmentation when it comes to XSS defenses and the granularity of security controls. The initial proposal of iframe sandboxes solved a very narrow use case, and other, unrelated designs started to spring up elsewhere. This wouldn't be bad by itself, but while the security controls on iframes were pretty great (with some tweaks, such as text/html-sandboxed), they would not be reflected in other APIs, which I thought is unfortunate. If we extend sandboxed iframes with srcdoc, seamless frames, text/html-sandboxed, and iframe rendering performance improvements, it actually becomes close to a comprehensive solution, and I am happy with this (other than a vague feeling that we just repurposed iframe to be some sort of a span ;-). I've introduced text/html-sandboxed for this purpose. Yup, I noticed. Looks great. It does make me wonder about two things, though: 1) Some other security mechanisms (CORS, anti-clickjacking controls, XSS filter controls) rely on separate HTTP headers instead. Is there a compelling reason not to follow that lead - or better yet, to unify all security headers to conserve space? 2) People may conceivably want to sandbox other document types (e.g., SVG, RSS, or other XML-based formats rendered natively, and offering scripting capabilities). Do we want to create -sandboxed MIME types for each? The header approach would fix this, too. 2.1) The ability to disable loading of external resources (images, scripts, etc) in the sandboxed document. The common usage scenario is when you do not want the displayed document to phone home for privacy reasons, for example in a web mail system. Good point. Should we make sandbox= disable off-origin network requests? That would be great. I think Adam proposed we have a separate sandbox=... toggle for this. Whether it's on or off by default probably doesn't matter much. 2.2) The ability to disable HTML parsing. On IFRAMEs, this can actually be approximated with the excommunicated plaintext tag, or with Content-Type: text/plain / data:text/plain,. On token-guarded SPANs or DIVs, however, it would be pretty damn useful for displaying text content without the need to escape , , , etc. Pure security benefit is limited, but as a phishing prevention and display correctness measure, it makes sense. I don't really understand the use case here; could you elaborate? One use case is a web forum or a web mail interface where you want to display a message, but specifically don't want HTML formatting. Or, performance permitting, the same could be used for any text-only entry fields displayed on a page. These are common XSS vectors, and they are not readily addressed by sandboxed iframe + srcdoc=..., because this will not render as expected: User's favorite smiley face is: iframe srcdoc=lt;Ogt;_lt;Ogt;/iframe Having a drop-in solution for this would be pretty nice, and very easy to implement, too: just force text/plain, do not sniff. Do people get CSRF right more often than simply escaping characters? It seems implausible that authors get complex cryptographic properties right more often than a simple set of substitutions, but I suppose stranger things are true on the Web. Keep in mind that pretty much every web application already needs to safely generate unique, unpredictable tokens - for session identifiers that guard authenticated sessions. If they can't get it right, they are hosed anyway - but problems here are not horribly common, in my experience at least, and web app frameworks do a decent job of helping developers by providing token-generating facilities. As noted earlier, the vast majority of issues with XSS and XSRF defenses is that you explicitly need to think about them, and a failure to do so has no obvious side
Re: [whatwg] some thoughts on sandboxed IFRAMEs
The reason to use a MIME type here is to trick legacy browsers into not rendering the response as HTML. Legacy browsers probably will, anyway :-( /mz
Re: [whatwg] some thoughts on sandboxed IFRAMEs
I believe that the @doc attribute, discussed in the original threads about @sandbox, will be introduced to deal with that. It'll take plain html as a string, avoiding the opaqueness and larger escaping requirements of a data:// url, as the only thing you'll have to escape is whichever quote you're using to surround the value. That doesn't strike me as a robust way to prevent XSS - the primary reason why we need sandboxing to begin with is that people have a difficulty properly parsing, serializing, or escaping HTML; so replacing this with a mechanism that still requires escaping is perhaps suboptimal. Nah, token-guarding is no good. For one it's completely unusable in the XML serialization without edits to the XML spec. This seems valid. More importantly, though, it puts a significant burden on authors to generate unpredictable tokens. Is this difficult? No, of course not. But people *will* do it badly, copypasting a single token in all their iframes or similar. People already need to do this well for XSRF defenses to work, and I'd wager it's a much simpler and better-defined problem than real-world HTML parsing and escaping could realistically be. It is also very easy to delegate this task to existing functions in common web frameworks. Also, a single token on a returned page, as long as it's unpredictable across user sessions, should not be a significant issue. 1) The utility of the SOP sandboxing behavior outlined in the spec is diminished if we have no way to actually *enforce* that the IFRAMEd resource would only be rendered in such a context. If I am serving user-supplied, unsanitized HTML, it is obviously safe to do iframe sandbox src=show.cgi?id=1234/iframe - but where do we prevent the attacker from calling http://my_site/show.cgi?id=1234 directly, and bypassing the filter? There are two cases where the mechanism still offers some protection: You mean, if the attacker controls their own website on the same origin and iframes it for themselves? The specific scenario given in the spec is: pWe're not scared of you! Here is your content, unedited:/p iframe sandbox src=getusercontent.cgi?id=12193/iframe Let's say this is on example.com. What prevents evil.com from calling http://example.com/getusercontent.cgi?id=12193 in an IFRAME? Assuming that the author of evil.com is also the author of example.com user content 12193, this renders all the benefits of using sandboxed frames on example.com moot. The only two cases where this threat is mitigated is when non-SOP domains are used to serve user content (but in this case, if you're doing it right, you don't really need iframe sandboxes that much); or if id= is unpredictable (which in your own words, people are going to mess up). And neither of these seem to be the case for the example given. 2.2) The ability to disable HTML parsing. On IFRAMEs, this can actually be approximated with the excommunicated plaintext tag, or with Content-Type: text/plain / data:text/plain,. On token-guarded SPANs or DIVs, however, it would be pretty damn useful for displaying text content without the need to escape , , , etc. Pure security benefit is limited, but as a phishing prevention and display correctness measure, it makes sense. Why not just run an escape function over the content before sending it? All web languages have one specifically for escaping the html-significant characters. There's only five of them, after all. Well, indeed =) But xssed.com has 61,000 data points to the contrary. The easier we make it for people to achieve exactly the result they want, whilst avoiding security issues, the better. One of the common tasks they fail at is rendering limited (neutered) HTML without any JS in. This is not an unsolved task - quite a few implementations exist to do it pretty well - but they still fail. The other, arguably more common task - and the most common source of XSS flaws - is to display user input without any HTML at all. So this fits in nicely, even if simple to implement by other means. /mz
Re: [whatwg] some thoughts on sandboxed IFRAMEs
Nah, token-guarding is no good. [...] More importantly, though, it puts a significant burden on authors to generate unpredictable tokens. Btw, just to clarify - I am not proposing this instead of the current method; we could very well allow token-guarded sandboxing on divs / spans, and sandboxing sans tokens on iframes, without making the mechanism much more complicated or unintuitive. Iframes solve one class of problems (mostly, sandboxing entire pages or larger blobs of text, with certain performance and usability trade-offs); lightweight divs / spans solve another (easy and low-cost sandboxing of small snippets of user input) in a conceptually similar way. If we do not address that second need, we are bound to see completely different mechanisms emerge (such as the toStaticHTML variants), with different semantics, security controls, and filtering granularity, which I think is suboptimal. And since these mechanisms are limited to JS, we may eventually see a third class of solutions emerge at some point, which is really, all too reminiscent of the misery with 5 or so flavors of SOP. So my general concern is this; token-guarded tags may not be the best way to do it, but still. /mz
Re: [whatwg] some thoughts on sandboxed IFRAMEs
The @sandbox seems like a better fit for the advertising use case. I am not contesting this, to be clear - I am aware of many cases where it would be very useful - but gadgets are a fairly small part of the Internet, and seems like a unified solution would be more desirable than several very different APIs with different granularity. The toStaticHTML-alike will address another specific uses, but will leave applications that can't rely on JS exclusively for their rendering needs (which I'd wager is still a majority) out in the cold; which would probably lead to a yet another XSS prevention / HTML sandboxing approach emerging later on. I haven't really seen a compelling argument why all these can't be unified without a significant increase in code or spec complexity - maybe one exists. More importantly, some of the features of @sandbox (e.g., allow-same-origin), as well as some of the examples in the spec, seem to be explicitly targeted for other use cases, which makes me think this is not the consensus between the authors; and the particular same-origin user content example would promote highly unsafe coding practices if ever followed. So it seems to me like such a narrow use case is not even the consensus between authors? Cheers, /mz
Re: [whatwg] some thoughts on sandboxed IFRAMEs
[...sorry for splitting the response...] People screw up CSRF tokens all the time. The closing tag nonce design has been floating around for years. The earliest variant I could find is Brendan's jail tag. Sure, I hinted it not as a brilliant new idea, but as a possibilty. I do think giving it - or just anything more flexible as frames - as an option should be relatively simple when seamless sandbox frames are implemented, and that it would make it infinitely more useful in places where it would arguably do much more good. If the authors wish to restrict this model to a specific ad / gadget use case, and consciously decided the costs of extending it to a more general sandboxing appraoch outweigh the benefits, that's definitely fine; but this is not evident. If so, we need to revise the spec to make this clear, perhaps nuke features such as allow-same-origin altogether, and definitely scrape examples such as: pWe're not scared of you! Here is your content, unedited:/p iframe sandbox src=getusercontent.cgi?id=12193/iframe /mz
Re: [whatwg] some thoughts on sandboxed IFRAMEs
How do I use the jail tag to sandbox advertisements? Huh? But that's not the point I am making... I am not arguing that iframe sandbox should be abandoned as a bad idea - quite the opposite. I was merely suggesting that we *expand* the same logic, and the same excellent security control granularity, to span and div; this seems like it would not increase the implementation complexity in any significant way. We could then allow these to be populated with secure contents in three ways: 1) Guarded closing tag - this is simple and bullet-proof; but may conflict with XML serializations, and hence require some hacks, 2) CDATA or @doc-like approaches. Less secure because it does not enforce a security control, but less contentious, and already being considered for IFRAMEs. 3) .innerHTML, which would be then safe by default, without the need for .innerSafeHTML (and the associated ambiguities) or explicit .toStaticHTML calls. This allows people to utilize the mechanism for so many more additional use cases without the performance and usability cost of IFRAMEs, and does not subvert the original ad / gadget use case in any way. *This* is what I find greatly preferred to having separate, completely disjointed APIs with different semantics for ads / gadgets and other full page contents, for small snippets of JS-inserted HTML, and for server-returned data. The sandbox tag is great at addressing that use case. I don't see why we should delay it in the hopes that the jail tag comes back to life. I am not suggesting this at all; extending the spec to cover, or at least hint these cases would be a good idea. This is not to say the functionality as currently speced out should be scraped. My points were: 1) If we want to keep it limited to the ads / gadget case, we should make it clear in the spec, reconsider the applicability of allow-same-origin in this context, and definitely revise the as of now unsafe getusercontent example, etc. I am not entirely sold that this is a beneficial strategy in the long run, but as long as the alternatives were considered, so be it. 2) If we want to make the implementation useful for other scenarios as well, and avoid the proliferation of HTML-sandboxing APIs with different security controls, we should still keep the spec mostly as is, and I have no objection to implementations incorporating it; BUT it would be beneficial to allow it to be extended as outlined above, or in a similar general way, specifically making it easy to sandbox inline HTML, and to place thousands of sandboxed containers on a page without making the renderer implode. /mz
Re: [whatwg] some thoughts on sandboxed IFRAMEs
On Sun, Dec 13, 2009 at 2:00 PM, Adam Barth wha...@adambarth.com wrote: The sandbox tag is great at addressing that use case. I don't see why we should delay it in the hopes that the jail tag comes back to life. And Adam - as you know, I have deep respect for your expertise and contributions in this area, so please do not take this personally... but this really strikes me as throwing random ideas at the wall, and seeing which ones stick. This is sometimes beneficial - but we are dealing with possibly revolutionary security mechanisms in the browser, meant to counter one of the most significant unsolved security challenges on the web. And this mode of engineering is probably why we have a different same-origin policies for XMLHttpRequest, DOM access, cookies, third-party cookie setting, Flash, Java, Silverlight... plus assorted ideas such as MSIE zones on top of it. It's the reason why their sum is less secure than each of the mechanisms individually. Still, this is not an attempt to dismiss the hard work: implementing sandboxed IFRAMEs as-is and calling it a day *will* make the Internet a safer place. But a collection of walled off, incompatible APIs with different security switches and knobs, all of them to perform a common task, does strike me as suboptimal - and I do think it's avoidable. Especially since, I am guessing, some of the pragmatic objections to guarded tags were probably due to implementation complexity or dubious usability, all of which are probably moot with @sandbox in place. Furthermore, in this particular case, I am really concerned that the spec is at odds with itself - you mention certain specific use cases, but the spec seems to be after a broader goal: sandboxing user-supplied content in general. In doing so, it gives some bad advice (again, the user content example is exploitable, at least until the arrival of some out-of-scope security mechanism to prevent it). I think I stated the concerns reasonably well earlier in the thread; but if they sound unwarranted or inflammatory, I can admit a defeat. Cheers, /mz
Re: [whatwg] some thoughts on sandboxed IFRAMEs
span sandboxlt;spangt;But this span will have another span as its child, sandboxed. The regular parser sees no entities here, only a nested span!lt;/spangt;/span That's a pretty reasonable variant for lightweight sandboxes, IMO. It does not have the explicit assurance of a token-based approach (i.e., will not fail right away if the user gets it wrong), but it's better than data: URLs or @doc in that - as you noted - it will fail quickly if the encapsulated HTML is not escaped, while this may still go unnoticed until abused: iframe sandbox doc=h1User input without escaping/iframe iframe sandbox src=data:text/html,h1User input without escaping/iframe As a side note, the other benefit of sandboxed spans and divs in such a design is that you can then have .innerHTML on sandbox-tagged elements automagically conform to the sandboxing rules, without the need for .toStaticHTML, .secureInnerHTML, or similar approaches (which are error-prone by the virtue of tying sanitization to data access method, rather than a particular element). /mz
[whatwg] some thoughts on sandboxed IFRAMEs
Hi folks, So, we were having some internal discussions about the IFRAME sandbox attribute; Adam Barth suggested it would be more productive to bring some of the points I was making on the mailing list instead. I think the attribute is an excellent idea, and close to the dream design we talked about internally for a while. I do have some peripheral concerns, though, and seems like now is the time to bring them up! Starting with two high-level comments: although I understand the simplicity, and hence the appeal, of sandboxed IFRAMEs, I do fear that they will be very hard on web developers - and hence of limited utility. In particular: 1) IFRAME semantics make it exceedingly cumbersome to sandbox short snippets of text, and this task is perhaps the most common and pressing XSS-related challenge. Unless the document is constructed on client side by JavaScript, sites would need to use opaque data: URLs, or put up with a lot of additional HTTP roundtrips, to utilize sandboxed IFRAMEs for this purpose. [ There is also the problem of formatting and positioning IFRAME content, although the seamless attribute would fix this. ] The ability to sandbox SPANs or DIVs using a token-guarded approach (span sandbox=random_token/span sandbox=same_token) is, on the other hand, considerably easier on the developer, and probably has a very similar implementation complexity. 2) Renderers suck dealing with IFRAMEs, and will probably continue to do so for time being. This means that a typical, moderately complex application (say, as a discussion forum or a social site), where hundreds of user-controlled strings may need to be present to display user content - the mechanism would have an unacceptable load time and memory footprint. In fact, people are already coming up with lightweight alternatives with a significant functionality overlap (and different security controls). Microsoft has toStaticHTML(), while a standardized implementation is being discussed here right now in a separate thread. Isn't the benefit of keeping the design slightly simpler (and realistically, limited to relatively few usage scenarios) negated by the fact that alternative solutions to other narrow problems would need to emerge elsewhere? The browser coming with several different script sanitizers with completely different APIs and security controls does not strike me as a desirable outcome (all the flavors of SOP are a testament to this). If the anser is not a strong no, maybe the token-guarded DIV / SPAN approach is a better alternative? Now, that aside - on a more pragmatic level, I have two extra comments: 1) The utility of the SOP sandboxing behavior outlined in the spec is diminished if we have no way to actually *enforce* that the IFRAMEd resource would only be rendered in such a context. If I am serving user-supplied, unsanitized HTML, it is obviously safe to do iframe sandbox src=show.cgi?id=1234/iframe - but where do we prevent the attacker from calling http://my_site/show.cgi?id=1234 directly, and bypassing the filter? There are two cases where the mechanism still offers some protection: 1.1) If I make IFRAMEd URLs unpredictable with the use of security tokens - but if people were likely to get this right, we wouldn't have XSRF and related issues on the web, 1.2) f I point the IFRAME to a non-same-origin domain - but if I can do this, and work out the non-trivial authentication challenges in such a case, I largely don't need a SOP sandbox to begin with: I can just use unique_id.sandboxdomain.com. In fact, many sites I know of do this right now. It strikes me that this mechanism would make a whole lot more sense if supported on HTTP header level, instead: X-SOP-Sandbox: 1; in its current shape, it is defensible perhaps if aided by Mozilla's CSP. Otherwise, it's an error-prone detail, and we should at the very least outline why it's very difficult to get it right in the spec. 2) The utility of the no form submission mode is limited to certain very specific anti-phishing uses. While this does not invalidate it, it makes it tempting to mention two other modes we discussed internally, and that probably fall into the same bucket: 2.1) The ability to disable loading of external resources (images, scripts, etc) in the sandboxed document. The common usage scenario is when you do not want the displayed document to phone home for privacy reasons, for example in a web mail system. 2.2) The ability to disable HTML parsing. On IFRAMEs, this can actually be approximated with the excommunicated plaintext tag, or with Content-Type: text/plain / data:text/plain,. On token-guarded SPANs or DIVs, however, it would be pretty damn useful for displaying text content without the need to escape , , , etc. Pure security benefit is limited, but as a phishing prevention and display correctness measure, it makes sense. Well, that's it. Hope this does not come off as a complete rant :P Cheers, /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Wed, 1 Oct 2008, Robert O'Callahan wrote: I don't think that's secure. The outer page can set the IFRAME's URL to contain a #xyz fragment identifier That's really covered in the original proposal. Honest :P In a kludgy manner, of course (permitting fragments, but not permitting onload scrolling based on fragments in cross-domain settings), but we thought of this one. /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Tue, 30 Sep 2008, Adam Barth wrote: This could be addressed by sending a cryptographic hash of the origin (using an algorithm that is commonly available in libraries used by server-side programmers). Interesting idea. So you're suggesting something like: Origin-SHA1: 4e13de73de2d1a1c350eb4ae429bb7b009a21a84 This sounds like it would work well if the site owner knew exactly all the origins he was expecting, but it makes it difficult to enforce a policy like process this request if it came from a subdomain of example.com. More importantly, since the dictionary of possible inputs is rather limited, it would be pretty trivial to build a dictionary of site - hash pairs and crack the values. May protect xyzzy2984.eur.int.example.com, but would still reveal to me you are coming from playboy.com. /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Tue, 30 Sep 2008, Edward Z. Yang wrote: More importantly, since the dictionary of possible inputs is rather limited, it would be pretty trivial to build a dictionary of site - hash pairs and crack the values. May protect xyzzy2984.eur.int.example.com, but would still reveal to me you are coming from playboy.com. Salt it. Problem solved. Not really? I just need to rebuild my dictionary for that salt, but to check against say a million or ten million of common domains, it wouldn't be very expensive. And it's not very expensive to build such a list of domains, too. /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Tue, 30 Sep 2008, Edward Z. Yang wrote: In that case, you are certainly correct; adding a salt only hinders an attacker. But if we're worried about Origin giving away a secret intranet website, I think things should be reasonable. Of course, they can still dictionary brute-force it... I guess the concern is primarily over home users, as they seem to be particularly fond of referrer-blocking plugins and so forth - and if Origin becomes nearly as often blocked over rational or irrational fears, it would become much less useful. Corporations with large intranets probably care less, and there might be better ways to help them if they do (from RFC1918 checks on browser end, to proxies or internal redirectors that remove internal addresses only). /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Mon, 29 Sep 2008, Hallvord R M Steen wrote: To give webmasters more ways to deal with this situation, I think we should implement the Access Control Origin HTTP-header only (assuming that it should refer to the top site in the frameset hierarchy). I definitely like the Origin proposal the most of all the opt-in schemes, simply because it permits trusted domains to be whitelisted for many applications that rely on same-origin separation to implement security sandboxes. It still completely ignores the question of how we protect gadgets / mashups / whatever that are *designed* to be embedded on potentially untrusted sites, but depend on having the integrity of their UIs preserved, so I think we need - or well, should - tackle this aspect separately if this is the consensus for now. Note that the current implementation proposals for Origin headers (which I believe are limited to non-GET, non-HEAD requests) would not prevent this attack, nor some other potential attack vectors; they would probably need to be modified to include Origin header on SRC= GET requests on IFRAME / EMBED / OBJECT / APPLET. Extending the scheme to include SCRIPT would also cover script-inclusion attacks; extending it to all automated navigation (SRC=, REL=, scripted form submissions and location updates, etc) would prevent a broader set of XSRF and XSS attacks than the original proposal, but that's purely optional. But the bottom line is, there are some extra birds we could hit with that stone. Sites may want to use any of several policies in a somebody framed me situation. For example, these are all policies a site may want to deploy: 1. nobody may frame my content 2. selected sites only may frame my content 3. anyone may frame my content but not re-use an existing session 4. anyone may frame my content As noted, one important scenario which we do not account for is 5. anyone may iframe my content, but I want my UI not to get clobbered. This would realistically be the expectation for almost any privileged / authenticated gadget to be embedded on third-party pages. Cheers, /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Mon, 29 Sep 2008, Anne van Kesteren wrote: A cross-site XMLHttpRequest request would always include Origin. I haven't really seen other specifications start using it yet, but I believe there are some experimental implementations for including it in cross-site form POST requests. Yup, I mean the non-XMLHttpRequest Origin header as proposed / implemented by Adam Barth and Collin Jackson for generic POSTs (though I might be not doing the implementation justice, so it's probably best for them to chime in). /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Mon, 29 Sep 2008, Hallvord R M Steen wrote: It still completely ignores the question of how we protect gadgets / mashups / whatever that are *designed* to be embedded on potentially untrusted sites, but depend on having the integrity of their UIs preserved After giving this quite some thought over the weekend, my conclusion is that this basically isn't doable - simply because it is a UI issue, UI is all about communicating to end users and the likelyhood of finding a solution that communicates the complexity of this in a way users will understand is practcally 0. Well, so I agree. Yet, given the choice between: 1) Telling developers that they can't do any privileged gadgets safely at all, not theirs, and for reasons that are hard to explain to regular developers too - and pretending that the problem does not exist while people continue to depend on the unsafe logic (because whether we like it or not, seems that gadgets, mashups, and other methods of tightly integrating various applications and data sources on client side is here to stay), ...and... 2) Implementing a kludge that does not severely and inherently degrade user experience, whilst giving developers at least some security that they should have in the first place (most of the security problems they are dealing with these days can be tracked back to poor or uncoordinated security design decisions in the early days of the Web), I would be kinda willing to side with 2, which is why we came up with the kludgy proposal #3 to begin with. It's ugly, it's not perfect, it may require multiple workarounds to account for various scenarios, but it's the only way to tackle the UI problem we could think of. It also has a chance of working in a reasonably seamless manner if carefully reviewed and done right, although it might be a bumpy ride. Not presenting users with overly complex choices or failure scenarios is a noble goal, but realistically, it's not how web browsers work these days, and so when applied selectively, it might be not the strongest argument possible. As of now, understanding browser settings and error / warning / prompt messages requires a fair dose of expertise and experience, and it is extremely difficult to operate these applications without this knowledge. Some of the ongoing efforts improve this a bit (for example, browsers moving away from cryptic SSL security prompts to cryptic interstitials), other efforts take us a step back (for example, yellow security notification bars that are fully spoofable by web pages, and not properly anchored into browser chrome). The idea I liked most was a sort of automatically raise IFRAMEs to topmost z-index when focused combined with some way to temporarily flash the address - but IMO it's not doable because we'll mess up the UI of existing solutions in unexpected ways, and users don't understand URLs and have a quite fuzzy understanding of the basic different site concept. Yup. Plus, it leaves some open questions. Do we simply raise an IFRAME when clicked? If yes, the harm might be already done. Do we require Eolas-patent-style click-to-activate? If yes, we might seriously annoy operators of some IFRAME-based advertisement systems. Do we raise the frame just on mouseover? This would result in confusing flickering and page layout changes, would mess up drop-down menus expanded over different-origin document windows, etc. Cheers, /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Tue, 30 Sep 2008, Robert O'Callahan wrote: We can easily offer these developers the following options: a) developers of privileged gadgets can whitelist domains that they trust to not subvert the UI How is this achieved? If I have a chat (talk to site owner using your $foo chat account) or calendar overlay (see scheduled events overlaid on your calendar) gadget that is to be embedded freely by third-parties, and offers a privileged UI - even if I require sites to pre-register or otherwise build a whitelist of these untrusted domains, I have no assurance they would play nice. b) privileged gadgets can be offered to the world as long as the IFRAME's own UI is not trusted. For example, gadgets whose purpose is to offer a postMessage API to untrusted container pages would be just fine. Sure, but then it makes the model drastically different, and suitable for different uses (many privileged gadgets may specifically not want to disclose any presented information to the top level page). c) spawn new windows/tabs to perform or confirm privileged operations That's a terrible user experience, by most accounts, and goes against the concept of a gadget; I believe it is often avoided at all costs except when absolutely necessary (e.g., login, where the user needs the opportunity to verify URL, SSL status, etc). Cheers, /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Tue, 30 Sep 2008, Robert O'Callahan wrote: If the chat gadget is configured to only talk to the site owner, how can it be abused? I suppose the site owner can discover the chat nick of a visitor who otherwise wouldn't want to disclose it. That's a risk that the chat system developers might very well be willing to accept. Assume you are logged in with Facebook, Google, or any other common party that provides general chat / calendar services or anything of that kind; and let's say this party permits site operators embed a gadget that shows every visitor a schedule of events advertised on a page overlaid on top of visitor's schedule (with the option to add these to your calendar, or edit your calendar data - it does not have to be read-only); or gives you the opportunity to chat, review and annotate documents, or otherwise collaborate with site owners using similar facilities provided by gadget operator in their third-party domain, in your capacity as the user logged in with said services. [If the visitor is not logged in, such a gadget would not display, or would offer a login link that pops up a new https:// window.] This is not a very far-fetched scenario - I've seen designs of this type - and they are very much possible and safe to arrange without disclosing any user-specific information to the page that embeds said gadgets. The only security problem arises with UI redress flaws; so it would be nice to offer viable alternatives for such applications, too. That's a terrible user experience, by most accounts, and goes against the concept of a gadget; I believe it is often avoided at all costs except when absolutely necessary (e.g., login, where the user needs the opportunity to verify URL, SSL status, etc). Maybe we can make it a better user experience, for example, by allowing the new window/tab to appear as a new pane at the top or bottom of the existing tab. That would nicely handle your chat example, IMHO. Possibly. /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Sat, 27 Sep 2008, Jim Jewett wrote: uhm... that is exactly when involuntary actions are *most* likely. It's not about merely clicking something accidentally - it's about clicking at a very specific place, as intended by the attacker, to trigger a very specific functionality on a targeted page. So I do not quite see how random frustration / wrong window focus clicks could apply (and it's a problem that no application is really designed to handle [1]). Many programs become unresponsive during launch and/or setup. I typically switch to another program (or another page), but the mouse events (and even keyboard keys) don't always go to the right place. That's odd, and I would be willing to say that this is a problem that needs to be addressed by your window manager or OS vendor. Window focus management and message queues should be independent of any particular application's responsiveness to messages sent to it. I honestly do not recall any situation where I would end up sending click events to the wrong application because the focus switch operation I just executed seemed to work, but in reality did not (if the application is not responsive, it would very likely not redraw itself, which means I would have nothing to click on). Cheers, /mz [1] Well, except for http://www.bitboost.com/pawsense/
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Sat, 27 Sep 2008, Jim Jewett wrote: Yet opt-in proposals expect content authors to immediately add security checks everywhere, which is considerably less realistic than having a handful of webpages adjust their behavior, if we indeed break it (which I don't think would be likely with the design). It feels better, but I am inclined to think it is considerably less beneficial. Why? Most sites won't add the checks because they don't need them. Static pages do not (but would likely see no ill effects, too). Almost all web applications, where the user has a distinct authenticated context, do. Given that something like 90%+ of the list of top 100, 500, or whatever websites visited by typical users belongs to the latter category (well, looking at public stats at least), easily extrapolated to tens of millions of other less successful but still used resources (web forums, shops, chats, customer portals, etc), that all these are almost always significantly more complex that any static content (thousands of pages and hundreds of distinct features are not uncommon) - I indeed see a problem that is best addressed in an on-by-default mode. If you have faith that all these places can be patched up because we tell them so, and that these who want to would be able to do so consistently and reliably - look at the current history of XSRF and XSS vulnerabilities. /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Sun, 28 Sep 2008, Michal Zalewski wrote: If you have faith that all these places can be patched up because we tell them so, and that these who want to would be able to do so consistently and reliably - look at the current history of XSRF and XSS vulnerabilities. ...and consequently, the worst-case scenario for breaking a page that did not need the protection to begin with is that the owner easily opts out, in a manner that is trivial to verify across his resources; on the other hand, the worst-case scenario for leaving one out of thousands resources on Facebook, MySpace, eBay, or my wife's cat fanciers' forum, accidentally not protected by an opt-in mechanism in some obscure code path... is more or less widespread misery that is extremely hard and sometimes expensive to clean up. /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Sun, 28 Sep 2008, Robert O'Callahan wrote: I'm not sure what you're talking about here. I'm specifically NOT talking about Content-Restrictions or Site-Security-Policies or any other policies for controlling what a page may do once it has loaded. I'm expressing approval for your option 1, X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes, preferably generalized to X-I-Do-Not-Want-To-Be-Loaded-Across-Domains: yes so that it can be used for scripts and images too. Well, OK, but that gets us on a slippery slope ;-) If it is just for IFRAMEs, then it does not reduce complexity - it increases it, because we already have way too many security-related headers (MSIE8 has Content-Type-And-I-Really-Mean-It-So-Do-Not-Second-Guess, headers to control XSS filters, P3P policies, etc; other browsers are getting cross-domain XMLHttpRequest headers; there are some more examples to find), and we are adding a yet another header with a name and syntax that probably would not add up to a coherent picture, and costs quite a few bytes for high-traffic sites. If we, on the other hand, do the preferred generalization, as you note, then the next reasonable step would be to integrate all these security headers into a single, sane syntax that converses space, resources, and follows common rules. Now consider that I-Do-Not-Want-To-Be-Loaded-Across-Domains is also inherently incompatible with mashups, content separation, gadgets, etc, and there is a very vocal group of proponents and promotors for these technologies (which is why browser vendors are implementing cross-domain XMLHttpRequest to begin with). So we would probably rather want to say I-Want-To-Be-Loaded-Only-By: list_of_domains. This still leaves some attacks (I might want my gadget to be embedded anywhere, just without being clobbered, which is something we averted our eyes from here), but let's say for a moment that it's good enough. If we do that, then we are not far from the (IMO half-baked) site security policy concept. Some other person then adds several extra checks to prevent XSRF on top of this, and you have a system indistinguishable from SSP ;-). Which is not to say much, just explaining why I made the leap. There would probably be a temptation to come up with a coherent and unified design, which may result in some bloat. Or maybe not. So what? The same goes for all your options --- slow browser migration delays the uptake of any client-side solution. Not really; minor versions usually have better uptake rates, thanks to auto-updates, etc (it's far from perfect, but it's nowhere near the estimated, if I recall published stats correctly, 20% of people still using MSIE6 after a year of MSIE7?) - not to mention, not having a change shelved until the next major version of a browser 2-4 years from now, means that even with poor uptake, it would be broadly available sooner. Complex changes often get deferred, so any feature that is easy to smuggle in a minor version is probably better than a feature that needs to wait for MSIE 9, Firefox 4 (now, #3 is still considerably cheaper than a fully-blown SSP). Cheers, /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Sun, 28 Sep 2008, Robert O'Callahan wrote: There is no way in the world that Microsoft would implement your option 3 in a security update to IE6. Sure, I'm not implying this. I simply have doubts about any other major security changes making it into MSIE8 or Firefox 3. Cheers, /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Thu, 25 Sep 2008, Maciej Stachowiak wrote: I meant, corner of the container, rather than actual document rendered within. Then can't you work around the restriction by scrolling the contents inside the iframe and sizing it carefully? (One way to scroll an iframe to a desired position is to load a URL containing an anchor link This was addressed in the original proposal (anchors and within-IFRAME focus() calls). There should be no other useful ways to scroll different-domain IFRAMEs, I'm hoping (window.scroll* methods are mercifully restricted in such a case in most browsers). For example, iGoogle widgets would become disabled if scrolled partially off the top of the page under your proposal. And even if scrolled back into view, would remain disabled for a second. With possibly a jarring visual effect, or alternately, no visual indication that they are disabled. Hard to decide which is worse. As per the other thread, this is easily preventable (and a clause for UI action optimizations is already in the original proposal). I don't see this as a sufficient argument to dismiss the proposal, quite frankly - it does not indicate a fatal flaw, but rather a minor issue that is rather easily worked around. Cheers, /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Fri, 26 Sep 2008, Maciej Stachowiak wrote: Maybe I didn't read very well, but I don't see how the clause for UI action optimizations would prevent what I described. Could you spell it out for me please? It seems to me that the embedded iframes for iGoogle gadgets (or similar) will indeed be disabled when scrolled partly off the top of the page (or maybe dead to UI events only when you bring the mouse near them, which amounts to the same thing). What I meant is that we can conceivably inhibit disabling IFRAMEs if they end up off the screen as a result of non-scripted user-initiated scrolling - a change that does not require the design to be scraped. I was simply referring to the fact that similar optimizations were already present in the design, so it is not a very far-fetched idea to extend it to incorporate this. We did not, because it seemed to be a non-issue. All this assuming that the inability to interact with a cross-domain gadget whose top part is off the screen is an usability problem by itself, to a degree that invalidates any security benefit for such a scheme. Many of the earlier security improvements within browsers did rule out far more pronounced usage scenarios, retrospectively breaking other people's applications. Examples include file:/// scripting restrictions, Internet - file:/// access restrictions, document.cookie restrictions on non-HTTP schemes, CANVAS readback once non-same-origin images are rendered, third-party cookie restrictions, etc. Not all of these solutions were perfect, but they do provide some context. I am also not sure what you mean by the other thread. Err, sorry - the other branch of this one. P.S. I cited this example because it is a Google property, but I am sure there are many others like it. We can't expect content authors to immediately fix them all. Yet opt-in proposals expect content authors to immediately add security checks everywhere, which is considerably less realistic than having a handful of webpages adjust their behavior, if we indeed break it (which I don't think would be likely with the design). It feels better, but I am inclined to think it is considerably less beneficial. /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Fri, 26 Sep 2008, Elliotte Rusty Harold wrote: It's tongue-in-cheek that I don't expect it to be adopted or seriously considered (this year). It's not tongue-in-cheek in that I very much wish it were adopted. That is, I think it's in the realm of the desirable, not the possible. Oh yup, agreed there; with current DOM manipulation capabilities, and with the hopefully upcoming flexible, site-controlled security policies, IFRAMEs could probably safely go away in a decade or so for most intents and purposes. I am curious what issues you see with same origin content. They certainly exist, but I tend to feel those are orthogonal to the issues at hand, and subject for a separate discussion. Yup, these are best addressed by introducing better security controls wrt content sniffing, sandboxing, etc, rather than keeping IFRAMEs around. It's just that killing IFRAMEs before these improvements are introduced would probably do some harm. The general problem is, let's assume my application wants to show you a third-party gadget, a document of an unknown format sent to you in an e-mail, or a raw HTML page that cannot be scrubbed down, or that we do not believe we can scrub well enough (this is a very difficult task by itself, given browser-specific HTML parsing quirks). Further assume that I want to do it within some other, trusted UI, to offer a more intuitive and streamlined user experience, instead of creating new minimal, non-interactive tabs. The only way to do it right now without risking the content gaining control of the UI is to keep it in a separate, untrusted sandbox domain, and use IFRAMEs to embed the data within the UI. Quite a few web apps adopted this approach for better or worse to implement useful functionality. Cheers, /mz
[whatwg] Dealing with UI redress vulnerabilities inherent to the current web
Hi folks, I am posting here on the advice of Ian Hickson; I'm new to the list, so please forgive me if any of this brings up long-dismissed concepts; hopefully not. For a couple of months now, along with a number of my colleagues at Google, we were investigating a security problem that we feel is very difficult or impossible to avoid on application side, and might be best addressed on HTML or HTTP level in contemporary browsers. These problems had recently gained some mainstream attention, and so we hoped to discuss potential solutions, and perhaps gain some traction for long-term fixes. 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. Practical, real-world examples of such UI redress attacks were demonstrated in the past, and recently resurfaced on an OWASP conference (under the name of clickjacking); some references include: * http://www.thespanner.co.uk/2008/02/11/csrf-chat/ * https://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference * http://lists.immunitysec.com/pipermail/dailydave/2008-September/005356.html We feel that current web browser designs provide no adequate tools for web site owners to protect their applications against such attacks. The two workarounds often employed right now are: 1) Using Javascript hacks to detect that window.top != window to inhibit rendering, or override window.top.location. These mechanisms work only if Javascript is enabled, however, and are not guaranteed to be reliable or future-safe. If the check is carried on every UI click, performance penalties apply, too. Not to mention, the extra complexity is just counterintuitive and weird. 2) Requiring non-trivial reauthentication (captcha, password reentry) on all UI actions with any potential for abuse. Although this is acceptable for certain critical operations, doing so every time a person adds Bob as a friend on a social networking site, or deletes a single mail in a webmail system, is very impractical. Other quick fixes are easy to come up with, but in general prove problematic in many usage scenarios. Based on our internal conversations, we have a number of proposals for approaches to how to address the issue, along with their pros and cons outlined. All these could be tweaked, combined, etc.; none of them seems quite ideal. 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) - 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. 2) Add a document-level mechanism to make if nested show this else show that 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. Pros: - Lightweight - Far more fine-grained than proposal #1 (though still not perfect) Cons: - Opt-in (sites remain vulnerable unless action is taken) - Might seem like an odd abuse of CSS / HTML 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. [ I like this one the most myself, but we were far from reaching any consensus. ] Algorithm
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Thu, 25 Sep 2008, Collin Jackson wrote: 6) New cookie attribute: The httpOnly cookie flag allows sites to put restrictions on how a cookie can be accessed. We could allow a new flag to be specified in the Set-Cookie header that is designed to prevent CSRF and UI redress attacks. If a cookie is set with a sameOrigin flag, we could prevent that cookie from being sent on HTTP requests that are initiated by other origins, or were made by frames with ancestors of other origins. Good point; the concern with this, as with most of the other schemes except for #3, is that it breaks some legitimate cross-domain uses such as gadgets and mashups (we can either permit anyone to partly or fully display a gadget, or deny everyone; we would ideally want to restrict partial rendering only). Just as importantly, some sites are moving to different-domain content hosting domains specifically to work around countless bugs, oddities, and design flaws in modern browsers (starting with MSIE text/plain / image/* behavior and utf-7 sniffing, through Content-Disposition bypass issues, to the complete inability to safely serve certain types of non-sanitized resources in sensitive domains). Customizable policy frameworks may help with this in the long run, but for now, it's a necessity. Any solution that puts blanket cross-domain restrictions on IFRAME nesting would need to be completely disabled in such scenarios. This is why I and several people like #3 best, despite its relative complexity - because it does not require you to fully expose your content to third-party domains. 7) New HTTP request header: Browser vendors seem to be moving away from same origin restrictions towards verifiable origin labels that let the site decide whether two security origins trust each other. Recent examples of this are MessageEvent's origin property [1], postMessage's targetOrigin argument [2], and the HTTP Origin header [3] [4] [5]. We can adjust proposal (1) to conform to this philosophy: instead of making it an X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes HTTP response header, make it an X-Ancestor-Frame-Origin: http://www.evil.com; HTTP request header. Oh yup, I wanted to capture this possibility in #5; it's a noble long-term goal, but with the conflicting proposals from Microsoft, Mozilla developers, and several other parties, and the high complexity of getting these mechanisms right - I am not sure it's a viable solution for the next few years. Maybe in 5-10, it would be a reality. /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Thu, 25 Sep 2008, Maciej Stachowiak wrote: C) Treat a case where top-left corner of the IFRAME is drawn out of a visible area (CSS negative margins, etc) as a special case of being obstructed by the owner of a current rendering rectangle (another IFRAME or window.top) and carry out the same comparison. Isn't this likely to come up any time you have a scrollable iframe, or one with overflow: hidden? And why top left but not bottom right? I meant, corner of the container, rather than actual document rendered within. If deals strictly with the frame beginning outside the current viewport to hide some of its contents, but leave small portions of the UI exposed to misdirected clicks. Doing the same check for bottom right is very much possible, although does not seem to thwart any particularly plausible attacks. - Seems complicated to implement correctly. It is relatively complex, as acknowledged. The whole reason for this complexity is that we hoped to devise a solution that: a) Works by default, without the need to implement specific server-side mechanisms (all things aside, placing the burden on server side is counterintuitive and likely to make these problems persist forever, even more so than XSS and XSRF), b) Does not break any plausible usage scenarios we could think of (with a particular attention to IFRAMEd non-same-origin document views, ads, gadgets). I would love to see better solutions along these lines to arise on this forum; failing this, we may resort to a solution that requires sites to opt in en masse for a particular mechanism, or to give up defenses to permit certain types of applications to be built - but I see this as suboptimal. - Seems very difficult to validate correctness of the security policy. This one I'm not sure I follow; very few browser security mechanisms are provable, and even the ones that are, usually do not get proven. It is relatively easy to intuitively break down and analyze the attack surface here, however. - Likely to break user experience of some existing sites. Any particular examples? Cheers, /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Fri, 26 Sep 2008, Robert O'Callahan wrote: Seems like this will create a really bad user experience. The user scrolling around in the outer document will make IFRAMEs in it mysteriously become enabled or disabled. Well, to put this in perspective - we are talking about cross-domain IFRAMEs only, and only a short security timeout; we could also quite conceivably make an exception for cases where a frame is scrolled into view as a result of the user interacting with the scroll bar, as opposed to page scripts (some optimizations of this type are already mentioned in the proposal). That said, yeah, there are some trade-offs and gotchas. I do not think that bad user experience is inherent to the design, but that does not change the fact that it's a kludge. I am not touting option #3, or any option on that list for that matter, as a perfect solution; in fact, they all suck for one reason or the other. I'm hoping we can come up with something workable, though. As noted, my greatest concern is having us pick an easy way out that essentially delegates all responsibility for compensating for an arguably broken design to web applications (as is the case with most of the opt-in solutions) - web developers already face a remarkable burden here, and tend to fail way too often - or devising a fix that cripples some less obvious but common uses (such as gadgets / mashups, or IFRAMEd advertisements). [ Not very related, but one such example of problem shifting was the fix that some browser vendors implemented to improve privacy, by refusing third-party cookies. It helped with the particular problem, and seemed insanely elegant - but also caused massive problems with certain types of gadgets, certain authentication schemes, and a handful security mechanisms that relied on different-origin separation to safely host untrusted content, lacking other options. ] Cheers, /mz
