PE: Add material on RelayState sanitization

In SAML Bindings: Add text to section 3.1.1, Use of RelayState Some bindings that define a "RelayState" mechanism do not provide for end to end origin authentication or integrity protection of the RelayState value. Most such bindings are defined in conjunction with HTTP, and RelayState is often involved in the preservation of HTTP resource state that may involve the use of HTTP redirects, or embedding of RelayState information in HTTP responses, HTML content, etc. In such cases, implementations need to beware of Cross-Site Scripting (XSS) and other attack vectors (e.g., Cross-Site Request Forgery, CSRF) that are common to such scenarios. Implementations MUST carefully sanitize the URL schemes they permit (for example, disallowing anything but "http" or "https"), and should disallow unencoded characters that may be used in mounting such attacks. This caution applies to both identity and service provider implementations. Add text to sections 3.4.5.2, 3.5.5.2, 3.6.5.2: When using RelayState in conjunction with HTTP redirects or response information, implementations MUST carefully sanitize the URL schemes they permit (for example, disallowing anything but "http" or "https"), and should disallow unencoded characters that may be used in mounting such attacks. In SAML Profiles: Add text to section 4.1.5 Unsolicited Responses --------- Note that the use of unsolicited responses can lead to Cross-Site Request Forgery (CSRF) vulnerabilities due to the inability to ensure that a request from the client originated the SAML profile transaction. Service providers SHOULD have a means of disabling the acceptance of unsolicited responses if circumstances warrant. The use of solicited responses may also be vulnerable to such attacks, the use of cookies to correlate the issuance of SAML requests and responses with the same client being one possibly solution. However, if unsolicited respones cannot be prevented, no improvement to the solicited case will be of use. --------- Insert new section 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. -------- Add text to section 4.2.5: --------- The RelayState header block defined for use with this profile MAY be used to preserve information about resources requested by the client 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. -------