RE: [NOT] Microsoft's feedback on XHR2

No.

I understand why you might like to edit our feedback, Ian, but your edit does not, in fact, represent Microsoft's feedback on cross-domain.  What you call "redacting background material" I call "removing principles such that remaining points might seem unprincipled."  The members of the WG (and the public) are welcome to draw their own conclusions from our statements; I am NOT willing to have you be the one who draws their conclusions for them.

As every email software package I'm aware of can handle HTML and text, and most of them can do an automatic translation between the two of them, I'll ask you again to not editorialize on Microsoft's motives or actions for the group.  Particularly when you are redacting the very principles at issue.

-Chris

> -----Original Message-----
> From: Ian Hickson [mailto:ian@hixie.ch]
> Sent: Sunday, June 15, 2008 7:19 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: 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 18:01:54 UTC