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

Received on Tuesday, 17 June 2008 05:03:50 UTC