Re: [UMP] Feedback on UMP from a quick read
On Jan 9, 2010, at 1:57 PM, Tyler Close wrote: On Sat, Jan 9, 2010 at 10:20 AM, Adam Barth w...@adambarth.com wrote: (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. Thanks for giving this another look. 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. I don't think I suggested otherwise, nor do I think Adam suggested that I suggested otherwise. What I meant to say was that the weak confidentiality protection for ECMAScript should not be used as an excuse to weaken protection for other resources. This is a leaky and awkward hole but it does not justify ignoring more general confidentiality concerns in any context. Adam's analogy was that the widespread existence of XSS bugs is not a reason to remove all cross-domain protection either. While it's not a 100% on-point analogy, I got the point he was making and I recognize that it is similar to my own. Regards, Maciej
Re: [UMP] Feedback on UMP from a quick read
On Sun, Jan 10, 2010 at 6:54 AM, Maciej Stachowiak m...@apple.com wrote: What I meant to say was that the weak confidentiality protection for ECMAScript should not be used as an excuse to weaken protection for other resources. And I was never proposing to weaken existing protection for other resources. My reasoning rested on two points: 1. I thought this redirect behavior was the CORS defined behavior. 2. Even if it's not, this WG is currently defining the security model for newly allowed cross-domain requests. It's reasonable to say that if you refer to a resource using a guessable URL and respond to a uniform GET request with a response marked as accessible by any origin, then there's no confidentiality. This rule has no impact on the security of existing resources, since they don't yet have a Same Origin Policy opt-out header. This rule has the advantage of covering up the bizarre Same Origin Policy handling of ECMAScript data, thus eliminating a dangerous security gotcha for developers. It's bad when developers think they've implemented a design that provides confidentiality, and that turns out not to be true. We should be trying for a simple set of rules that yield easily predictable results. This is a leaky and awkward hole but it does not justify ignoring more general confidentiality concerns in any context. Again, I wasn't doing that. I was looking at one very specific context that doesn't even exist yet, because we're currently defining it. Adam's analogy was that the widespread existence of XSS bugs is not a reason to remove all cross-domain protection either. That would be an extremely foolish thing to propose. I don't think I was being extremely foolish. The analogy is a poor one. While it's not a 100% on-point analogy, I got the point he was making and I recognize that it is similar to my own. In that case, please consider the argument I present at the top of this email. The proposal is different from what you've understood. --Tyler -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
Re: [UMP] Feedback on UMP from a quick read
On Fri, Jan 8, 2010 at 4:56 PM, Adam Barth w...@adambarth.com wrote: On Fri, Jan 8, 2010 at 4:43 PM, Tyler Close tyler.cl...@gmail.com wrote: On Fri, Jan 8, 2010 at 3:56 PM, Adam Barth w...@adambarth.com wrote: [... Requiring uniform responses to redirects ...] It's a good thing to question, since this feature is a relaxation of the model, but it seems valuable and without risk. Can you think of a danger here? Here's an obscure risk: 1) An enterprise (example.com) has a partially open redirector (go.corp.example.com) behind their firewall 2) The redirector will only redirect to *.example.com 3) There is a public site api.example.com that opts into UMP Now the attacker can probe go.corp.example.com by asking for redirects to api.example.com and reading back the response. I actually considered that case and convinced myself that the attacker *could* mount the attack using a form or iframe by timing the request. A working redirect will likely take longer to return than a broken redirect. Also, the attack can work without timing, but using a script tag, if the response can be parsed as ECMAScript. This is especially problematic if the redirector attaches interesting bits to the URLs it directs (like API keys). This attack is not possible with the form element. Any unguessable bits in the redirect URL should not be revealed, since the attacker does not get access to the non-uniform redirect response, even if the final response is a uniform response. This design is also already dangerous, since using a form tag, the attacker can already freely exercise these API keys. You're assuming the API keys are for integrity. What if they're for confidentiality? If the response can be parsed as ECMAScript, an attacker can break confidentiality by loading the document using a script tag. Also, for any media-type, the attacker can mount a clickjacking attack against this design. 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. 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. --Tyler -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
Re: [UMP] Feedback on UMP from a quick read
On Sat, Jan 9, 2010 at 7:23 AM, Tyler Close tyler.cl...@gmail.com wrote: If the response can be parsed as ECMAScript, an attacker can break confidentiality by loading the document using a script tag. 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. Also, for any media-type, the attacker can mount a clickjacking attack against this design. ClickJacking is an integrity attack. I'm worried about confidentiality. 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. 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. :) (As Maciej says, CORS doesn't appear to have this hole.) Adam
Re: [UMP] Feedback on UMP from a quick read
On Fri, Jan 8, 2010 at 3:36 PM, Tyler Close tyler.cl...@gmail.com wrote: On Fri, Jan 8, 2010 at 1:41 PM, Adam Barth w...@adambarth.com wrote: What happens with Set-Cookie headers included in uniform responses? It seems like we ought to ignore them based on the principle that UMP requests are made from a state store / context that is completely separate from the user agents normal state store / context. That's a good point. I'll add text to that effect. This new text is at: http://dev.w3.org/2006/waf/UMP/#state-changes I've also removed the recommendation to omit headers about the user-agent. http://dev.w3.org/2006/waf/UMP/#request-sending Thanks, --Tyler -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
Re: [UMP] Feedback on UMP from a quick read
On Sat, Jan 9, 2010 at 10:20 AM, Adam Barth w...@adambarth.com wrote: On Sat, Jan 9, 2010 at 7:23 AM, Tyler Close tyler.cl...@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
Re: [UMP] Feedback on UMP from a quick read
On Sat, Jan 9, 2010 at 1:57 PM, Tyler Close tyler.cl...@gmail.com wrote: On Sat, Jan 9, 2010 at 10:20 AM, Adam Barth w...@adambarth.com wrote: 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. You're making the security model *weaker* though. Why not make it stronger? Your reaction to a small (i.e., partial) leak of information in one media type is to open the floodgates for leaking all information about all media types. That doesn't make any sense. By way of example, suppose images leaked information about their height and width (which they do!), does that means we should disclose all maner of confidential information stored in HTML documents? 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? My point is more that UMP should be a subset of CORS (which we're selecting based on some principled notions about security). Having the security model for UMP be tighter than CORS in some places and looser than CORS in others doesn't seem like a good idea. Adam
Re: [UMP] Feedback on UMP from a quick read
On Sat, Jan 9, 2010 at 2:23 PM, Adam Barth w...@adambarth.com wrote: On Sat, Jan 9, 2010 at 1:57 PM, Tyler Close tyler.cl...@gmail.com wrote: On Sat, Jan 9, 2010 at 10:20 AM, Adam Barth w...@adambarth.com wrote: 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. You're making the security model *weaker* though. Why not make it stronger? Your reaction to a small (i.e., partial) leak of information in one media type is to open the floodgates for leaking all information about all media types. That doesn't make any sense. Originally, you characterized your scenario as obscure. Now you say it's opening the floodgates. I don't find your frequent outbursts of hyperbole at all constructive. Others have pointed this out more subtly, but I guess you didn't get the hint. In any case, I thought following of non-uniform redirects was the original semantics introduced by CORS and so decided to retain it. Like I said in the last email, I am reconsidering that based on Maciej's correction. And just to be clear. In no reasonable way can either decision be said to open the floodgates. I also don't see any reasonable way to conclude that the UMP security model is weaker than CORS. Those are some pretty outlandish claims to try to prove. --Tyler -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
Re: [UMP] Feedback on UMP from a quick read
On Sat, Jan 9, 2010 at 2:39 PM, Tyler Close tyler.cl...@gmail.com wrote: On Sat, Jan 9, 2010 at 2:23 PM, Adam Barth w...@adambarth.com wrote: On Sat, Jan 9, 2010 at 1:57 PM, Tyler Close tyler.cl...@gmail.com wrote: On Sat, Jan 9, 2010 at 10:20 AM, Adam Barth w...@adambarth.com wrote: 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. You're making the security model *weaker* though. Why not make it stronger? Your reaction to a small (i.e., partial) leak of information in one media type is to open the floodgates for leaking all information about all media types. That doesn't make any sense. Originally, you characterized your scenario as obscure. Now you say it's opening the floodgates. I don't find your frequent outbursts of hyperbole at all constructive. Others have pointed this out more subtly, but I guess you didn't get the hint. The scenario is obscure. My point is that your reasoning doesn't make sense. In any case, I thought following of non-uniform redirects was the original semantics introduced by CORS and so decided to retain it. Like I said in the last email, I am reconsidering that based on Maciej's correction. Great. :) And just to be clear. In no reasonable way can either decision be said to open the floodgates. I also don't see any reasonable way to conclude that the UMP security model is weaker than CORS. Those are some pretty outlandish claims to try to prove. What I'm saying is that it isn't strictly stronger. It's weaker in some places and stronger in others. IMHO, UMP ought to be strictly more secure than CORS. Sure, the cases where it's weaker are obscure, but that doesn't mean we should let UMP have bizarre gotchas. Adam
Re: [UMP] Feedback on UMP from a quick read
One more question: the draft doesn't seem to provide any way to generate a uniform request. Are we planning to have another specification for an API for generating these requests? Adam On Fri, Jan 8, 2010 at 1:41 PM, Adam Barth w...@adambarth.com wrote: [[ In particular, the user agent should not add the HTTP headers: User-Agent, Accept, Accept-Language, Accept-Encoding, or Accept-Charset ]] This seems a bit overly constrictive. Maybe we should send Accept: */*, etc? More generally, I suspect the requirements in Section 3.2 violate various HTTP RFCs. Maybe we should use the term willful violation somewhere? [[ If the response to a uniform request is an HTTP redirect, it is handled as specified by [HTTP], whether or not the redirect is itself a uniform response. If the redirect is not a uniform response, the user-agent must still prevent the requesting content from accessing the content of the redirect itself, though a response to a redirected request might be accessible if it is a uniform response. If the response to a uniform request is an HTTP redirect, any redirected request must also be a uniform request. ]] This seems looser than needed. It would be better if the redirect had to be a uniform response also. There's a note in the spec The HTML form element can also follow any redirect, without restriction by the Same Origin Policy, but the form element also sends Accept and User-Agent headers. What's the reason for excluding the headers but not requiring redirects to be uniform responses? What happens with Set-Cookie headers included in uniform responses? It seems like we ought to ignore them based on the principle that UMP requests are made from a state store / context that is completely separate from the user agents normal state store / context. Adam
Re: [UMP] Feedback on UMP from a quick read
On Fri, Jan 8, 2010 at 1:41 PM, Adam Barth w...@adambarth.com wrote: [[ In particular, the user agent should not add the HTTP headers: User-Agent, Accept, Accept-Language, Accept-Encoding, or Accept-Charset ]] This seems a bit overly constrictive. Maybe we should send Accept: */*, etc? More generally, I suspect the requirements in Section 3.2 violate various HTTP RFCs. Maybe we should use the term willful violation somewhere? Which RFCs are you referring to? AFAIK, Section 3.2 doesn't violate any MUST requirement in any relevant RFC. There are two uses for this requirement: 1. On browsers that don't yet support any cross-domain API, it would be nice to emulate support by routing the request through the requestor's Origin server. To help ensure the response is the same whether it was sent directly from the user agent or via the Origin server, we omit any information about the sending software. 2. Omitting these headers can significantly reduce message size and so improve performance. [[ If the response to a uniform request is an HTTP redirect, it is handled as specified by [HTTP], whether or not the redirect is itself a uniform response. If the redirect is not a uniform response, the user-agent must still prevent the requesting content from accessing the content of the redirect itself, though a response to a redirected request might be accessible if it is a uniform response. If the response to a uniform request is an HTTP redirect, any redirected request must also be a uniform request. ]] This seems looser than needed. It would be better if the redirect had to be a uniform response also. There's a note in the spec The HTML form element can also follow any redirect, without restriction by the Same Origin Policy, but the form element also sends Accept and User-Agent headers. What's the reason for excluding the headers but not requiring redirects to be uniform responses? Somewhere in the list archives, I believe there's a message that pointed out a need to remain compatible with existing HTTP redirection software that cannot be (or won't be) updated to include the new header. For example, if the page receives a URL from a URL shortening service, it would be nice to be able to complete the request even if the URL shortening service doesn't return uniform response redirects. The form argument makes it clear that following a non-uniform redirect doesn't introduce a security vulnerability. AFAICT, this feature also doesn't lead the resource author into any poor design choices. It's a good thing to question, since this feature is a relaxation of the model, but it seems valuable and without risk. Can you think of a danger here? What happens with Set-Cookie headers included in uniform responses? It seems like we ought to ignore them based on the principle that UMP requests are made from a state store / context that is completely separate from the user agents normal state store / context. That's a good point. I'll add text to that effect. Thanks, --Tyler -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
Re: [UMP] Feedback on UMP from a quick read
On Fri, Jan 8, 2010 at 2:53 PM, Adam Barth w...@adambarth.com wrote: One more question: the draft doesn't seem to provide any way to generate a uniform request. Are we planning to have another specification for an API for generating these requests? Similar to CORS, UMP is just the security model; separate API specs define the API for making requests under that model. So, as XHR2 is to CORS, a yet-to-come UniformRequest is to UMP. --Tyler -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
Re: [UMP] Feedback on UMP from a quick read
On Fri, Jan 8, 2010 at 3:36 PM, Tyler Close tyler.cl...@gmail.com wrote: There are two uses for this requirement: 1. On browsers that don't yet support any cross-domain API, it would be nice to emulate support by routing the request through the requestor's Origin server. To help ensure the response is the same whether it was sent directly from the user agent or via the Origin server, we omit any information about the sending software. If this is an important consideration, then the server software can just copy the relevant headers. I'm not sure there's a good security case to be made here for deviating from standard operating procedure. It seems quite sensible to send an Accept header of */* instead of omitting the header. 2. Omitting these headers can significantly reduce message size and so improve performance. This seems like premature optimization to me. Do you have benchmarks that show this has any impact on page load time (or any other metric you think is interesting)? [... Requiring uniform responses to redirects ...] It's a good thing to question, since this feature is a relaxation of the model, but it seems valuable and without risk. Can you think of a danger here? Here's an obscure risk: 1) An enterprise (example.com) has a partially open redirector (go.corp.example.com) behind their firewall 2) The redirector will only redirect to *.example.com 3) There is a public site api.example.com that opts into UMP Now the attacker can probe go.corp.example.com by asking for redirects to api.example.com and reading back the response. This is especially problematic if the redirector attaches interesting bits to the URLs it directs (like API keys). This attack is not possible with the form element. Adam
Re: [UMP] Feedback on UMP from a quick read
On Fri, Jan 8, 2010 at 3:56 PM, Adam Barth w...@adambarth.com wrote: On Fri, Jan 8, 2010 at 3:36 PM, Tyler Close tyler.cl...@gmail.com wrote: There are two uses for this requirement: 1. On browsers that don't yet support any cross-domain API, it would be nice to emulate support by routing the request through the requestor's Origin server. To help ensure the response is the same whether it was sent directly from the user agent or via the Origin server, we omit any information about the sending software. If this is an important consideration, then the server software can just copy the relevant headers. I'm not sure there's a good security case to be made here for deviating from standard operating procedure. It seems quite sensible to send an Accept header of */* instead of omitting the header. I'm not making a security argument here, just an engineering one. It seems simpler and more efficient this way. 2. Omitting these headers can significantly reduce message size and so improve performance. This seems like premature optimization to me. Do you have benchmarks that show this has any impact on page load time (or any other metric you think is interesting)? Reading Steve Souders stuff has impressed upon me the cost of message size overhead. If you just open up a Firebug console, it's clear that these headers are eating up a significant fraction of the MTU and so splitting messages that should've gone over the wire in a single packet. All that said, perhaps it makes more sense to move this recommendation to individual UMP API specs, such as UniformRequest, rather than deal with it in the UMP spec, leaving it as purely about the security model. At the very least, that delays the controversy. I'll remove the text from the UMP spec. [... Requiring uniform responses to redirects ...] It's a good thing to question, since this feature is a relaxation of the model, but it seems valuable and without risk. Can you think of a danger here? Here's an obscure risk: 1) An enterprise (example.com) has a partially open redirector (go.corp.example.com) behind their firewall 2) The redirector will only redirect to *.example.com 3) There is a public site api.example.com that opts into UMP Now the attacker can probe go.corp.example.com by asking for redirects to api.example.com and reading back the response. I actually considered that case and convinced myself that the attacker *could* mount the attack using a form or iframe by timing the request. A working redirect will likely take longer to return than a broken redirect. Also, the attack can work without timing, but using a script tag, if the response can be parsed as ECMAScript. This is especially problematic if the redirector attaches interesting bits to the URLs it directs (like API keys). This attack is not possible with the form element. Any unguessable bits in the redirect URL should not be revealed, since the attacker does not get access to the non-uniform redirect response, even if the final response is a uniform response. This design is also already dangerous, since using a form tag, the attacker can already freely exercise these API keys. --Tyler -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
Re: [UMP] Feedback on UMP from a quick read
On Fri, Jan 8, 2010 at 4:43 PM, Tyler Close tyler.cl...@gmail.com wrote: On Fri, Jan 8, 2010 at 3:56 PM, Adam Barth w...@adambarth.com wrote: [... Requiring uniform responses to redirects ...] It's a good thing to question, since this feature is a relaxation of the model, but it seems valuable and without risk. Can you think of a danger here? Here's an obscure risk: 1) An enterprise (example.com) has a partially open redirector (go.corp.example.com) behind their firewall 2) The redirector will only redirect to *.example.com 3) There is a public site api.example.com that opts into UMP Now the attacker can probe go.corp.example.com by asking for redirects to api.example.com and reading back the response. I actually considered that case and convinced myself that the attacker *could* mount the attack using a form or iframe by timing the request. A working redirect will likely take longer to return than a broken redirect. Also, the attack can work without timing, but using a script tag, if the response can be parsed as ECMAScript. This is especially problematic if the redirector attaches interesting bits to the URLs it directs (like API keys). This attack is not possible with the form element. Any unguessable bits in the redirect URL should not be revealed, since the attacker does not get access to the non-uniform redirect response, even if the final response is a uniform response. This design is also already dangerous, since using a form tag, the attacker can already freely exercise these API keys. You're assuming the API keys are for integrity. What if they're for confidentiality? Adam
