 | This blog elaborates on issues related to the web domain under which cloud applications are visible in internet. Unlike the problem discussed in part 1 this one is more configuration-related, than a programming technique. This is the reason why we will not see code samples, which I hope will not make the blog boring. The topic is pretty important for cloud applications security, and deserves attention, I believe. |
Using an own web domain, instead of common one, provided by the cloud (infrastructure or platform) service provider has multiple benefits. Of course the branding and marketing aspects are important for B2C applications, and search engine indexing does matter. However, here I will focus primarily on the security implications of having own domain versus sharing a web domain with other cloud tenants.
The key is that web domains offer isolation, which is a major pillar in the web security policies of various web technologies, protocols, standards, and products. They originate from the old school “perimeter security”, relying simply on the facts that a corporation or organization
- hosts its data and the software processing it in an own premise
- has own web domain
- has a personnel responsible to protect this trusted area from the outside world (internet)
The introduction of cloud and on-demand software services has broken most of the perimeter security assumptions in IT, while the security policies related to web domains are here to stay and very difficult to evolve due to compatibility risks.
More concrete, the challenge related with web domains is that application providers sharing the same cloud platform or infrastructure (cloud tenants) usually do not trust each other, while sharing a web domain implies trust. If cloud tenants share a web domain then the trust boundaries are broken. The risk from that can be hardly assessed as it is hard to enumerate all technologies, protocols, standards, and products, which security policies rely on web domains as an isolation mechanism.
Let's observe some examples how web security policies and standards get affected by domain sharing.
To make examples more concrete, I will illustrate them with HANA Cloud Platform (HCP), where by default applications are exposed in internet in a common domain hana.ondemand.com.
Server certificate authentication
Recent browser versions provide convenient and user-friendly authentication of the server certificate during HTTPS connection establishment, which is a basic level of protection for the end user. In short, a browser will notify the user when the identity of the server, to which the connection is established, is not the one the user requests.
However, when it comes to a cloud application the question that matters is what the identity of the server certificate is – does it identify the exact application or the whole cloud domain? Technically, if the server certificate is issued to a generic entity, e.g. *.hana.ondemand.com, then during SSL connection establishment the client will identify the complete domain, instead of a particular server. That is the server authentication done by the browser will still succeed even if a user requesting https://genuine.hana.ondemand.com is redirected to https://fake.hana.ondemand.com
Same-origin policy
The same-origin policy (SOP) uses host name, which is strong enough to distinguish and isolate genuine.hana.ondemand.com from fake.hana.ondemand.com. However, in order to enable some technologies and programming techniques SOP has relaxations. It allows a script in a web page to set the document.domain parameter to a super domain, a suffix of the host name. If two pages explicitly and mutually set their respective document.domain parameters to the same value, access is granted (for details see [1], [2], [3], and [4]).
Suppose that application genuine1.hana.ondemand.com wants to grant application genuine2.hana.ondemand.com access and avoid the SOP restrictions (e.g. in order to enable cross-application UI mash-ups or alike). To achieve that in both applications the document.domain property is changed to hana.ondemand.com. The problem now is that a malicious application malicious.hana.ondemand.com can do the same, with which to circumvent SOP and execute attacks like XSS or CSRF against genuine1 and genuine2.
CORS (Cross Origin Resource Sharing)
CORS is a much better approach for relaxing SOP. It enables applications to define trust across origins (web domains) by allowing browsers to make cross-origin request (for details see [5], [6]).
The allowed origins configuration however shall be done very cautiously with maximum restriction only to the trusted entities. For example a trust to a common domain like *.hana.ondemand.com will be vulnerable; instead the exact application origin https://genuine.hana.ondemand.com shall be used.
Cookies manipulation via cross-site cooking
Cross-site cooking is an exploit allowing the attacker to set or change cookies for an application in another domain (see [3], [7], [8], and [9]). The cookies management policy allows any subdomain of a given domain to set, and receive the cookies for that domain. For example a malicious application malicious.hana.ondemand.com can set cookies with domain .hana.ondemand.com, which will force the user’s browser to send them with all subsequent requests to genuine.hana.ondemand.com. With this technique the malicious application can set or change sensitive cookies of other applications sharing the same domain.
Adobe cross-domain policy
Adobe also has a security policy based on web domains. The Adobe cross-domain trust configuration grants a web client, such as Adobe Flash Player or Adobe Reader, permission to handle data across different domains (see [3], [10]). If the trust is granted to a complete domain like .hana.ondemand.com, one can hardly separate trusted and untrusted entities served from hana.ondemand.com.
As you see there are various means of the trust between applications sharing the same web domain, which implies variety of threats from a potentially malicious application with which you share a domain. As the list of examples here cannot be considered complete, it is very hard to assess the security risk from running an application in a shared domain with other untrusted applications. Therefore the safe solution is to always run critical productive applications in own web domain.
References:
[1] http://www.w3.org/Security/wiki/Same_Origin_Policy
[2] http://en.wikipedia.org/wiki/Same-origin_policy
[3] https://code.google.com/p/browsersec/wiki/Part2
[5] http://www.w3.org/TR/cors/
[6] http://en.wikipedia.org/wiki/Cross-origin_resource_sharing
[7] http://www.securiteam.com/securityreviews/5EP0L2KHFG.html
[8] http://kuza55.blogspot.com/2008/02/understanding-cookie-security.html
[9] http://en.wikipedia.org/wiki/Cross-site_cooking
[10] http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html
- SAP Managed Tags:
2 Comments
