W3C home > Mailing lists > Public > public-appformats@w3.org > March 2008

Re: IE Team's Proposal for Cross Site Requests

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 18 Mar 2008 00:16:10 -0700
Cc: "Web API WG (public)" <public-webapi@w3.org>, "public-appformats@w3.org" <public-appformats@w3.org>, Eric Lawrence <ericlaw@exchange.microsoft.com>, Chris Wilson <Chris.Wilson@microsoft.com>, Zhenbin Xu <zhenbinx@windows.microsoft.com>, Gideon Cohn <gidco@windows.microsoft.com>, Sharath Udupa <Sharath.Udupa@microsoft.com>, Doug Stamper <dstamper@exchange.microsoft.com>, Marc Silbey <marcsil@windows.microsoft.com>, David Ross <dross@windows.microsoft.com>
Message-Id: <9C936B67-9A1D-444D-8D81-6F283BA5DDDC@apple.com>
To: Sunava Dutta <sunavad@windows.microsoft.com>

On Mar 17, 2008, at 7:52 PM, Sunava Dutta wrote:

> Maciej Stachowiak [mjs@apple.com] noted:
> <<I think encouraging more content sniffing of text/plain on the  
> server side is likely to increase, not reduce attack surface.>>
> If a service is defined as accepting one format, it need only accept  
> that format, and can reject anything else.  Sniffing is not  
> recommended or desirable.

Such a service should reject an incorrect MIME type, which text/plain  
would be for XML.

> Remember, even if you allow the Content-Type to be specified by the  
> caller, the server has NO guarantee that the Content-Type specified  
> is an accurate description of the POST body content.  To remain  
> secure, servers MUST be robust in the face of malformed input.

However, sniffing in text/plain is a whole different ball of wax.

> Maciej Stachowiak [mjs@apple.com] noted:
> <<So far I have not heard any *specific* security risks of the  
> Access- Control model as compared to XDR, at least none that have  
> held up to closer scrutiny. Is Microsoft aware of any specific such  
> risks, as opposed to general concerns?>>
> The Security Worries section here: http://wiki.mozilla.org/Cross_Site_XMLHttpRequest 
>  and the Security section here:http://www.w3.org/TR/access-control/#security 
>   describe some of the concerns related to the Access-Control  
> model.  We believe that the XDR model effectively mitigates the  
> concerns described.

Do you have any specifics? Which of those items, in particular, do you  
think represent security vulnerabilities in XHR2+AC? Which are  
addressed by XDR? I can do this analysis myself if necessary, but if  
Microsoft is making the claim that XDR is more secure and that you  
believe XHR2+AC has security vulnerabilities, I think you should  
provide specific evidence to back up these claims.

(Note that these are both lists of issues that are believed to be  
adequately addressed, so it is not immediately obvious which items you  
believe are vulnerabilities.)

> Maciej Stachowiak [mjs@apple.com] noted:
> <<Certainly simplicity of client-side authoring, server-side  
> authoring and implementation are worth discussing as well, but I  
> think the approaches are similar enough that simplicity in itself is  
> not a major security issue.>>
> While simplicity alone obviously is no guarantee of security, design  
> complexity almost always leads to implementation bugs.   
> Implementation bugs in access control mechanisms lead to security  
> bugs.

That is true. But based on my experience writing the original  
implementation of XMLHttpRequest for WebKit, and my review of the  
spec, I do not think XHR2+AC rises to the level of complexity that is  
highly likely to lead to implementation bugs.


Received on Tuesday, 18 March 2008 07:16:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:56:22 UTC