Introduction In the context of SAP web
applications, the usage of domain relaxation can often be observed. It relaxes the document.domain property of the web application to a higher level domain, which allows different applications to communicate and interact across origin boundaries, if they agree to the same domain as origin. In addition, SAP web applications implement a token-based single sign-on mechanism, by storage of a SAP Logon Ticket in the MYSAPSSO2 cookie, that is similarly scoped to a higher-level domain. Both practices cause security risks under certain circumstances which are often not considered or underestimated.
Internal SAP web applications in companies are usually hosted in Intranet subdomains, like a.example.local and b.example.local, and the origin of the application, respectively the MYSAPSSO2 cookie scope, is raised to the Intranet root domain example.local. Besides the SAP applications, further web applications are hosted similarly in subdomains like c.example.local. From a security perspective, mostly business critical SAP applications are mixed at the same domain level with possibly not-so-critical other internal web applications.
Security Impact Relaxation of the document.domain property of a web application exposes the DOM to other web
applications in arbitrary subdomains of the relaxed domain value. A direct consequence of this is, that the effects of Cross-Site Scripting vulnerabilities (XSS) of applications in these subdomains directly affect the relaxing application, as if it would be vulnerable itself. A XSS attack would be executed as follows:
- The attacker injects the malicious script payload in the vulnerable application, which is hosted in a sub domain, e.g. vulnerable.example.local. The payload is executed in the victims browser as he visits the vulnerable page.
- The injected payload relaxes document.domain to the same value, as the relaxing target application does, example.local. This is essential to put both applications, vulnerable and target, into the same origin in the next attack step.
- In the next step, the payload loads the target application in a frame or a new window. The loaded application performs the intentional relaxation to example.local.
- Because both applications relaxed their document.domain properties to example.local, the malicious JavaScript code is now able to interact with the DOM of the target application, as if they were hosted in the same origin.
Similar applies to the domain attribute of cookies. Because it was set to the parent domain, example.local, the cookie is transmitted to all child domains. In context of SAP web applications, the httpOnly flag of the MYSAPSSO2 cookie is fortunately enabled by default, which means that the cookie is protected against client-side attacks. Nevertheless, rogue or compromised web applications below the relaxed domain are still able to steal this cookie on the server-side. This cookie acts as token for single sign-on authentication to all SAP applications, a user is authorized for.
In summary the risk for SAP applications is, that XSS vulnerabilites in third party Intranet applications can leverage to a compromise of a SAP account or takeover of a session.
Example
This page contains some super-secret content, is hosted in the domain fallout.skora.net and relaxes document.domain to skora.net. The attacker page is hosted in a different subdomain, demo.skora.net, and relaxes document.domain as the victim page on request. Two attack techniques are shown:
- Loading of victim page in a frame on the attacker page.
- Loading of victim page in a new browser window or tab.
Both techniques have their pros and cons. The first method is more unobtrusive, because the frame can be hidden from the victims user. Unfortunately (from the attackers point of view), framing of pages can be prevented by the X-Frame-Options HTTP header. The second demonstrated method allows the attack without framing, but is easier to detect by the victim user, because a windows pops up for a short time.
Things to Consider...
...as Security Tester
Always check for relaxation of the document.domain property in web application audits. This applies especially for SAP-based web applications, because their frameworks use this feature quite often. For this purpose open the JavaScript console of your favorite audit browser and check if the value of document.domain is equal to the value of window.location.hostname property or the URL in the address bar of the browser. If they don't match, it is relaxed. If other applications with lower security requirements are hosted below this origin, the relaxing application is possibly at risk. If there is a known XSS vulnerability in one of the applications hosted in subdomains, then the relaxing application can be attacked by this XSS vulnerability.
The MYSAPSSO2 cookie is normally scoped to a higher level domain. If non-SAP web applications are hosted under this domain, this is a risk, which should be reflected in audit reports. It should be checked if the httpOnly flag was disabled explicitely for the MYSAPSSO2 cookie, because it exposes the SAP logon token to XSS attacks unnecessarily.
In unscoped penetration testing engagements with the SAP application environment as target, it can be easier to identify unrelated Intranet applications that are vulnerable against XSS and attack the SAP applications indirectly with the techniques described above.
...in Planning and Operation of the SAP Application Environment
SAP web applications which use domain relaxation and SAP Logon Tickets via MYSAPSSO2 cookies scoped to higher level domains, should be isolated in a separate Intranet domain, like sap.example.local. The domain relaxation and cookie scoping should not exceed this domain. No other web application with lower security requirements should be hosted below this domain.
The SAP Logon Ticket property ume.logon.httponlycookie should be set to (the default value) true, to prevent client-side stealing of the cookie in XSS attacks. This doesn't protect against server-side attacks, so the domain separation advice applies also here.
Generally the usage of domain relaxation and scoping of cookies to higher level domains should be omitted. Browsers offer more secure alternatives like the Window.postMessage API for such purposes, that keep the domain boundaries intact. This should be considered in custom build applications.
Many thanks go to Daniel Sauder (@DanielX4v3r) for proofreading!