Microsoft's feedback on XHR2

For those of you who want to read it more conveniently, here's Microsoft's 
feedback in plain text form, with the background material redacted (since 
everyone here is familiar with the issues) and the "community quotes" 
removed (since all those points have already been addressed in earlier 
e-mails on the relevant mailing lists).

I haven't tried to remove the redundancy; there's a lot of text in there 
that's repetitive and some of the points are made many times. I may make 
another pass that just summaries the actual points being made for more 
convenient consideration by the working group and the editor.

=======================================================================

CS-XHR does not:

- Avoid privilege escalation attacks by ensuring that the user's
authority cannot be misused.

- Protect existing sites that reply on the Same Origin Policy for
cross-domain defense.

- Make it secure by default (Or provide an alternative for developers
who are not security gurus) and deployment by keeping it simple and
easy to grasp.


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).

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.



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.

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.

- The proposal modifies the expected behavior of the SetRequestHeader
method, and the availability of the user and password parameters on
the Open() method.

- The proposal requires that the HEADERS_RECEIVED state must either
never be reached for a cross-origin request, or it must be delayed
until any access control list in the entity is evaluated. Hence,
eventing behaves differently when a request is cross-origin.

The proposal requires that getAllResponseHeaders() and
getResponseHeader() should behave differently by not inappropriately
exposing any trusted data of the response such as HTTP header data.


Requiring implementers to maintain access control rules that allow
wildcards can lead to deployment errors.

- For access where AC is important, other architectures like Server
Side Proxying for service providers who are interested in maintaining
access control rules and the HTML 5.0 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.

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.

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 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.


Allowing Access Control Rules to be visible on the client leads to
information disclosure.

- Doing the evaluation server side will raise the bar on profiling the
sites allow list.

- Server side proxying allows for sites to maintain a list of hidden
partners and allowed sites.

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. While this has not been seen to be a
prominent concern in existing deployments, this has been raised as a
potential door for exploits by our security experts as there could be
scenarios where the cross-domain file could be of interest to
attackers as adoption increases.


Sending Access Control Rules in Headers can lead to inadvertent
access.

- 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.

- 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.


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.

- Ensure proper and complete URL canonicalization if Access-Control is
ever granted by path.

- Enforcing access control on a per-request basis. Do not permit
policy from one URL to regulate access to another URL.

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).  Note the AC draft can be demonstrated to need
the access control implementers to take additional security measures
although this is against the draft's own requirement 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."


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.

- 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).

- For down-level clients, server side proxying architectures will
likely continue to be used by organizations handling sensitive data.

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. 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.

- The web page for a hosted resource could include an authorization
token that the user can drag and drop on a third-party Web page. This
token authorizes a single request of a predetermined type. Often this
user action will be required regardless of any security policy, since
the third-party Web page will need to be told what resource it should
send its request to. Both the authorization token and the resource
identifier can be specified by the user in the same user interface
gesture.

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.

Privacy: Including the cookies lets sites more easily track users
across domains.


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.

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.

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.

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.

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.

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.

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.


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.

- 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.

- Using XMLHttpRequest to do this is inherently more complicated as
XHR has its own rules for blocking verbs.

- Server Side Proxying is a safer way to doing these scenarios.

Sites today do not expect HTTP verbs other than GET and POST (what's
allowed in HTML 4.01 forms today) to be sent cross domain. AC tries to
solve this by requiring that any non GET verbs require one OPTIONS
request from the browser and one response from the server to unlock
cross domain sending of ALL verbs to the domain. This decision may
also be cached on the client for future requests.

There are also redirection cases that require new checks.

This is further complicated by XMLHttpRequest rules on what HTTP verbs
are blocked by default like TRACE and TRACK.

This is especially scary given that user-sensitive information can be
transmitted in CS-XHR using cookies and credentials and any compromise
here will lead to actions (specified by the VERBS) on behalf of the
user (authority is specified by the cookies and credentials).

This multistage handshake in the case of non-GET requests opens the
possibility for attacks like DNS Rebinding and Time of Check, Time of
Use attacks where a change occurs in between consecutive attacks. In
the case of non-GET requests, DNS Rebinding mitigation depends on the
server actively validating the HOST header. For CSRF attack scenarios
using non-GET verbs, victim devices across the network are likely not
going to do this as the victim server is not intending to be part of a
Cross-Site XMLHTTPRequest transaction. This violates the Web API AC
drafts own specification of "Must not require content authors or site
maintainers to implement new or additional security protections to
preserve their existing level of security protection."

========================================================================

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 16 June 2008 02:19:50 UTC