-----Original Message-----
From: Jonas Sicking [mailto:[EMAIL PROTECTED]
Sent: Monday, June 16, 2008 10:00 PM
To: Sunava Dutta
Cc: Arthur Barstow; Marc Silbey; public-webapps; Eric Lawrence; Chris
Wilson; David Ross; Mark Shlimovich (SWI); Doug Stamper; Zhenbin Xu;
Michael Champion
Subject: Re: Need PDF of MS' input [Was Re: Seeking earlier feedback
from MS]
Hi Sunava et Al,
Thanks for the feedback!
This is a great start for a discussion. I hope we can get to more
concrete discussions about the various issues that microsoft is seeing
and try to figure out ways to address them.
There is a lot of experience at microsoft on these issues, especially
as
first deployers of the XMLHttpRequest API, so I'm greatly looking
forward to using that experience to improve the Access-Control spec.
Hopefully we can get to those meaty parts in this discussion that is
following from your mail.
I'll start with a mini FAQ to avoid repeating myself below:
Why is the PEP in the client rather than the server?
In order to protect legacy servers some of the enforcement will have
to live in the client. We can't expect existing legacy servers to
all
of a sudden enforce something that they haven't before.
In fact, even XDR using client side PEP. It's the client that looks
for the XDomainRequest header and denies the webpage access to the
data if the header is not there.
In fact, Access-Control does allow full PEP on the server if it so
chooses by providing an "Origin" header.
Is Access-Control designed with "Security by design"
Yes. In many ways. For example Access-Control does not allow any
requests to be sent to the server that aren't already possible today,
unless the server explicitly asks to receive them.
Additionally Access-Control sets up a safe way to transfer private
data. This prevents sites from having to invent their own which
risks
them inventing something less safe.
Thirdly, Access-Control integrates well with the existing HTTP
architecture of the web by supporting REST apis and the
Content-Type header. This allows existing security infrastructure
to inspect and understand Access-Control requests properly.
What about DNS rebinding attacks.
Even with DNS rebinding attacks Access-Control is designed not to
allow any requests which are not possible already in todays web
platform as implemented in all major browsers.
Especially the last point is something that seems to have been
misunderstood at microsoft. It is not the case that DNS rebinding
attacks affect Access-Control any different than it affects the rest of
the web platform. Any server that wants to protect itself against DNS
rebinding attacks in the current web platform will automatically get
protected against Access-Control. And any site that does not protect
itself is already vulnerable to the exact same attacks with
Access-Control as it is on the current web platform. In fact,
Access-Control is less vulnerable than XMLHttpRequest on its own is. So
a server doesn't need to deploy anything extra to "defend" itself
against Access-Control.
Section 4: Secure Design Principles
Why Secure Design Principles Are Important__
*/"Secure by design/*/, in /software engineering
<http://en.wikipedia.org/wiki/Software_engineering>/, means that the
software has been designed from the ground up to be secure. Malicious
practices are assumed, and care is taken to minimize impact when a
security vulnerability is discovered. For instance, when dealing with
/user <http://en.wikipedia.org/wiki/User_%28computing%29>/ input,
when
the user has to type his or her name, and that name is then used
elsewhere in the /program
<http://en.wikipedia.org/wiki/Computer_program>/, care must be taken
that when a user enters a blank name, the program does not break." -
/Secure by Design, Wikipedia
<http://en.wikipedia.org/wiki/Secure_by_design>
Secure design principles are key to ensuring that users, whether the
end-user or service provider, are protected. The increasingly hostile
Web and ever more clever attackers lead to the proliferation of new
vectors like XSS and CSRF. In the Web of today, it is critical that
solutions be secure-by-design /prior/ to release. This does not
guarantee that there will be no exploits; however it does ensure that
the bug trail is significantly lower and goes a long way toward
protecting the user. For more details on this, please read our MSDN
article on The Trustworthy Computing Security Development Life Cycle
<http://msdn.microsoft.com/en-us/library/ms995349.aspx>.
This sounds great. We've been using these types of principals when
designing Access-Control too.
Background of Client Side Cross-Domain Proposals
Cross-site XMLHttpRequest is essentially a combination of a cross-
domain
access mechanism, Access Control
<http://dev.w3.org/2006/waf/access-control/> (AC), and an object to
enable this mechanism, in this case, a versioned XMLHttpRequest
object
called XMLHttpRequest Level 2
<http://dev.w3.org/2006/webapi/XMLHttpRequest-2/> (XHR). This
cross-domain implementation will be referred to as CS-XHR.
*NOTE: This paper is based on the AC and XHR level 2 draft on
3/June/08.*
This is not entirely true. There is nothing that prevents Access-
Control
from being applied on XMLHttpRequest Level 1. Just as Access-Control
can
be applied to XInclude, XQuery, XSLT, XPath, <video>, CSS fonts, SVG,
XBL etc.
XDomainRequest (XDR) is the new object that we designed for cross
domain
using a "clean room" approach, one where we start with strict
security
principles and a "clean slate" and add functionality only if it meets
those principles.
We've used the same approach when designing Access-Control as well.
/"To me, it boils down to three issues: security, simplicity, and
architecture. I believe security concerns trump all others, and my
analysis is that Microsoft's security team made the right calls with
the XDR proposal, taking the conservative approach where no headers,
cookies or other credentials are transmitted to other domains, and
the
policy enforcement point (PEP) is assumed to be on the server. This
aligns with the de facto security model for today's Web where a user
establishes trust with the single domain, where the user and that
domain share secret information only between themselves, such as the
information stored in cookies. At OpenAjax Alliance, we have a
Security Task Force which contains some industry experts on web
security issues and the strong consensus (different than unanimity)
was a preference for XDR, mainly for security reasons. On the
simplicity side, XDR is appropriately simple (roughly as simple as
JSON Request), whereas Access Control has incrementally added
complexity (syntax rules for allowing/denying domains, two-step dance
for POST requests, detailed lists of headers that are transmitted) to
the point that it is now a small beast. On the architecture side,
Access Control is just plain wrong, with the PEP on the client
instead
of the server, which requires data to be sent along the pipe to the
client, where the client is trusted to discard the data if the user
isn't allowed to see the data; it is just plain architecturally wrong
to transmit data that is not meant to be seen. Regarding the
criticism
of XDR with more complex workflows where two sites need to work in
coordination with each other, possibly including the use of cookies
from the two sites, there are lots of ways to skin that cat and for
security reasons (such as CSRF concerns) should not be done within
the
context of the cross-domain request mechanism. For example, HTML5
allows postMessage(), so you can set up a web page with two IFRAMES,
each talking to a different server, and have them do client-side
communications via postMessage(); also, there are various server-side
alternatives to address these scenarios." - Jon Ferraiolo, Web
Architect, IBM & Open AJAX Alliance/
This is addressed by the FAQ above.
Section 5: Security Concerns with Web API WG Proposal on Cross-
Domain
XMLHttpRequest
In this section, I'll demonstrate a few of these that could be
critical
blockers to implementation by browsers and security minded developers.
Mozilla echoed our sentiments here by removing CS-XHR support from
the
Beta <https://bugzilla.mozilla.org/show_bug.cgi?id=424923#c14> until
the
specification addressed further security concerns.
This is wholly false. The reasons we dropped support for Access-Control
in FF3 was very different from the concerns that microsoft has
expressed. In fact IE8 is vulnerable to the concerns that we had. The
debate we have had (and are still having) is whether these concerns can
be addressed without sacrificing security too much elsewhere.
Extending XHR for Cross-Domain Access
*XHR has a history of bugs and extending it for cross-domain access
does
not build confidence.*
Recommendation
Rather than working backwards to secure an object with a poor
security
record, it makes more sense to start from a basic architecture and
adding functionality incrementally, securely, and only as necessary.
Discussion
XHR has a poor security record across all the major browsers ranging
from header spoofing attacks to re-direction attacks. Header spoofing
attacks now are even more scary given that CS-XHR uses headers to
determine which sites can access resources as well as what actions
they
can do (HTTP Verbs and headers).
So I want to try to understand this comment. Is the concern here over
the specific API that is used, or about what features that API allows?
It would be trivial to restrict XHR when used cross site such that the
security model is exactly that of XDR. By disallowing headers to be set
or retrieved, and by restricting the method to only "GET" and "POST"
cross-site XHR would have exactly the same feature set as XDR.
The discussion about which API to use is orthogonal to the discussion
about what features to allow for cross-site requests.
So is the concern here somehow related to security, or is it related to
concern about confusion of reusing the same object for both same-site
requests and cross-site requests (which might have different security
restrictions applied to it).
I'm not saying that API discussions aren't important. They most
certainly are. And it is an interesting discussion of if having the
same
API for same-site and cross-site (whatever that API is) is a good idea
or not. So I'm just trying to understand what the exact concern is here.
XHR Behaves Differently in Cross-Domain Mode and Same-Site Mode.
*XHR behaves differently in cross-domain mode and same-site mode
leading
to unnecessary confusion for the web developer by being the same API
only in name.*
Recommendation
XHR is a widely used object. Consequently, it is difficult to reverse
engineer without breaking existing deployments, adding complexity,
and
confusing developers. In the process this may introduce new holes
that
require further patching. This different cross domain behavior means
that it has all the disadvantages of XMLHttpRequest like its security
flaws without any clear benefit. Having a new object here without
these
redundant cross domain properties like getAllResponseHeaders will
mitigate a number of these worries.
Again, I'm confused about what the exact concern is here.
The only way I could see that reusing the same API for cross-site
requests would break existing deployments would be if such deployments
rely on that calls to XHR.open throw if the requested URI is a
cross-site one, now it will result in an error event being fired
instead.
Is that the concern?
Regarding complexity, that sounds like complexity for implementors?
Same
thing with "may introduce new holes that require further patching",
that
sounds like a concern about implementation bugs? Is that correct?
Again, all of these things are important, i'm just trying to understand
what the exact concern is here. Complexity for implementors is
definitely important in order to reduce bugs in the implementation.
Access-Control Rules that Allow Wildcards
*Requiring implementers to maintain access control rules that allow
wildcards can lead to deployment errors.*
Isn't the XDomainRequest:1 the same thing as a wildcard? Doesn't that
mean that anyone can load the resource on that URI?
Recommendation
* For access where AC is important, other architectures like
Server Side Proxying
<http://developer.yahoo.com/javascript/howto-proxy.html> for service
providers who are interested in maintaining access control rules and
the
HTML 5.0's WG's Cross Document Messaging are recommended.
* If you are going to use CS-XHR, we recommend avoiding
wildcards, auditing access control rules regularly, and avoiding
hosting
sensitive data from domains that expose data to CS-XHR.
The first seem very drastic, and isn't really a viable replacement in
many cases. And the second doesn't seem like a recommendation for the
spec, but rather for someone deploying the spec?
Wouldn't it be better to recommend that the spec disallows wildcarding
together with transferring cookies? That is the kind of input I was
hoping for from microsoft, and something that sounds like we should
take
a serious look at.
Future Work
Permitting the end user to decide whether the web application they're
using should be able to make a cross-domain request may be worth
investigating. There are significant user experience challenges
because
the user may not understand the implications of such access.
Exactly, this hasn't worked very well in the past, which is why we've
chosen to avoid that path.
Discussion
The service provider who sets the access permissions and returns the
requested content is another key player here. Providing a simple
scalable solution here will ensure that mistakes in permissions don't
unravel as services are deployed and maintained. For example, Flash
has
an access control mechanism similar to the one in CS-XHR and this has
been vulnerable to wildcarding attacks. Wildcarding attacks occur
when
access controls are set in error (a distinct possibility as the
number
of rules to filter cross domain requestors increases and becomes
complex) and allow for unintended access. This is especially scary
given
that AC can send cookies and credentials in requests. This also
violates
the AC drafts requirement
<http://www.w3.org/TR/access-control/#requirements> that it /"should
reduce the risk of inadvertently allowing access when it is not
intended. That is, it should be clear to the content provider when
access is granted and when it is not."/**
I'm not sure I agree here. Saying "Access-Control: allow <*>" makes it
pretty clear that everyone can read this resource, so we seem to pass
the spec requirement fine.
Community Comments
...
/Flickr was vulnerable to this exploit, because it hosted an "allow
all"
policy file in its main domains: flickr.com and /www.flickr.com
<http://www.flickr.com>/. We notified Flickr and they fixed the hole
promptly by moving their APIs to a //separate domain/
<http://api.flickr.com/crossdomain.xml>/ and removing the
//crossdomain.xml file on their main domain/
<http://www.flickr.com/crossdomain.xml>/ (now 404). - Julien
Couvreur,/
http://blog.monstuff.com/archives/000302.html//
(just commenting on the flickr one here as that's the one I know of.)
This wasn't technically a problem due to wildcarding. The solution they
use still uses wildcards. This was a problem of them applying the
policy
too broadly across their URI space.
Access-Control Rules Visible on the Client
*Allowing Access Control Rules to be visible on the client leads to
information disclosure.*
Only if the server so desires. The server has all information needed to
make this a pure server-side policy, so this doesn't appear to be an
issue.
Recommendation
* XDR ensures that servers regulate access to individual
requests and that rules are not available to the client.**
Actually, the XDR doesn't allow neither server or client side rules,
it's purely all or nothing. XDR currently relies on the 'referer'
header
which due to firewall filtering is unreliable to the point that it's
not
useful for security checks.
Discussion
The access control rules need not be exposed to the world as this
information could potentially be sensitive. For example, your Bank
may
maintain a list of allowed partners based on your other frequently
accessed bank accounts. Making these rules available on the client
can
lead to profiling attacks if this data is intercepted. While AC and
XDR
allow servers to use the Access-Control-Origin header to make
access-control decisions preventing them from being viewed on the
client, the reality is that in practice web developers are likely to
opt
in for what's easiest and will not leverage this given the
alternative
available for AC.
You think that sites will knowingly broadcast their rules to the world,
while being concerned that the world will read it? That seems like a
far
stretch to me.
Access-Control Rules in Headers
*Sending Access Control Rules in Headers can lead to inadvertent
access.*
Recommendation
* Enable users to restrict site-to-site access. This has its
own
set of challenges that need to be investigated like UI.
* If you are using CS-XHR, we recommend not using it to send
sensitive data so that if Access Control (AC) rules are compromised,
the
impact of the data disclosed is minimal. When AC rules are audited
and
maintained, if the rules are spoofed (a possibility because XHR has
been
subject to header spoofing attacks and AC rules are maintained in
headers), the data may be compromised.
Discussion
* The Web API Cross Site XMLHttpRequest plan allows access
control rules to be in headers. It is especially dangerous given that
XMLHttpRequest has had header spoofing attacks in the past on
multiple
browsers. This could cause cross domain access to legacy sites not
opted
in to cross domain or change access control rules for existing sites
using CS-XHR.
* To make things even more confusing, an XML file and headers
can be used to control access control in cross site XMLHttpRequest.
Community Comments
/"(Description Provided by CVE) : Firefox before 1.0.7 and Mozilla
Suite
before 1.7.12 allows remote attackers to modify HTTP headers of XML
HTTP
requests via XMLHttpRequest, and possibly use the client to exploit
vulnerabilities in servers or proxies, including HTTP request
smuggling
and HTTP request splitting." /http://osvdb.org/osvdb/show/19645//
/"//That the XDR proposal enables cross-domain requests with minimal
complexity and in a way which is unlikely to cause IT administrators to
disable the feature, is, in my opinion, reason enough to be
enthusiastic. The XDR proposal seems like something that could be a
stable platform on which to start building new kinds of applications./
I'm not following this section at all. The first section talks about
allowing inadvertent access. I first guess that that was inadvertent
access to content. However the Discussion section talks about reading
headers, so is that the concern?
Then the first Community comment talks about inserting custom request
headers, which seems to be something different? Then the second comment
talks about that XDR is good which seems totally unrelated to security
comments about the Access-Control spec.
Can you rephrase the concern here, i'm just not understanding it.
Maintaining Access Control Based on a Header
*Maintaining Access Control based on a header that instructs the
client
to serve the response to a particular domain/path instead of an
individual request leads to the potential for inadvertent access.*
Isn't XDR also header based? Or is this in general a concern about
header based solutions, Access-Control and XDR alike?
Recommendation
* Ensure proper and complete URL canonicalization if
Access-Control is ever granted by path.
Hmm.. this seems like a switch of topic. But yes, URL canonicalization
(or some people has preferred to call this the process of mapping a URI
to a file path) is a problem.
* Enforcing access control on a per-request basis. Do not
permit
policy from one URL to regulate access to another URL.
Hmm.. again a topic switch. Can you please expand on this? Seems
unrelated to the header concern in the original title and the URL
canonicalization concern in the previous comment.
Discussion
This can lead to vulnerabilities that occur when the path of the
request
can be modified by an attacker using special characters, a flaw that
we
pointed out to Mozilla on a teleconference on cross origin requests.
A
solution here is currently being discussed by the Web API WG (See
right).
I assume here that "This" in the first sentence refers to the "can be
granted by path" issue?
If so, yes. Based on experience from Adobes Crossdomain.xml deployment
this seems to cover existing attacks.
Note the AC draft can be demonstrated to need the access control
implementers to take additional security measures
<http://lists.w3.org/Archives/Public/public-webapi/2008May/0435.html>
although this is against the draft's own requirement
<http://www.w3.org/TR/access-control/#requirements> of /"Must not
require content authors or site maintainers to implement new or
additional security protections to preserve their existing level of
security protection." /and/ /"/Must not introduce attack vectors to
servers that are only protected only by a firewall." /
How so? Access-Control is secure by design by requiring servers to opt
in. So if a server does nothing different from what it does today
Access-Control will always bail early and apply the existing Same-
Origin
policy that UAs do today. That applies always, even for content that is
currently only protected by a firewall.
That seems to cover both the requirements that you list above?
Sending Cookies and Credentials Cross Domain
*The Access Control sends cookies and credentials cross domain in a
way
that increases the possibilities of information disclosure and
unauthorized actions on the user's behalf.*
It is not the sending of the cookies that is the concern here, it's the
sending of the users private data as a reply to the request that is the
concern, no?
Web developers want to transfer user-private data. They are going to do
so whether UAs provide official APIs to do so or not.
So I do think that we need to provide a safe solution for transmitting
private data, simply saying "never send cookies" is not a viable
solution unless an alternative is presented.
So far the solutions that sites seem to use is to ask the user for the
username/password for the third party site, and then employ a server to
server connection. This is a really bad design security wise since it
teaches users to give out their credentials. This is especially bad if
users use the same username/password on multiple sites, something that
is very common.
Recommendation
* Preventing cookies and other credentials from being sent
cross
domain will help ensure that private data is not inadvertently leaked
across domains.
* The HTML 5.0 feature called Cross Document Messaging,
combined
with the same-origin XMLHttpRequest, enables regulated cross-domain
access on the client without requiring potentially dangerous
functionality (e.g., cross-domain submission of headers).
This is definitely a decent alternative. The concern is that sites will
want to communicate directly with other servers rather than proxy
everything through javascript and iframes. This can be demonstrated by
the number of such solutions that are deployed today, despite the fact
that iframe communication (albeit cumbersome such) has been available
for some time.
Additionally there is a risk that sites will stick to current <script
src=> solutions which has a lot of security concerns apart from the
ones
discussed here.
Future Work
Future designs may include:
* The user could enter credentials while making a proper
trust
decision about whom ultimately gets the credentials and who this
grants
access to. Any user trust decision needs to be properly understood as
there is the possibility that poor UI design or spoofing may lead to
the
user making the wrong decision. If done correctly this does provide
the
benefit of having the user's explicit assent and a number of existing
software dialog warnings are currently based on this mechanism.
* The browser could send an XDomainRequestCookie header
<http://lists.w3.org/Archives/Public/public-webapi/2008May/0284.html>.
This would allow cookies to be sent in a header with a new name, so
that
existing sites would not inadvertently get a cookie and assume that
this
is cross domain. Sites could then ignore this header and not take
action
based on the use's session identifier. Aware servers on the other
hand
could read the new header and provide useful, user-specific services
based on its contents. This of course requires the server frameworks
to
need updates to look for such cookies and parse them properly. In
addition, any intermediary proxy that behaves differently based on
cookies would break, but these are issues that are definitely worth a
further look.
This doesn't scale very well though. You'd also need to introduce a
XDomainRequestAuthorization header and a XDomainRequestFutureAuth
header
and so on any time a new way of transmitting authorization data is
invented.
This is extra bad considering that you are violating the HTTP spec, so
any existing security infrastructure that deals with auth and cookie
headers will not recognize the new headers. So you are in fact reducing
certain aspects of security by going against the HTTP spec.
Discussion
The way AC does these increases the potential for Cross-Site Request
Forgeries as requests will be automatically authenticated and may
contain headers otherwise impossible to send via script. For example,
a
user may be authenticated via CS-XHR to his or her bank from their
online tax preparation site. If they subsequently visit an evil site,
it
could craft CS-XHR requests to the Bank Site and send a token to
authorize actions. Even though CS-XHR requires an OPT-in model from
the
server (this is good), if there is an XSS vuln, AC header spoof, or
wildcard accidently set, this opens up another channel for unwanted
authenticated actions.
In addition, a number of sites may assume and rely on cookies being
sent
with cross-site requests and this could become a third party problem
if
cookies are sent by default. As the Web API WG members note, a large
number of sites will not understand cookie authorization and will
wind
up susceptible to CSRF.
(I assume there is a "not" missing in the first sentence in the above
paragraph?)
I don't understand the CSRF risks at all. CSRF is a problem with sites
thinking they are getting same-site requests, but forget that HTML
allows for cross site <form>s. CSRF forces sites to explicitly have to
opt out of getting certain requests.
Access-Control on the other hand is opt-in. I would think that any one
that opts in to Access-Control realizes that they are going to get
cross-site requests, that is the only reason you would opt in, that you
want cross-site requests.
As far as XSS concerns go, that would seem to almost by design be a
problem with any solution deployed. For example postMessage has similar
XSS concerns. If a bank site has allowed a tax preparation site to
perform postMessage, then if the tax preparation site gets XSS attacked,
the attacker could also attack the bank site.
The wildcard problem you raised above, so lets discuss that there. Or
is
this one different in some way?
The header spoof I think you raised above too, but as you could see
there I didn't really follow you there :) But please do elaborate there
if it's the same issue.
Privacy: Including the cookies lets sites more easily track users
across
domains.
Access-Control follows the UAs privacy settings. So there should be no
more concerns here than with cross-site <img>.
Community Comments
* /"sending cookies, by-default, with 'non-safe' requests. /
o /many of the risks that are associated with allowing cross-site
XHR,
e.g. Cross-Site Request Forgery, can be mitigated by not sending
cookies
with these requests. /
* /Jonas concerned that sites will assume and come to rely
upon
browsers not sending cookies with cross-site requests, which could
lead
to problems if we ever decide to start sending 3rd party cookies by
default/
This is a concern if we *don't* send cookies in the initial
implementation.
* /We should not send cookies and auth headers."
/http://wiki.mozilla.org/User:Sicking/Cross_Site_XHR_Review#Discussion_
.26_Implications//
For the most part these concerns would be addressed by my proposals to
the mailing list. The remaining part is harder to solve and IE8 suffers
from this problem too.
# <http://krijnhoetmer.nl/irc-logs/whatwg/20080221#l-85>/ [00:04]
<Hixie> the reasons to include cookies are simple -- if we don't have
them, we (Google) basically can't use xhr./
/. . ./
# <http://krijnhoetmer.nl/irc-logs/whatwg/20080221#l-85>/ [00:19]
<sicking> so the thing is that CSRF today is kind of a catastrophe.
There are lots and lots and lots of sites that are susceptible to it.
If
we had a world where cookies weren't sent for third-party requests
we'd
be in a much safer web/
Yup. Fortunately Access-Control doesn't suffer from this problem since
it requires Opt-in. So it's not susceptible to CSRF in the same way.
Sending Arbitrary Headers Cross Domain
*Sending arbitrary headers cross domain breaks a lot of assumptions
that
sites today may make, opening them up for exploits. Creating complex
rules to limit the headers sent cross domain makes the spec even more
difficult to deploy reliably.*
Headers are only sent if the server opts in under the current spec. So
I
don't understand how it could break any assumptions that sites make
today.
Recommendation
Do not allow arbitrary headers to be sent cross domain. Avoid any
design
where the list of blocked and allowed headers is likely to be
confusing
and under constant revision as new attacks and interactions arise.
If you are implementing CS-XHR, we advise you take extreme caution in
what headers you allow in the OPTIONS request, in addition to testing
the allow list when opening up your service cross domain. Furthermore,
we recommend taking extra caution by ensuring that the headers do not
specific actions that are dangerous if the request is compromised by
a
DNS-Rebinding attack.
*No* headers are allowed to be set by the website in the OPTIONS
request. Only once a site has explicitly opted in can custom headers be
set.
For GET requests there is a very short whitelist (currently only has
two
entries) of headers that can be set without the site opting in.
Discussion
In general, browsers today can not send cross-domain GET/HEAD
requests
with arbitrary headers. With AC, this now becomes possible, breaking
many previous assumptions. Microsoft is aware of sites dependent on
the
expectation that arbitrary headers cannot be sent cross domain and
this
is in accordance with HTML 4.0. This is not a good security practice
by
any means but enabling this functionality in a way that compromises
our
users is not an option. As an example, UPnP allows GET requests with
a
SOAP Action header to perform actions on a device. If the SOAP Action
header is not actively blocked by a cross-site XMLHTTPRequest client,
attackers will be able to perform this attack against routers and
other
UPnP devices. Contrast this with XDR, where arbitrary headers cannot
be
supplied, by default.
It seems like you are misunderstanding the spec. Only once a site has
opted in can arbitrary headers be set. So any currently existing sites,
such as UPnP devices, is unaffected.
An option here is to create a block list of bad headers. However,
this
quickly adds to the complexity of this already complex proposal and
to
make things worse will need continual updates to the spec once
implementations have shipped and more blacklisted headers are
discovered. This will presumably prevent the spec from stabilizing
and
browsers will have to update patches to secure their implementations.
Block lists are unacceptable we all agree. The block list currently in
the spec really should be moved to the XMLHttpRequest Level 1 spec as
that is where the issue lies, not with the Access-Control spec.
This is a lower concern but having an allow list would be another
option. That said, since web sites today do rely on not allowing
arbitrary headers across domain it is difficult to prove that the
headers on the allow list are not being used by sites for Same Site
Origin requests.
Agreed 100%. The spec follows this design.
To make things even more complicated, the AC spec specifies a
complicated mix of allow lists, black lists, and other headers. For
example, if a header is not in an allow list, it needs a pre-flight
check. (The spec already requires pre-flight checks for non-GET HTTP
verbs). This of course is another addition to the multi-part request
that AC allows and if the server agrees there's still a blacklist to
filter out headers that should not be allowed. The convoluted
approach
continues with XMLHttpRequest level 2 having its own set of
blacklists
that filter headers out prior to cross domain. Moving on, this black
list in XMLHttpRequest has a SHOULD not and MUST not specification
for
blocked headers, leaving the door open for different behaviors across
browsers.
Even when taking DNS rebindings attack into account (at least the way
you have defined them at the top of this email) Access-Control doesn't
allow any requests other than the ones already possible, so it's secure
by design.
The blacklist of headers in the Access-Control spec really is just the
same one as the XHR spec and really should just be covered there.
Header spoofing in XMLHttpRequest is a common vulnerability from the
past. Sending headers cross domain may allow for access control rules
to
be changed, enabling legacy services not opting in to Cross Site
XMLHttpRequest to be vulnerable.
I do agree there is some concern here. However do note that this only
applies to servers that opt in. But I do personally have some concern
for the servers that do opt in.
Allowing Arbitrary HTTP Verbs
For the sake of avoiding confusion, http "verbs" are often referred to
as http "methods", so you might see me and others use that term.
*Allowing arbitrary HTTP verbs to be sent cross domain may allow
unauthorized actions on the server. Creating complex rules to secure
this opens up the possibility for other types of attacks.*
It would be great with more detail here. I'm especially interested to
hear feedback from microsoft here since I'm sure you have
implementation
experience since deploying XMLHttpRequest. Would be great to hear what
types of problems you ran into at that time.
Recommendation
* Do not allow non-GET and POST verbs. This is in line with
capabilities of HTML forms today and is specified by the HTML 4.**
* If verbs are sent cross domain, pin the OPTIONS request for
non-GET verbs to the IP address of subsequent requests. This will be
a
first step toward mitigating DNS Rebinding and TOCTOU attacks.
As mentioned before, even with DNS Rebinding attacks Access-Control is
designed in such a way that it doesn't allow any types of requests to
be
sent that can't already be sent by the current web platform.
However the pinning is an interesting idea here. One we should discuss
further.
* Using XMLHttpRequest to do this is inherently more
complicated
as XHR has its own rules for blocking verbs.
You mean that this is more complicated implementation wise? As stated
before, implementation complexity is certainly important to take into
consideration, I'm just trying to understand your concern.
Looking forward to continued discussion on these topics. There is
definitely some interesting stuff in here so I'm glad we got this
feedback!
Best Regards,
Jonas Sicking
