Security consideration when using *.cloudapp.net domain as production environment in Windows Azure

  • Article

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

Let’s start with a recap

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 https://*.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 https://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.

Phishing

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 https://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 https://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.

Let’s consider the HTTP protocol cookie policy in brief. Cookies are a simply way to share data (typically store user control data such as: user session id) between web server and HTTP client using a proper field in the HTTP header. HTTP protocol sets the scope of a cookie to a domain (cookies are bound to a domain); so every time an HTTP client (e.g. a web browser) is connected to a domain it can get/set values of cookies against the server (and the server vice versa to the client). Sending cookies is an operation done contextually and automatically on every HTTP request with every verb (GET, POST, PUT, DELETE ref. RFC2616 https://www.w3.org/Protocols/rfc2616/rfc2616.html) from the client (e.g. web browser). Users typically have not much more control of it, clients have settings to customize that behavior but a user cannot choose for every HTTP request which cookie he wants to allow or reject. Server has the same behavior but developers have more control over it because they can use custom code and they can write a custom logic for cookies’ allow/deny policy.

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.

  • User uses application A for hotel reservation. After he booked a room he doesn’t log out from the application and simply closes the tab. Then the user opens a new tab and goes to application B. When user browses application B, browser sends silently cookie to B. So application B can read all the cookies set while user was dealing with application A. Application B can also set values for that cookie, so on the next visit of browser to application A, values set from application B will be sent to application A.
  • User uses application A for hotel reservation. While he’s surfing on A he decides to have a look to his favorite weather channel to have a look at the weather during his own holiday. So user opens a new tab and types URL of his application B and looks to the forecast. For every page request to application B, application B can read and set values for cookies set by application A.

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

How to set a custom web domain for your own Windows Azure application

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:

  • Bind IP address (A field), so you will bind IP address in Microsoft Datacenter for your application to a custom domain.
  • Use a CNAME field, so you will associate your custom domain to your application, but request will involve a double lookup in DNS.

You can find more details at https://www.windowsazure.com/en-us/develop/net/common-tasks/custom-dns/

Additional Information: