JSON dictionary in the Relay State parameter

[Florian Lengyel]

My intention in this discussion is not to be confrontational but to seek a shared understanding of the SAML 2.0 specifications, especially regarding handling the RelayState. According to the text from Errata E90:

4.1.6 Use of Relay State

The RelayState feature of the various HTTP-based bindings defined for use with this profile MAY be used to preserve information about resources requested by the user agent prior to the use of the profile. As discussed in [SAMLBind], the lack of integrity protection in many scenarios, including the case of unsolicited responses, makes it **essential for identity and service providers to perform appropriate sanitization of the RelayState value and any URLs derived from it.** The URL scheme eventually derived SHOULD be limited to "https" or "http", and protection against unencoded executable content must be applied.

Section 4.1.6 indicates the necessity of sanitizing the RelayState value before deriving a URL. The implication is that a RelayState, while initially not a URL, can influence the creation or decision of one.

In the case of the two service providers we are discussing, the data passed through RelayState, a JSON dictionary and not a traditional URL, eventually dictates the navigation, necessitating prior sanitization. This interpretation aligns with the broader security principles that protect systems and users from potential vulnerabilities.


Florian Lengyel

________________________________
From: Florian Lengyel <Florian.Lengyel at cuny.edu>
Sent: Sunday, March 24, 2024 6:25 PM
To: Shib Users <users at shibboleth.net>
Cc: Brent Putman <putmanb at georgetown.edu>
Subject: Re: JSON dictionary in the Relay State parameter

The interpretation provided in your message that E90 only applies when the RelayState value is a URL is indeed not entirely accurate according to the text from the SAML 2.0 Errata E90. The errata do emphasize concerns around URLs because they're common and high-risk vectors for attacks such as XSS (Cross-Site Scripting) and CSRF (Cross-Site Request Forgery), but the caution is broader.

Here's a breakdown:

1. Sanitization and Security Concerns: The errata indicates that there's a need for careful sanitization due to the lack of "end-to-end origin authentication or integrity protection of the RelayState value." This concern applies broadly to the handling of RelayState, not exclusively to situations where RelayState is a URL.

2. Implementation Guidance: The guidance to "carefully sanitize the URL schemes they permit" and "disallow unencoded characters that may be used in mounting such attacks" suggests a focus on URLs, but the underlying principle is to prevent the RelayState from being exploited for attacks. This principle should apply to any content within RelayState that could be manipulated for malicious purposes.

3. URL-Specific Advice: While the text emphasizes URL schemes (restricting them to "http" or "https") and the prevention of executable content, the broader context of these guidelines is the prevention of XSS and CSRF attacks. This does not exclude other forms of data from being a concern if they can similarly be exploited due to improper handling or lack of sanitization.

4. Broader Application: The mention that "implementations MUST carefully sanitize...and should disallow unencoded characters" indicates a broader requirement than just for URLs. It suggests that any data within the RelayState should be handled in a way that prevents malicious exploitation, which would include ensuring that JSON structures or other data forms don't contain harmful content.

The intention is that all data, including but not limited to URLs, passed in the RelayState should be sanitized and secured against common web vulnerabilities. The errata's references to URL schemes and encoding primarily address the most common risks but do not limit the scope of sanitization to URLs alone.

Therefore, asserting that the standard's requirements for sanitizing RelayState apply only to URLs and not to other data formats like JSON is misinterpretation of the errata. It's critical for all transmitted data, regardless of format, to be secured against potential web-based vulnerabilities, especially in authentication flows.


________________________________
From: users <users-bounces at shibboleth.net> on behalf of Brent Putman via users <users at shibboleth.net>
Sent: Sunday, March 24, 2024 3:26 PM
To: Shib Users <users at shibboleth.net>
Cc: Brent Putman <putmanb at georgetown.edu>
Subject: Re: JSON dictionary in the Relay State parameter


* This email originates from a sender outside of CUNY. Verify the sender before replying or clicking on links and attachments. *


On 3/24/24 12:32 AM, Florian Lengyel via users wrote:


In the SAML 2.0 Errata 05, the guidelines regarding RelayState sanitization are presented as requirements, not just recommendations. Implementations must carefully sanitize the URL schemes they permit, specifically restricting them to "http" or "https" and must disallow unencoded characters that could lead to security attacks

Have these requirements been relaxed to recommendations?



No, Errata 05 is still the latest.  However, I believe what you are referring to in E90 there doesn't actually apply in your case of a JSON value.  It only addresses the case where the RelayState value is a URL (which is somewhat common in the real world). Essentially, IF it is a URL, THEN it must have an http or https scheme only and be encoded appropriately to address XSS, CSRF and other attacks, etc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20240324/a6a42c9d/attachment.htm>