|
 RE: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)
> -----Original Message-----
> From: Mark Nottingham [mailto: mnot@...]
> Sent: Tuesday, February 10, 2009 4:31 PM
>
> My understanding of the discussion's resolution was that this is not a
> goal for this spec any more; i.e., if there's any boundary-hopping, it
> will be defined by the protocol or application in use.
The only use case for finding out information about email addresses through host-meta is no longer in consideration. It was dropped mostly due to the fact that mailto URIs do not have an authority which means in order to go from a mailto URI to a host-meta authority, one has to write special handling specific for that URI scheme. This is not something we wanted to do in either host-meta or the discovery spec [1].
If the OpenID community wants to support email identifiers, they should find a way to address that at the application level, including dealing with all the authority and security issues it raises.
> I'm happy to clarify this by either adding scheme/protocol to the
> (host, port) tuple (although we'll probably have to come up with a
> different term than "authority"; PLEASE don't say "endpoint" ;), which
> will affect both the default scoping of application as well as the
> discovery mechanism, or just limiting it to discovery.
First, scheme is incorrect here as the scheme does not always determine a specific protocol (see 'http' is not just for HTTP saga). There are two ways in which a host-meta file can be obtained:
1. Given a host/port/protocol, the client can connect to the host/port and speak the protocol to obtain the resource /host-meta.
2. Given a URI, the client can connect to the host/port of the URI authority, speak the implied protocol from the URI scheme, and ask for the /host-meta resource. The resulting document is scoped for the host/port/protocol used.
Now, if someone had a mailto: URI, they could decide that for that application (which is likely to be an HTTP application) they are going to use the HTTP protocol with the domain name (and default port 80) of the email address. But again, that is outside the scope of our effort.
EHL
|
|
Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)
On Tue, Feb 10, 2009 at 11:37 PM, Eran Hammer-Lahav < eran@...> wrote:
> First, scheme is incorrect here as the scheme does not always determine a specific protocol
> (see 'http' is not just for HTTP saga).
I don't understand this level of pedantry, but if you want host-meta
to be usable by Web browsers, you should use the algorithm in
draft-abarth-origin to compute its scope from its URL. Any deviations
from this algorithm will introduce cracks in the browser's security
policy.
Adam
|
|
Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)
Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)
I don’t care of this level of pedantry which is why I don’t want to use terms that people have a problem agreeing what it means.
There is nothing incorrect about: GET joe@... HTTP/1.1
It might look funny to most people but it is perfectly valid. The protocol is HTTP, the scheme is mailto. HTTP can talk about any URI, not just http URIs. Since this is about *how* /host-meta is obtained, it should talk about protocol, not scheme.
EHL
On 2/11/09 10:18 AM, "Adam Barth" <w3c@...> wrote:
On Tue, Feb 10, 2009 at 11:37 PM, Eran Hammer-Lahav <eran@...> wrote:
> First, scheme is incorrect here as the scheme does not always determine a specific protocol
> (see 'http' is not just for HTTP saga).
I don't understand this level of pedantry, but if you want host-meta
to be usable by Web browsers, you should use the algorithm in
draft-abarth-origin to compute its scope from its URL. Any deviations
from this algorithm will introduce cracks in the browser's security
policy.
Adam
|
|
Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)
On Wed, Feb 11, 2009 at 11:55 AM, Eran Hammer-Lahav < eran@...> wrote:
> There is nothing incorrect about: GET mailto: joe@... HTTP/1.1
I don't know how to get a Web browser to generate such a request, so I
am unable to assess its security implications.
> It might look funny to most people but it is perfectly valid. The protocol
> is HTTP, the scheme is mailto. HTTP can talk about any URI, not just http
> URIs. Since this is about *how* /host-meta is obtained, it should talk about
> protocol, not scheme.
Here's my understanding of how this should work (ignoring redirects
for the moment). Please correct me if my understanding is incorrect
or incomplete:
1) The user agent retrieves the host-meta file by requesting a certain
URL from the network layer.
2) The network layer does some magic involving protocols and
electrical signals on wires and returns a sequence of bytes.
3) The user agent now must compute a scope for the retrieved host-meta file.
I recommend that the scope for the host-meta file be determined from
the URL irrespective of whatever magic goes on in step 2. because this
is the way all other security scopes are computed in Web browsers.
For example, if I view an HTML document location at
http://example.com/index.html, its security origin is (http,
example.com, 80) regardless of whether the HTML document was actually
retrieved by carrier pigeon or SMTP.
(To handle redirects, by the way, you have to use the last URL in the
redirect chain.)
Adam
|
|
Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)
I have to say that the current known use-cases for site-meta are: 1. Security critical ones, but for server-to-server discovery uses (not browser mediated) 2. Semantic ones, for user consumption, of an informative rather than security-critical nature. These use cases may be handled by browsers.
I agree that it is worth to look at the security consequences, but at least to me at this point, it is not clear that the traditional same-policy paradigm used by browsers is relevant here.
On Wed, Feb 11, 2009 at 12:38 PM, Adam Barth <w3c@...> wrote:
On Wed, Feb 11, 2009 at 11:55 AM, Eran Hammer-Lahav < eran@...> wrote:
> There is nothing incorrect about: GET mailto: joe@... HTTP/1.1
am unable to assess its security implications.
> It might look funny to most people but it is perfectly valid. The protocol
> is HTTP, the scheme is mailto. HTTP can talk about any URI, not just http
> URIs. Since this is about *how* /host-meta is obtained, it should talk about
> protocol, not scheme.
Here's my understanding of how this should work (ignoring redirects
for the moment). Please correct me if my understanding is incorrect
or incomplete:
1) The user agent retrieves the host-meta file by requesting a certain
URL from the network layer.
2) The network layer does some magic involving protocols and
electrical signals on wires and returns a sequence of bytes.
3) The user agent now must compute a scope for the retrieved host-meta file.
I recommend that the scope for the host-meta file be determined from
the URL irrespective of whatever magic goes on in step 2. because this
is the way all other security scopes are computed in Web browsers.
For example, if I view an HTML document location at
http://example.com/index.html, its security origin is (http,
example.com, 80) regardless of whether the HTML document was actually
retrieved by carrier pigeon or SMTP.
(To handle redirects, by the way, you have to use the last URL in the
redirect chain.)
Adam
-- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7)
|
|
Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)
|
|
Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)
On Wed, Feb 11, 2009 at 1:26 PM, Adam Barth <w3c@...> wrote:
On Wed, Feb 11, 2009 at 1:04 PM, Breno de Medeiros < breno@...> wrote:
> I have to say that the current known use-cases for site-meta are:
>
> 1. Security critical ones, but for server-to-server discovery uses (not
> browser mediated)
>
> 2. Semantic ones, for user consumption, of an informative rather than
> security-critical nature. These use cases may be handled by browsers.
would be eminently useful to be able to express X-Content-Type-Options
[1] and X-Frame-Options [2] in a centralized metadata store instead of
wasting bandwidth on every HTTP response (as Google does for
X-Content-Type-Options). I don't think anyone doubts that we're going
to see a proliferation of this kind of security metadata, e.g., along
the lines of [3]. I don't see the point of making a central metadata
store that ignores these important use cases.
The current proposal for host-meta addresses some use cases that today simply _cannot_ be addressed without it. Your proposal restricts the discovery process in ways that may have unintended consequences in terms of prohibiting future uses. This is so that browsers can avoid implementing same-domain policy checks at the application layer?
Adam
[1] http://blogs.msdn.com/ie/archive/2008/09/02/ie8-security-part-vi-beta-2-update.aspx
[2] https://blogs.msdn.com/ie/archive/2009/01/27/ie8-security-part-vii-clickjacking-defenses.aspx
[3] http://people.mozilla.org/~bsterne/content-security-policy/
-- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7)
|
|
Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)
On Wed, Feb 11, 2009 at 1:46 PM, Breno de Medeiros < breno@...> wrote:
> The current proposal for host-meta addresses some use cases that today
> simply _cannot_ be addressed without it.
I'm not familiar our process for adopting new use cases, but let's
think more carefully about one of the listed use cases:
On Wed, Feb 11, 2009 at 1:04 PM, Breno de Medeiros < breno@...> wrote:
> 1. Security critical ones, but for server-to-server discovery uses (not
> browser mediated)
To serve this use case, we should require that the host-meta file be
served with a specific, novel content type. Without this requirement,
servers that try to use the host-meta file for security-critical
server-to-server discovery will be tricked by attackers who upload
fake host-meta files to unknowing servers.
> Your proposal restricts the
> discovery process in ways that may have unintended consequences in terms of
> prohibiting future uses.
How does requiring a specific Content-Type prohibit future uses?
> This is so that browsers can avoid implementing
> same-domain policy checks at the application layer?
No, this is to protect servers that let attackers upload previously
benign content to now-magical paths.
Adam
|
|
Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)
On Wed, Feb 11, 2009 at 2:01 PM, Adam Barth <w3c@...> wrote:
On Wed, Feb 11, 2009 at 1:46 PM, Breno de Medeiros < breno@...> wrote:
> The current proposal for host-meta addresses some use cases that today
> simply _cannot_ be addressed without it.
think more carefully about one of the listed use cases:
On Wed, Feb 11, 2009 at 1:04 PM, Breno de Medeiros < breno@...> wrote:
> 1. Security critical ones, but for server-to-server discovery uses (not
> browser mediated)
To serve this use case, we should require that the host-meta file be
served with a specific, novel content type. Without this requirement,
servers that try to use the host-meta file for security-critical
server-to-server discovery will be tricked by attackers who upload
fake host-meta files to unknowing servers.
> Your proposal restricts the
> discovery process in ways that may have unintended consequences in terms of
> prohibiting future uses.
How does requiring a specific Content-Type prohibit future uses?
> This is so that browsers can avoid implementing
> same-domain policy checks at the application layer?
No, this is to protect servers that let attackers upload previously
benign content to now-magical paths.
1. The mechanism is not sufficient strong to prevent against defacing attacks. An attacker that can upload a file and choose how to set the content-type would be able to implement the attack. If servers are willing to let users upload files willy-nilly, and do not worry about magical paths, will they worry about magical content types?
2. This technique may prevent legitimate uses of the spec by developers who do not have the ability to set the appropriate header.
Is this more likely to prevent legitimate developers from getting things done than to prevent attacks from spoofing said magical paths? I would say yes.
Defacing attacks are a threat to applications relying on this spec, and they should be explicitly aware of it rather than have a false sense of security based on ad-hoc mitigation techniques. For instance, for XRD discovery there is work on a trust profile using signatures that operates on the basic principle that 'the way to get the resource is fundamentally untrustworthy, let the resources be self-validating.'
Adam
-- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7)
|
|
Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)
On Wed, Feb 11, 2009 at 2:15 PM, Breno de Medeiros < breno@...> wrote:
> 1. The mechanism is not sufficient strong to prevent against defacing
> attacks.
We're not worried about defacement attacks. We're worried about Web
servers that explicitly allow their users to upload content. For
example:
1) Webmail providers (e.g., Gmail) let users upload attachments.
2) Forums let users upload avatar images.
3) Wikipedia lets users upload various types of content.
> An attacker that can upload a file and choose how to set the
> content-type would be able to implement the attack. If servers are willing
> to let users upload files willy-nilly, and do not worry about magical paths,
> will they worry about magical content types?
In fact, none of these servers let users specify arbitrary content
types. They restrict the content type of resources to protect
themselves from XSS attacks to an to ensure that they function
properly.
> 2. This technique may prevent legitimate uses of the spec by developers who
> do not have the ability to set the appropriate header.
Many developers can control Content-Type headers using .htaccess files
(and their ilk).
> Is this more likely to prevent legitimate developers from getting things
> done than to prevent attacks from spoofing said magical paths? I would say
> yes.
What is your evidence for this claim? My evidence for this being a
serious security issue is the experience of Adobe with their
crossdomain.xml file. They started out with the same design you
currently use and were forced to add strict Content-Type handling to
protect Web sites from this very attack. What is different about your
policy file system that will prevent you from falling into the same
trap?
> Defacing attacks are a threat to applications relying on this spec,
We're not talking about defacement attacks.
> and they
> should be explicitly aware of it rather than have a false sense of security
> based on ad-hoc mitigation techniques.
This mechanism does not provide a false sense of security. In fact,
it provides real security today for Adobe's crossdomain.xml policy
file and for a similar Gears feature. (Gears also started with your
design and was forced to patch their users.)
Adam
|
|
Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)
On 2/11/09 12:38 PM, "Adam Barth" < w3c@...> wrote:
> On Wed, Feb 11, 2009 at 11:55 AM, Eran Hammer-Lahav < eran@...>
> wrote:
>> There is nothing incorrect about: GET mailto: joe@... HTTP/1.1
>
> I don't know how to get a Web browser to generate such a request, so I
> am unable to assess its security implications.
It really does not matter what a browser will do with such URI. This example
is not really of interest to a browser because that would imply that the
mailto URI has some visual representation the user wants to see. No such
representation exists today for the user to ask for and the brower to show.
But an application with full access to the HTTP protocol can use it to
obtain some representation of the URI that will mean something to it.
>> It might look funny to most people but it is perfectly valid. The protocol
>> is HTTP, the scheme is mailto. HTTP can talk about any URI, not just http
>> URIs. Since this is about *how* /host-meta is obtained, it should talk about
>> protocol, not scheme.
>
> Here's my understanding of how this should work (ignoring redirects
> for the moment). Please correct me if my understanding is incorrect
> or incomplete:
>
> 1) The user agent retrieves the host-meta file by requesting a certain
> URL from the network layer.
>
> 2) The network layer does some magic involving protocols and
> electrical signals on wires and returns a sequence of bytes.
>
> 3) The user agent now must compute a scope for the retrieved host-meta file.
>
> I recommend that the scope for the host-meta file be determined from
> the URL irrespective of whatever magic goes on in step 2. because this
> is the way all other security scopes are computed in Web browsers.
> For example, if I view an HTML document location at
> http://example.com/index.html, its security origin is (http,
> example.com, 80) regardless of whether the HTML document was actually
> retrieved by carrier pigeon or SMTP.
You got this backwards. You decide what the scope is, you get the document
for that scope, you use it.
1. You want to find out more about example.com on port 80 speaking HTTP.
2. You want to find out more about http://example.com/resource/1 (and care
about the HTTP representation).
In both cases, you will do:
GET /host-meta HTTP/1.1
Host: example.com:80
While this document can be identified with http://example.com/host-meta,
that URI alone is not enough to declare its scope. The fact you used HTTP to
obtain a representation of this URI is also needed. Again, protocol and
scheme are not the same thing.
Now, how do you know that what you got is authorized/trusted/unspoofed/etc?
You don't based on what the host-meta spec is offering. If you need that,
specify it in your application. If a bunch of people agree on how to add
security to this, we can address it separately.
Your argument is that without such security, this whole thing is useless. We
obviously disagree.
EHL
|
|
Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)
On Wed, Feb 11, 2009 at 2:36 PM, Adam Barth <w3c@...> wrote:
On Wed, Feb 11, 2009 at 2:15 PM, Breno de Medeiros < breno@...> wrote:
> 1. The mechanism is not sufficient strong to prevent against defacing
> attacks.
servers that explicitly allow their users to upload content. For
example:
1) Webmail providers (e.g., Gmail) let users upload attachments.
2) Forums let users upload avatar images.
3) Wikipedia lets users upload various types of content.
> An attacker that can upload a file and choose how to set the
> content-type would be able to implement the attack. If servers are willing
> to let users upload files willy-nilly, and do not worry about magical paths,
> will they worry about magical content types?
In fact, none of these servers let users specify arbitrary content
types. They restrict the content type of resources to protect
themselves from XSS attacks to an to ensure that they function
properly.
For some purposes, such as the one you described, putting a host-meta almost anywhere in a site could expose a browser to attacks similar to the ones that crossdomain.xml presented. However, such applications could handle specifying content-type as a requirement, as Eran rightly pointed out.
> 2. This technique may prevent legitimate uses of the spec by developers who
> do not have the ability to set the appropriate header.
Many developers can control Content-Type headers using .htaccess files
(and their ilk).
And many others cannot. This is particularly irksome in outsourcing situations where you have only partial control of the hosting environment or depend on non-technical users to perform administrative tasks.
> Is this more likely to prevent legitimate developers from getting things
> done than to prevent attacks from spoofing said magical paths? I would say
> yes.
What is your evidence for this claim? My evidence for this being a
serious security issue is the experience of Adobe with their
crossdomain.xml file. They started out with the same design you
currently use and were forced to add strict Content-Type handling to
protect Web sites from this very attack. What is different about your
policy file system that will prevent you from falling into the same
trap?
The difference being that cross-domain.xml is intended primarily for browser use and therefore optimization for that case sounds legitimate. This is not the case here.
Again, again, there is an application layer where browsers can implement such policies.
> Defacing attacks are a threat to applications relying on this spec,
We're not talking about defacement attacks.
> and they
> should be explicitly aware of it rather than have a false sense of security
> based on ad-hoc mitigation techniques.
This mechanism does not provide a false sense of security. In fact,
it provides real security today for Adobe's crossdomain.xml policy
file and for a similar Gears feature. (Gears also started with your
design and was forced to patch their users.)
Adam
-- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7)
|
|
Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)
On Wed, Feb 11, 2009 at 2:44 PM, Eran Hammer-Lahav < eran@...> wrote:
> You got this backwards.
Ah. Thanks for this response. I understand the situation much better now.
Let me see if I understand this correctly for the case of the https scheme.
1. You want to find out more about example.com on port 443 speaking
HTTP-over-TLS.
2. You want to find out more about https://example.com/resource/1 (and
care about the HTTP-over-TLS representation).
In both cases, you will do (wrapped in a TLS session):
GET /host-meta HTTP/1.1
Host: example.com:443
Your point is that a Web browser would never want to find out more
about https://example.com/resource/1 and care about the HTTP
representation (it would always be interested in the HTTP-over-TLS
representation).
Thanks,
Adam
|
|
Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)
Exactly. Does that addresses your concern about scope?
(we can continue debating the value of the content type header as a measure
of security if you'd like...)
EHL
On 2/11/09 2:58 PM, "Adam Barth" < w3c@...> wrote:
> On Wed, Feb 11, 2009 at 2:44 PM, Eran Hammer-Lahav < eran@...>
> wrote:
>> You got this backwards.
>
> Ah. Thanks for this response. I understand the situation much better now.
>
> Let me see if I understand this correctly for the case of the https scheme.
>
> 1. You want to find out more about example.com on port 443 speaking
> HTTP-over-TLS.
> 2. You want to find out more about https://example.com/resource/1 (and
> care about the HTTP-over-TLS representation).
>
> In both cases, you will do (wrapped in a TLS session):
>
> GET /host-meta HTTP/1.1
> Host: example.com:443
>
> Your point is that a Web browser would never want to find out more
> about https://example.com/resource/1 and care about the HTTP
> representation (it would always be interested in the HTTP-over-TLS
> representation).
>
> Thanks,
> Adam
>
|
|
Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)
On Wed, Feb 11, 2009 at 3:04 PM, Eran Hammer-Lahav < eran@...> wrote:
> Exactly. Does that addresses your concern about scope?
Yes. I think we should make it clearer in the spec that host-meta's
scope is restricted by protocol. As a browser developer, I find the
current spec confusing on this point.
> (we can continue debating the value of the content type header as a measure
> of security if you'd like...)
(I'm composing a reply to Breno now.)
Adam
|
|
Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)
On Wed, Feb 11, 2009 at 2:46 PM, Breno de Medeiros < breno@...> wrote:
> However, such applications could handle
> specifying content-type as a requirement, as Eran rightly pointed out.
Why force everyone interested in use case (1) to add this requirement?
This will have two results:
1) Some application will forget to add this requirement and be
vulnerable to attack.
2) A service that requires the well-known Content-Type will not be
able to inter-operate with a server that takes advantage of the laxity
of this spec.
>> What is different about your
>> policy file system that will prevent you from falling into the same
>> trap?
>
> The difference being that cross-domain.xml is intended primarily for browser
> use and therefore optimization for that case sounds legitimate. This is not
> the case here.
We're discussing security-critical server-to-server discovery, which
is the first use-case you listed.
> Again, again, there is an application layer where browsers can implement
> such policies.
Sure, you can punt all security problems to the application layer
because I can't construct attacks without a complete system.
It sounds like there are three resolutions to this issues:
1) Require host-meta to be served with a particular, novel Content-Type.
2) Add a section to Security Considerations that explains that
applications using host-meta should consider adding requirement (1).
3) Ignore these attacks.
My opinion is that (3) will cause users of this spec a great deal of
pain. I also think that (2) will cause users of this spec pain
because they'll ignore the warning and construct insecure systems.
By the way, there is a fourth solution, which I suspect you'll find
unappealing for the same reason you find (1) unappealing: use a method
other than GET to retrieve host-meta. For example, CORS uses OPTIONS
for a similar purpose.
Adam
|
|
Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)
On Wed, Feb 11, 2009 at 3:22 PM, Adam Barth <w3c@...> wrote:
On Wed, Feb 11, 2009 at 2:46 PM, Breno de Medeiros < breno@...> wrote:
> However, such applications could handle
> specifying content-type as a requirement, as Eran rightly pointed out.
This will have two results:
1) Some application will forget to add this requirement and be
vulnerable to attack.
2) A service that requires the well-known Content-Type will not be
able to inter-operate with a server that takes advantage of the laxity
of this spec.
>> What is different about your
>> policy file system that will prevent you from falling into the same
>> trap?
>
> The difference being that cross-domain.xml is intended primarily for browser
> use and therefore optimization for that case sounds legitimate. This is not
> the case here.
We're discussing security-critical server-to-server discovery, which
is the first use-case you listed.
In that case, content-type is a mild defense. Can you give me an example where a web-site administrator will allow files to be hosted at '/'? I can find some fairly interesting names to host at '/'
E.g.: favicon.ico, .htaccess, robots.txt, ...
Trying to secure such environments seems to me a waste of time, quite frankly.
The most interesting threat of files uploaded to root is via defacement. This solution does nothing against that threat.
> Again, again, there is an application layer where browsers can implement
> such policies.
Sure, you can punt all security problems to the application layer
because I can't construct attacks without a complete system.
It sounds like there are three resolutions to this issues:
1) Require host-meta to be served with a particular, novel Content-Type.
Not feasible, because of limitations on developers that implement these server-to-server techniques.
2) Add a section to Security Considerations that explains that
applications using host-meta should consider adding requirement (1).
No. I would suggest adding a Security Considerations that say that host-meta SHOULD NOT be relied upon for ANY security-sensitive purposes _of_its_own_, and that applications that require levels of integrity against defacement attacks, etc., should implement real security techniques. Frankly, I think content-type does very little for security of such applications.
3) Ignore these attacks.
My opinion is that (3) will cause users of this spec a great deal of
pain. I also think that (2) will cause users of this spec pain
because they'll ignore the warning and construct insecure systems.
By the way, there is a fourth solution, which I suspect you'll find
unappealing for the same reason you find (1) unappealing: use a method
other than GET to retrieve host-meta. For example, CORS uses OPTIONS
for a similar purpose.
Adam
-- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7)
|
|
Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)
On Wed, Feb 11, 2009 at 3:32 PM, Breno de Medeiros < breno@...> wrote:
> In that case, content-type is a mild defense. Can you give me an example
> where a web-site administrator will allow files to be hosted at '/'?
There are enough of these sites to force Adobe to break backwards
compatibility in a Flash security release.
> I can find some fairly interesting names to host at '/'
>
> E.g.: favicon.ico, .htaccess, robots.txt, ...
OMG, you changed my favicon! .htaccess only matters if Apache
interprets it (e.g., uploading an .htaccess file to Gmail doesn't do
anything interesting).
> Trying to secure such environments seems to me a waste of time, quite
> frankly.
Clearly, Adobe doesn't share your opinion.
> The most interesting threat of files uploaded to root is via defacement.
> This solution does nothing against that threat.
I you can deface my server, then I've got big problems already (e.g.,
my Web site is totally hacked). Not addressing this issue creates a
security problem where none currently exists.
>> 1) Require host-meta to be served with a particular, novel Content-Type.
>
> Not feasible, because of limitations on developers that implement these
> server-to-server techniques.
That's an opinion. We'll see if you're forced to patch the spec when
you're confronted with a horde of Web servers that you've just made
vulnerable to attack.
>> 2) Add a section to Security Considerations that explains that
>> applications using host-meta should consider adding requirement (1).
>
> No. I would suggest adding a Security Considerations that say that host-meta
> SHOULD NOT be relied upon for ANY security-sensitive purposes _of_its_own_,
Then how are we to address use case (1)?
> and that applications that require levels of integrity against defacement
> attacks, etc., should implement real security techniques. Frankly, I think
> content-type does very little for security of such applications.
Your argument for why strict Content-Type handling is insecure is that
a more powerful attacker can win anyway. My argument is that we have
implementation experience that we need to defend against these
threats.
I did a little more digging, and it looks like Silverlight's
clientaccesspolicy.xml also requires strict Content-Type processing:
http://msdn.microsoft.com/en-us/library/cc645032(VS.95).aspxThat makes 3 out of 3 systems that use strict Content-Type processing.
Microsoft's solution to the limited hosting environment problem
appears to be quite clever, actually. I couldn't find documentation
(and haven't put in the effort to reverse engineer the behavior), but
it looks like they require a content type of applciation/xml, which
they get for free from limiting hosting providers by naming their file
with a ".xml" extension. This is clever, because it protects all the
sites I listed earlier because those sites would have XSS if they let
an attacker control an application/xml resource on their server.
Adam
|
|
Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)
On Wed, Feb 11, 2009 at 3:57 PM, Adam Barth <w3c@...> wrote:
On Wed, Feb 11, 2009 at 3:32 PM, Breno de Medeiros < breno@...> wrote:
> In that case, content-type is a mild defense. Can you give me an example
> where a web-site administrator will allow files to be hosted at '/'?
compatibility in a Flash security release.
> I can find some fairly interesting names to host at '/'
>
> E.g.: favicon.ico, .htaccess, robots.txt, ...
OMG, you changed my favicon! .htaccess only matters if Apache
interprets it (e.g., uploading an .htaccess file to Gmail doesn't do
anything interesting).
> Trying to secure such environments seems to me a waste of time, quite
> frankly.
Clearly, Adobe doesn't share your opinion.
> The most interesting threat of files uploaded to root is via defacement.
> This solution does nothing against that threat.
I you can deface my server, then I've got big problems already (e.g.,
my Web site is totally hacked). Not addressing this issue creates a
security problem where none currently exists.
>> 1) Require host-meta to be served with a particular, novel Content-Type.
>
> Not feasible, because of limitations on developers that implement these
> server-to-server techniques.
That's an opinion. We'll see if you're forced to patch the spec when
you're confronted with a horde of Web servers that you've just made
vulnerable to attack.
>> 2) Add a section to Security Considerations that explains that
>> applications using host-meta should consider adding requirement (1).
>
> No. I would suggest adding a Security Considerations that say that host-meta
> SHOULD NOT be relied upon for ANY security-sensitive purposes _of_its_own_,
Then how are we to address use case (1)?
> and that applications that require levels of integrity against defacement
> attacks, etc., should implement real security techniques. Frankly, I think
> content-type does very little for security of such applications.
Your argument for why strict Content-Type handling is insecure is that
a more powerful attacker can win anyway. My argument is that we have
implementation experience that we need to defend against these
threats.
I did a little more digging, and it looks like Silverlight's
clientaccesspolicy.xml also requires strict Content-Type processing:
http://msdn.microsoft.com/en-us/library/cc645032(VS.95).aspx
That makes 3 out of 3 systems that use strict Content-Type processing.
All of the above systems target browsers and none have the usage requirements of the proposed spec.
Microsoft's solution to the limited hosting environment problem
appears to be quite clever, actually. I couldn't find documentation
(and haven't put in the effort to reverse engineer the behavior), but
it looks like they require a content type of applciation/xml, which
they get for free from limiting hosting providers by naming their file
with a ".xml" extension. This is clever, because it protects all the
sites I listed earlier because those sites would have XSS if they let
an attacker control an application/xml resource on their server.
Adam
-- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7)
|
|
Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)
On Wed, Feb 11, 2009 at 3:57 PM, Adam Barth <w3c@...> wrote:
On Wed, Feb 11, 2009 at 3:32 PM, Breno de Medeiros < breno@...> wrote:
> In that case, content-type is a mild defense. Can you give me an example
> where a web-site administrator will allow files to be hosted at '/'?
compatibility in a Flash security release.
> I can find some fairly interesting names to host at '/'
>
> E.g.: favicon.ico, .htaccess, robots.txt, ...
OMG, you changed my favicon! .htaccess only matters if Apache
interprets it (e.g., uploading an .htaccess file to Gmail doesn't do
anything interesting).
> Trying to secure such environments seems to me a waste of time, quite
> frankly.
Clearly, Adobe doesn't share your opinion.
> The most interesting threat of files uploaded to root is via defacement.
> This solution does nothing against that threat.
I you can deface my server, then I've got big problems already (e.g.,
my Web site is totally hacked). Not addressing this issue creates a
security problem where none currently exists.
The web site of your corporation being totally hacked and the identity system for users of your corporation server's being totally hacked are problems of a completely different order of magnitude.
The fact is that site-meta will be used for purposes that introduce attending threats even more significant than XSS (an example of which you still have to provide in this thread) and security measures needed to mitigate these threats are application specific.
>> 1) Require host-meta to be served with a particular, novel Content-Type.
>
> Not feasible, because of limitations on developers that implement these
> server-to-server techniques.
That's an opinion. We'll see if you're forced to patch the spec when
you're confronted with a horde of Web servers that you've just made
vulnerable to attack.
>> 2) Add a section to Security Considerations that explains that
>> applications using host-meta should consider adding requirement (1).
>
> No. I would suggest adding a Security Considerations that say that host-meta
> SHOULD NOT be relied upon for ANY security-sensitive purposes _of_its_own_,
Then how are we to address use case (1)?
> and that applications that require levels of integrity against defacement
> attacks, etc., should implement real security techniques. Frankly, I think
> content-type does very little for security of such applications.
Your argument for why strict Content-Type handling is insecure is that
a more powerful attacker can win anyway. My argument is that we have
implementation experience that we need to defend against these
threats.
I did a little more digging, and it looks like Silverlight's
clientaccesspolicy.xml also requires strict Content-Type processing:
http://msdn.microsoft.com/en-us/library/cc645032(VS.95).aspx
That makes 3 out of 3 systems that use strict Content-Type processing.
Microsoft's solution to the limited hosting environment problem
appears to be quite clever, actually. I couldn't find documentation
(and haven't put in the effort to reverse engineer the behavior), but
it looks like they require a content type of applciation/xml, which
they get for free from limiting hosting providers by naming their file
with a ".xml" extension. This is clever, because it protects all the
sites I listed earlier because those sites would have XSS if they let
an attacker control an application/xml resource on their server.
Adam
-- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7)
|
