- From: Tyler Close <tyler.close@gmail.com>
- Date: Sat, 9 Jan 2010 13:57:52 -0800
- To: Adam Barth <w3c@adambarth.com>
- Cc: public-webapps <public-webapps@w3.org>
On Sat, Jan 9, 2010 at 10:20 AM, Adam Barth <w3c@adambarth.com> wrote: > On Sat, Jan 9, 2010 at 7:23 AM, Tyler Close <tyler.close@gmail.com> wrote: >> Since in general this design cannot be made safe, >> I think it's better to not support it at all in the security model, by >> allowing a uniform request to follow a non-uniform redirect. A >> security model that works for some media-types but not others is just >> too bizarre to explain to developers. > > That's the security model we have. For example, it's safe to return > untrusted HTML tags with certain media types but not with others. Just because the Same Origin Policy is full of bizarre gotchas doesn't mean the UMP must also be. Using the UMP with permission tokens eliminates several of the gotchas. I'm taking every opportunity I can to provide developers with a more reasonable security model. Surely a security expert must applaud this effort. >> This choice doesn't endanger >> existing resources, since CORS also allows a cross-origin request to >> follow a redirect that has not opted out of the Same Origin Policy. > > I'm glad you consider CORS to be the epitome of a secure design. :) Does the smiley imply that you don't consider CORS to be a good example of secure design? For myself, I was merely citing CORS as the original definition for the semantics of the "Access-Control-Allow-Origin: *" header. > (As Maciej says, CORS doesn't appear to have this hole.) Indeed, I misread the section on simple requests: http://www.w3.org/TR/access-control/#simple-cross-origin-request0 I didn't realize the algorithm was checking the response headers in several different places. I guess that's one of the dangers of an algorithmic specification: you must have the whole thing in mind before you can make any statements about what it does or does not do. Given this correction, I'm reconsidering following of non-uniform redirects. I still don't like that it makes it look like your example design is safe, when in fact there are several non-confidentiality problems with it, and using JSON for the final response also breaks confidentiality. > As Maciej says, just because the server can screw up it's > confidentiality doesn't means we should prevent servers from doing the > secure thing. By this argument, we should remove the same-origin > policy entirely because some sites might have XSS vulnerabilities. Deciding to use a popular and standard media-type in its intended setting is not at all comparable to filling your site with XSS vulnerabilities. I did not read Maciej's email as suggesting otherwise. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Received on Saturday, 9 January 2010 21:58:25 UTC