RE: Need PDF of MS' input [Was Re: Seeking earlier feedback from MS]
I want to re-emphasize that XDR is targeting cross-domain access of public data only. One can already access those public data on the server anonymously. XDR allows this to be done from within the browser rather than through server side proxy or custom applications. The custom header is simply additional measure to allow server explicitly opt-in. CS-XHR, on the other hand, appears to be trying to handle cross-domain access of private data. I don't know if the private data is meant to be something similar to personal photo album or someone's private bank account information. I would assume they have different security requirements. I don't have a clear picture how banks can utilize CS-XHR to handle their private data. Trying to provide a general solution here is bound to have a lot of pitfalls. I know this may sound a bit vague and doesn't address the questions below. But this is a long conversion and I am not sure if we can sort out all without face to face discussions. So I wanted to get the meta points across and this may be of interest. Thanks! Zhenbin -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
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
