Cookie scoped to parent domain security vulnerability in Fiori Launchpad

[former_member514516]

Hi,

We ran a security vulnerability scans over our Fiori Launchpad which will be hosting a few of our Enterprise Fiori applications.. This scan has flagged us with a "Cookie scoped to parent domain" risk.. The description of the issue is similar to the one described here.

Can somebody help if we should worry about this or can ignore this? I assume this was flagged as the apps are under subdomain of the Fiori Launchpad's domain.

Thanks

Michael

[Ivan-Mirisola · Accepted solution]

Hi Michael,

Suppose you call it with the following URI 'flp.hostname.com'. Here the hostname.com is FLP's domain. Thus, any further HTTP requests that needs to perform SSO will require the MYSAPSSO2 cookie to be sent as well. If you have additional systems connected via FLP (let's say you have a separate SRM box), you will probably want to have SSO. In order to have SSO, the SAP Logon Ticket issued by the SAP Gateway System has to be accepted by the other systems and must be valid for that exact same domain. Therefore, your SRM box would need be something like srm.hostname.com. In this particular scenario, the cookie has to be set as parent - otherwise SSO wouldn't be possible.

Needless to say, access to FLP is recommended via SAP Web Dispatcher. In other words, SAP-WD (most likely to be installed on a DMZ) is not just used as load-balancer software, but it is more intended to avoid exposing all URI involved in the FLP communication/integration and allow Javascript applications run without crossing domain borders. In other words, DNS resolution for all URI's involved must fall to the addresses assigned to SAP-WD. In such case, it won't really matter if the cookie is set as parent or not. This way, there should be no risk of a parent application performing a call to an unwanted system sitting in the same domain using that cookie. That is true simply because it must go through SAP-WD anyway - which should be properly configured to allow the cookie to pass only for those subdomains involved in the FLP scenario.

Furthermore, FLP has protection against Clickjacking attacks. So, you are still protected by any attacks that may use iFrame techniques to perform misuse of cookies.

I'd recommend using SAP-WD in any case - avoiding exposure of direct server communication. Doing so will also help you manage centrally how FLP is accessed. Not to mention using a single trusted SSL certificate for all servers involved.

With that said, if you still feel uncomfortable with the cookie being set as parent, you could always open a support ticket to investigate the issue in more depth.

Hope this info helps!

Best regards,
Ivan

[former_member514516 · Accepted solution]

Thanks Ivan for the very detailed and informative reply.

In our case, we are using a Fiori Launchpad hosted in SAP Cloud Platform via Portal Services. The backend is an on-premise classic SAP system. Embedded in this backend system is the Netweaver Gateway and the Web Dispatcher which are used in our Principal Propagation setup between the SAP Cloud Platform and the backend system.

So with this this setup with what you said, could I say we should be fine and can just disregard the Cookie scoped to parent domain security?

[Ivan-Mirisola · Accepted solution]

Hi Michael,

Oh, thanks for clarifying your setup.

With that setup in mind, on SCP, most cookies are just part of session management between browser, IdP and SP. In other words it is mostly used to make sure requests are flowing properly.

IMHO: The most critical aspect of security is implemented via SAML assertion tokens. This token is what is used to identify a user to an application and perform SSO. Therefore, I would keep an extra eye on exploitation possibilities regarding any vulnerability with the SAML implementation.

Just for the sake of sanity, let me start first by stating that SCP doesn't store SAML tokens as cookies in your browser. It is rather a request payload attribute named 'SAMLResponse' that is re-passed on each new request whenever authentication is required. Thus you do not have a security issue if the cookie is set as parent. SAML Assertion Token is protected by several mechanisms (signatures, validity, certificates, base64 enconding) that makes it very hard for any attacker to impersonate or forge that token.

If you still need more clarification on the cookie being set as parent, please share its name (I did not get a hand on any tool yet to perform such security tests). With its name I could tell you what that cookie is meant for and perhaps on why it is being set as parent - I am confident there is a good reason for it to be the way it is.

Hope this helps,

Best regards,
Ivan

[former_member514516 · Accepted solution]

Hi Ivan,

I believe this is the name of the cookie: oucrsqruhcgpgviqqxkwutehx

Thanks for your help here.

Michael

[Ivan-Mirisola · Accepted solution]

Hi Michael,

That cookie is used to store some communication state information that is only relevant between the IdP and SP. Simply put, that is internal information used by the SAML communication.

My understanding is that it doesn't pose a threat because it is not used to perform authentication nor authorization.

To learn more, please check this document and search for RelayState.

Best regards,
Ivan

[former_member1316380]

The short answer to Michael's question is:
"Yes, you should be *seriously* worried about the domain scope of the MYSAPSSO2 cookie. The scan that flagged this as an issue is doing you a great service to bring this to your attention."

The long answer and further explanation is this:
You need to ensure that the the hosts that exist under this common parent domain that the cookie is scoped to are the absolute minimum of SAP hosts that actually require visibility of the MYSAPSSO2 cookie to authenticate the user and no others.

Any device or person that obtains a copy of your MYSAPSSO2 cookie can fully authenticate as the user who was issued that cookie. This means that the cookie should not be advertised to all hosts in a domain - unless that domain is heavily controlled and only has hosts in it that are SAP hosts that actually require visibility into this cookie. It is unfortunate that SAP chose to use relaxed cookie domain scoping to achieve cross-host SSO when so many more secure alternatives exist for this problem, but, that being said, it is possible to minimize your exposure by ensuring that you create a common parent domain for only those sap hosts that need to see the MYSAPSSO2 cookie for authentication.

Comments on this question from SAP that state "it doesn't pose a threat because it is not used to perform authentication" are just plain wrong. Any host under the parent domain that is compromised can be used to hijack the user's session and the attacker can then authenticate as the user and perform actions as that user. No amount of "click-jacking protection" mitigates a "session hijacking" attack that occurs as a result of insecure cookie scoping. Comments from SAP that lead a customer into a false sense of security around a vulnerability exposure like this are not helpful.

[former_member1316380]

This article provides a good overview of the MYSAPSSO2 cookie: https://wiki.scn.sap.com/wiki/display/ASJAVA/The+MYSAPSSO2+cookie

Note that the article clearly states the MYSAPSSO2 cookie "is the encoded content of the SAP Logon Ticket. The browser is used to transmit the Logon Ticket from system to system via the MYSAPSSO2 cookie."