(Post courtesy Giuseppe Branca)
The Windows Azure platform offers you an easy way to publish applications: just press the publish button in management user interface. I want to go a little in depth on in what can be a possible security concern if you publish applications using *.cloudapp.net a production environment.
After having deployed your Windows Azure solution package in the cloud you can start your application. Starting your application will automatically create a first type of URI related to the application; this URI follows the pattern http://*.cloudapp.net. In this phase the wildcard * stands for a group of letters and digits randomly generated by Windows Azure platform, and you are in a phase of lifecycle of Windows Azure application called staging. The Staging phase is a phase intended to be used only for testing; in this phase your application is completely published in Internet but is reachable only by users who know the URI: i.e. only by you, people you’re sharing the URL with, and/or people who can access your Windows Azure Account for managing purpose.
The second phase is just putting the solution in production, as before it is very easy: just pressing another button in Windows Azure management interface. After that your application will be published with a domain http://XXXX.cloudapp.net where XXXX is the name you chose when you uploaded your Windows Azure package.
This means mainly two things:
1. A very easy way to publish application, if you are not bothered that users will access your application through the cloaudapp.net domain.
2. There will be a lot of Windows Azure applications running within the same *.cloudapp.net domain.
Indirectly point 1 and point 2 bring two downsides you must be aware of, so now you will learn that for your application in production it’s better to avoid *.cloudapp.net domain and that it’s better to associate your own custom domain.
First security concern is phishing. Phishing is a technique whereby an attacker sets up a frontend copy of a website and using social engineering techniques brings users of attacked web site to the phishing site. The user is asked to enter sensitive data (e.g. username and password) into the phishing site, and often users will provide the data because based on the look and feel and URL of the phishing website they are tricked into thinking that they are interacting with the original website they trust.
A simple example will let you understand this scenario: you did a good job and you finally published your Windows Azure application you called myroomcolor using *.cloudapp.net domain. So it will be published as http://myroomcolor.cloudapp.net. An attacker decided to attack your site. So the attacker creates a website with the same layout as your site and publishes it on Windows Azure. The Attacker publishes the application with the URL http://myromcolor.cloudapp.net and then he uses techniques (as link in emails, etc.) to bring visitors to his site. If a user is not very careful it will not notice any difference with your own website, and may insert sensitive data (such as username and password) in phishing site. This is due to the fact that users often base their trust in being in the right place looking at site layout and also to URL of the pages. Layout can easily be cloned, and as you can see an attacker can choose a very similar URL to the attacked one with some typo, or very little differences that can mislead users.
The second security concern in hosting an application in the production environment using a domain *.cloudapp.net is not related with Windows Azure Platform but with the design of HTTP protocol, which makes this scenario inconvenient.
Consider following scenario: application A and application B are on *.cloudapp.net domain, that A application is our application and B application is application used by the attacker. Application A binds cookie domain to *.cloudapp.net instead of A.cloudapp.net.
These two scenarios can be easily generalized creating a wider set of attack scenario. As you can see the fact that cookies are set by different application owners on the same web domain brings the possible threat of cookie stealing or cookie injecting.
By default ASP.NET cookies running on Windows Azure are bound to the specific domain instead of *.cloudapp.net, but if a developer intentionally sets this value (or uses a third party framework that does not set the proper value) then the application will be vulnerable to attacks based on cookies.
So now you are asking how to fix this behavior. The answer is very easy; as this fault is not in Windows Azure but in HTTP protocol, you have to prevent the possibility of a cookie being sent to any other application than the intended one. You can get it associating your own custom domain name to application and emit cookies bound to that domain. In this way cookies of your own application can be read or set only when a HTTP request will address the write context (i.e. right domain).
Setting a custom domain for your own application is a process that does not involve Windows Azure platform directly. You have to deal with your own preferred DNS provider and you can follow one of these procedures:
You can find more details at http://www.windowsazure.com/en-us/develop/net/common-tasks/custom-dns/
Nice article Giuseppe and Sean. Thanks for sharing :-)
Doesn't your suggested solution then cause all of my own domain cookies to be sent to Microsoft? Wouldn't these private cookies then be subject to collection and use by the NSA?