On Fri, May 14, 2010 at 11:27 AM, Dirk Pranke <dpra...@chromium.org> wrote: > On Fri, May 14, 2010 at 10:18 AM, Tyler Close <tyler.cl...@gmail.com> wrote: >> On Fri, May 14, 2010 at 1:15 AM, Maciej Stachowiak <m...@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. >> > > We are talking about enabling a class of functionality (cross-origin > messaging) that isn't currently possible on the web. Obviously if it is > possible to do so securely and easily, that's a good thing. If that is not > possible, and the options are to enable things that have relative degrees > of security or ease of use, then it becomes much more debatable. > "Damning" is a strong word to use in this situation,
If the introduced security problems are complex and therefore hard or infeasible to solve, then "damning" is the right word. If the simple, benign scenario is made infeasible, that's damning. > especially since I > think most people would see the interchange between Maciej and I that > neither solution (CORS or UMP) makes things trivially securable. Another > conclusion could be that doing this stuff is just hard. There's a big difference between "trivially" and infeasible. What are the issues with UMP where we cannot provide concrete guidance to developers? As I've shown, there are hard unknowns in the CORS solution. >> 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. >> > > If the code had been audited, then it is reasonable to assume that someone > would have caught that allowing the HotTrades service to tell the user to > fetch *any url at all* was a bad idea, and the API should have been > restricted to "GET http://finance.yahoo.com/stock/%s/instaprice" instead > of "GET %s". You've changed the scenario so that now HotTrades can only happen on Yahoo listed securities, instead of those listed on any exchange in the world. You have to allow fetching of any URL to make the application work. A possible CORS solution is to check that the URL does not refer back to a user private resource on my.yahoo.com and so do a check on the domain in the URL from HotTrades. However, now you have to wonder about other domains that accept cross-domain requests from my.yahoo.com, such as finance.yahoo.com. How do you list all other domains that might be giving special cross-domain access to my.yahoo.com? You can't; it's an unbounded list that is not even under the control of my.yahoo.com. > This is also what Maciej said in his Don't Be a Deputy > Slides - "Guarantee that requests on behalf of a third party look different > than > your own". How do I make a GET request for public data look different? I look forward to seeing DBAD explained in greater depth. I am completely unconvinced by what has been presented to date. > You are correct that it is possible to use CORS unsafely. It is possible to > use > UMP unsafely, Again, that is broken logic. It is possible to write unsafe code in C++, but it is also possible to write unsafe code in Java, so there's no security difference between the two languages. Please, this illogical argument needs to die. > since - as others have expressed - everything depends on the URL > being unguessable. or putting an unguessable token somewhere else in the request. In CORS, everything depends on the cookie being unguessable and confidential. Adam has shown how hard that is. > Many people seem to feel that this is at least as > great a flaw > as the ambient authority flaw. As you and Maciej discussed, a truly secure solution requires the use of unguessable secrets outside of cookies. Whether you argue for CORS or UMP, you must have techniques for protecting these non-cookie secrets. > So, to me, your argument suggests that we either should not implement > either solution, > which no one will find acceptable, or we should implement a solution > that requires > *both* unguessable tokens and cookies. I don't follow your logic here. We have techniques for protecting unguessable tokens outside of cookies. We know that cookies *don't* provide a good way to protect unguessable tokens. Adam has clearly shown that. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html