OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] Updated: (SECURITY-12) PE: Add material onRelayState sanitization



     [ http://tools.oasis-open.org/issues/browse/SECURITY-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Cantor updated SECURITY-12:
---------------------------------

    Proposal: 
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:

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.
-------


  was:
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.
-----

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:

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 the service provider to perform appropriate sanitization of the RelayState value and any URLs derived from it. The URL scheme 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 the service provider to perform appropriate sanitization of the RelayState value and any URLs derived from it. The URL scheme SHOULD be limited to "https" or "http", and protection against unencoded executable content must be applied.
-------



Clarify applicability of guidance to IdPs and SPs and difference between RelayState and the URLs computed from it.

> PE: Add material on RelayState sanitization
> -------------------------------------------
>
>                 Key: SECURITY-12
>                 URL: http://tools.oasis-open.org/issues/browse/SECURITY-12
>             Project: OASIS Security Services (SAML) TC
>          Issue Type: Improvement
>          Components: Bindings, Profiles
>    Affects Versions: Version 2.0
>            Reporter: Scott Cantor
>             Fix For: 2.0 incorporating Approved Errata
>
>
> A recent paper (http://www.ai-lab.it/armando/pub/sec2011.pdf) outlines some threats that in small part involve problems with RelayState handling in implementations. Conversations with the author at the end of last year suggested we add clarifying material if possible to guide implementers to avoid some of the worst problems.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]