On May 13, 2010, at 6:40 PM, Dirk Pranke wrote: > On Thu, May 13, 2010 at 6:13 PM, Maciej Stachowiak <[email protected]> wrote: >> ; you're right. > >> >> If you don't run the code in an off-domain iframe or through a sanitizer >> like Caja, then everything on your site is vulnerable, not just resources >> protected via CORS. Using different-origin iframes with postMessage to >> communicate to the container seems like a fine solution for third-party >> gadgets. What goal is it defeating? Why would embedding gadgets inline >> without a frame be a goal? > > One could argue that maintaining off-domain iframes is a hack, or is a > maintenance burden. You are correct of course that if you don't do > either, you are vulnerable.
Hack: not sure why it would be a hack. Embedding self-contained pieces of interactive content is *exactly* what iframes are designed for. The case where using iframes is a bit of ahack (in my opinion) is when you use an invisible iframe as a way to implement a cross-site data API, where visual embedding is not an issue. I think the idea of running untrusted JavaScript code from your own origin is terrifying, no matter how much you have tried to verify and restrict it. So even if I were using a Caja-style tool, I would still want to put the untrusted content in an off-domain iframe. Maintenance burden: I don't see that either. You could either host the iframe content on the domain of the gadget provider, in which case it reduces burden on the hosting site, or else it's easy to support an unbounded number of subdomain hostnames from a single server. Wheres the burden? > >> Alternately, tools like Caja would block all use of XHR other than the >> anonymous kind. > > Exactly, so the off-domain IFRAME is the only option here. I'm not following you. Wrapping untrusted third-party widgets with Caja would not prevent my.yahoo.com from doing XHR on its own behalf. > >> >> Thus, any of the reasonably secure ways to embed a third-party widget would >> not be vulnerable. >> >> >>> >>> What about the UMP-based solution; is it vulnerable? If the page >>> containing the third-party gadget does not also contain the >>> Yahoo!-provided portfolio gadget, then the $UNGUESSABLE_ID is not >>> easily obtained, and so, not really. >> >> Actually, if any page served off of my.yahoo.com contains $UNGUESSABLE_ID, >> and the widget is embedded on the My Yahoo origin and not protected with a >> tool like Cja, then the third-party gadget can trivially get the unguessable >> ID. It doesn't even have to use it right away while the My Yahoo site is >> embedding widgets in an insecure way - it can exfiltrate it for later use at >> the time and place of its choosing. >> > > True. I did not consider this interestingly different, but in retrospect I > was perhaps wrong. It makes it more clear why tools like Caja have to restrict the networking that "Cajoled" content is allowed to do. > >> This is the main risk of UMP compared to CORS. Because secret tokens are the >> only security tool you have, you have the problem of maintaining >> confidentiality of a shared secret. If that shared secret is embedded in Web >> pages you serve, and/or embedded in a URL, that is hard to do. >> > > Agreed. In this particular use case, protecting that URL is probably not > difficult, but it is a general problem. Why do you think so? URLs tend to leak. Browsers store them all over and do not generally treat them like secure information. Users share them freely. If you want to keep something secret, the last thing you want to do is put it in a URL. If I were designing a secret token based defense, at minimum I would use POST and put the secret token in the POST body instead of in the URL. There are also more subtle risks to shared secrets. If you are creating your secrets with a bad random number generator, then they will not in fact be unguessable and you have a huge vulnerability. Even security experts can make this mistake, here is an example that impacted a huge number of people: <http://www.debian.org/security/2008/dsa-1571>. >>> >>> Lastly, if we say that the problem is that My Yahoo! should not have >>> allowed third-party widgets, I will observe that the exact same >>> attacks can occur if the page is simply compromised some other way >>> (through XSS, or code embedded in an ad running on the page). The >>> point of this observation is that what we often believe to be trusted >>> code comes back to bite us. >> >> If the page is compromised through XSS, then the financial data it can >> access will be compromised in any case. >> > > The data is compromised only if the data either is already on the > page, or if it is obtainable. In the CORS without token case, or the > existing server-to-server case, you lose even if the data isn't > already on the page, because it can be fetched without needing to know > anything special. > > In the UMP case (or the CORS+token case), this is only true if the > compromised page can also obtain the $UNGUESSABLE_ID. OK, so there's two vulnerability scenarios: 1) User has the Yahoo Finance gadget embedded on their My Yahoo! page. The My Yahoo! page has an XSS vulnerability. In this case, the XSS attacker can get at your financial data regardless of whether you use an Origin-based scheme, a secret token scheme, or both in combination. 2) User does not currently have the Yahoo Finance gadget embedded on their My Yahoo! page, but does have a Yahoo Finance account. The My Yahoo! page has an XSS vulnerability. In this case, the UMP+ secret token solution will not have a vulnerability - assuming the secret token only gets generated when the user takes an explicit action to authorize the My Yahoo! gadget with Yahoo Finance. You seem to be assuming that a CORS-based solution still has a vulnerability in this case, but I think that's not a valid assumption. With a CORS-based protocol, you would still do per-user authorization. The CORS request carries both an Origin header and a Cookie header, so both the requesting site and the user are known to the service provider. The service provider (Yahoo Finance in this case) should check whether the service consumer (My Yahoo) is authorized for that specific user. In this case, they would not be, since the user is not using the Yahoo Finance gadget. In other words, CORS does not take away your ability to do per-user authorization. In fact, it makes it easier since you don't need to figure out a tricky way to bootstrap into a secret token defense. I think by assuming per-site authorization instead of per-site+user authorization for CORS, you are comparing apples and oranges. It would be like using a per-site "API key" with UMP instead of a per-user secret token. That's a possible (and temptingly simple) way to use UMP, but it would not provide effective security. Thus, I still think your analysis above is flawed. > >> >>> It does suggest (to me) that it's easier to build a credentialled API >>> that is flawed than it is to build a UMP API that is flawed. I think >>> the credentialled solution's problems are more subtle and easier to >>> miss. Perhaps I am unduly biased by my own experience, however. >> >> Since you missed a vulnerability in your own proposed UMP-based solution >> (when running under the same hypothetical conditions as the CORS-based >> solution), I'm not sure it is fair to say that the security flaws with >> credentials are necessarily more subtle. > > I had in mind that the UNGUESSABLE_ID would only appear on that one > page if the Yahoo!-provided widget was used, but I did not state it > clearly, so this is a fair criticism. You are also correct that it may > not be obvious that there needs to be no other way the third-party > widget could fetch a "trusted" page and also get it, which is a subtle > point that should certainly be included in the writeup. See my explanation above for why CORS doesn't have a problem in that scenario either. > > Regardless, it was a subjective assessment, so "fair" is entirely open > to debate ;) > >> >>> >>> Does anyone disagree with my analysis? Are there other considerations >>> or alternatives that I have not included? >> >> I cited what I think are a few flaws in your analysis. I haven't had a >> chance to read the whole thing carefully. >> >> I think a more likely use case for CORS does not involve embedded gadgets at >> all. Consider the example of a social network asking for access to your >> GMail contacts. > > Fair enough. Sounds like a different email thread; I'll see what I can do :) I agree with your comment in another thread that similar scenarios have been discussed at length, and should be written up to incorporate in a security considerations section. The GMail contacts example is interestingly different from the calendar example, because it would be a case of protecting private data rather than exposing an API with side effects. At least, that's the case assuming a read-only contacts interface, which is all that should be needed for this use case. Thus, the primary consideration is confidentiality, not integrity. Confused Deputy problems are primarily an attack on integrity, as I understand it. Regards, Maciej
