- From: Tyler Close <tyler.close@gmail.com>
- Date: Fri, 14 May 2010 10:18:05 -0700
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Dirk Pranke <dpranke@chromium.org>, public-webapps <public-webapps@w3.org>
On Fri, May 14, 2010 at 1:15 AM, Maciej Stachowiak <mjs@apple.com> wrote: > OK, so there's two vulnerability scenarios: Actually, there is at least one other kind of vulnerability in the CORS design that has not been mentioned by anyone yet and that does not require XSS or untrusted code. Before I describe the attack, I want to remind everyone that the purpose of this particular scenario was to study the usability of CORS and UMP in a benign situation. This example only has a page from Yahoo talking to servers also operated by Yahoo. There are also no side-effects in this example; it's purely a data presentation example. Given that CORS and UMP are new protocols and that this is the most benign scenario we can conjure, I think it's fair to expect a solution with strong security properties. It should be damning if the solution to this very simple scenario introduces complex security problems. First I'll explain a concrete attack against the concrete example, and then I'll generalize it to explain why we should expect this problem to be recurring. The CORS solution to the scenario creates a widely known URL, "http://finance.yahoo.com/api/v1/my_portfolio", that is treated specially when the request happens to come from the my.yahoo.com origin. If you have tunnel vision on only the portfolio widget, then you might see no problem, but there are also other pages with other content on the my.yahoo.com domain. What happens if they make a request to this same URL, could something unexpected and wrong happen? Let's say myYahoo also has a page that fetches the "HotTrade of the Day" and posts its current price to my public activity stream, letting my friends know what investment I'm researching at the moment. The code for this content is audited by Yahoo and is not malicious. The "HotTrade of the day" can be on any market in the world and for anything. It might be hog futures in China or rice in Chicago. The page is used by momentum traders who just want to invest in anything that's moving quickly. Since no site lists the price of everything that can be traded, HotStocks returns the URL to GET the current price. The page content was created by a trading firm that wants to boost trades and attract new customers interested in trading on all of the world's markets. The page content makes the following requests: GET http://hottrades.foo/hotnow HTTP/1.0 Origin: my.yahoo.com HTTP/1.0 200 OK Content-Type: text/plain http://finance.yahoo.com/stock/goog/instaprice and then: GET http://finance.yahoo.com/stock/goog/instaprice HTTP/1.0 Origin: my.yahoo.com HTTP/1.0 200 OK Content-Type: text/plain 510.88 and then: POST http://my.yahoo.com/stream/append HTTP/1.0 Origin: my.yahoo.com Content-Type: text/plain I got my tip at 510.88. Find your price at: http://finance.yahoo.com/stock/goog/instaprice HTTP/1.0 204 OK Later, an attacker causes an unexpected URL to get into the HotTrades tip stream, resulting in the my.yahoo.com page doing the following: GET http://hottrades.foo/hotnow HTTP/1.0 Origin: my.yahoo.com HTTP/1.0 200 OK Content-Type: text/plain http://finance.yahoo.com/api/v1/portfolio/mine and then: GET http://finance.yahoo.com/api/v1/portfolio/mine HTTP/1.0 Origin: my.yahoo.com HTTP/1.0 200 OK Content-Type: application/json { /* all my portfolio data */ } and then: POST http://my.yahoo.com/stream/append HTTP/1.0 Origin: my.yahoo.com Content-Type: text/plain I got my tip at { /* all my portfolio data */ }. Find your price at: http://finance.yahoo.com/api/v1/portfolio/mine HTTP/1.0 204 OK If the Yahoo Finance portfolio was designed to use UMP instead of CORS, this hack would not compromise any private portfolio data since the attacker doesn't know the unguessable secret for anyone's private portfolio. The fundamental problem with the CORS design is that it attaches ambient permission to a well-known URL, the portfolio URL, so code that thinks it is just fetching public data might inadvertently fetch private data and reveal it. What URLs refer to private data versus public data is unknowable by the web content. Any content that fetches public data and then publishes a report on it could fall victim to this kind of attack in a CORS world. For example, earlier Nathan was interested in building a client-side web app that fetched Semantic Web data from a variety of sources, computed on it and produced a result. This app could very easily fall victim to this kind of Confused Deputy attack in a CORS world. How is the app to know which URLs it accesses have ambient permission attached to them that results in private data being returned? In an UMP world, the app can fetch data without attaching any credentials, so knows that anything that comes back must not be user private data. Considered only in isolation, the CORS solution might seem simple and secure[1]. When you consider the effect this code has on the rest of the origin and all the other code running on that origin, it clearly not secure. How is every piece of code in the origin supposed to know what ambient permission URLs have been made accessible to the whole origin, and so might be unsafe to use. This is a recipe for a hairball. Given these Confused Deputy problems and the problems with cookies that Adam points out in his IETF draft, the responsible decision is to leave cookies and other ambient authority out of CORS, at least until the underlying cookie mechanism has been made safe *and* we have safe usage patterns to recommend to CORS application developers. Given that there is also no implementation experience of using CORS with credentials to build applications, these features are also entirely speculative. The responsible decision here is obvious. --Tyler [1] I dispute even that, since Adam has shown how unreliable cookies are. One draft of the cookie spec even recommended against using cookies in any new application. I recommend everyone read the Security Considerations section of Adam's cookie draft <http://tools.ietf.org/html/draft-ietf-httpstate-cookie-08#section-8>. -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Received on Friday, 14 May 2010 17:18:39 UTC