(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/
If you already use a federated domain environment with Office 365, you cannot add a custom domain name at the domain menu in SharePoint Online directly. In this case, you can use the new-MSolFedratedDomain cmdlet in the Microsoft Online Services Module for Windows PowerShell.
(Post courtesy Soon Im Kim)
As a SharePoint Online Administrator you can create a public Website. When you setup the site, you can use a custom domain name that your company owns. In this case, if your environment is federated, you should use a new-MSolFedratedDomain cmdlet in "Microsoft Online Services Module for Windows PowerShell"
This article describes how to create a public-facing Website by using a custom domain name and you can see below 3 blocks:
To add a custom domain name, use these steps.
1. Navigate to Microsoft Online Services Module for Windows PowerShell by going to Start-> All Programs -> Microsoft Online Services. Right click on Microsoft Online Services Module for Windows PowerShell and click Run as administrator.
2. Once PowerShell is open, run $cred=Get-Credential. When the cmdlet prompts you for credentials, type your Office 365 admin username and password.
3. Run Connect-MsolService -Credential $cred. This cmdlet connects PowerShell session to your Office 365 account.
4. Confirm domain names in the Office 365 tenant domain using Get-MSolDomain.
5. Add a custom domain name you want to use as a public Web site address using new-MSolFederatedDomain cmdlet. Then, you can confirm your custom domain name is added using Get-MSolDomain again.
6. Now you can find your custom domain (in this example, www.onprem04.datamotion.co.kr ) at the Office 365 Domains and using Domain Intent menu, you can make this domain as a SharePoint Online Services as below.
Create a Public Web Site by using a custom domain name
1. Go to SharePoint Online Administration Center and Click ‘Site Collections’.
2. Click ‘New’ button and Click ‘Public Website’.
3. Create your Public Website. At the URL, choose the custom domain name you want to use as a SharePoint Public Website address.
Now click DNS Information and find what is suggested to add as CNAME then go to your domain manager and add a CNAME record in the DNS as per the information provided.
After updating DNS you can browse your site from internet using your domain name. Now we can find the Public Website as below.
To learn more, check out the following articles:
· Article 1, http://office.microsoft.com/en-us/sharepoint-online-enterprise-help/set-up-a-public-website-HA102476205.aspx
· Article 2, http://onlinehelp.microsoft.com/en-us/office365-enterprises/ff637595.aspx
If you are an IT Pro that will be deploying Office 365, or a Microsoft Partner studying for the 70-323 Administering Office 365 exam, make sure to head over to http://aka.ms/O365-CertJump to watch Ajinkya Pinto and Fulvio Salanitro (Partner Technical Consultants) share the information you need to know before deploying Office 365!
You can watch the streaming video or download as a WMV, MP4, or MP3 for watching on the go.