Hi Team, I am facing the following issue - please share if you think of any fix. Thanks.

One of the Relying Parties is making a request to ISAM IdentityProvider . It includes Target / RelaySate in the SAMLAuthnRequest but this RelayState has XSS vulnerability. From Federation Runtime Trace's RequestSecurityToken – Saml20Claims , we do see that RelayState is encoded as below:

RelayState=""/>tes<script>alert(1)</script>"

We are getting this RelayState from the Service Provider's SAML Authn Request. ISAM is the IDP in this scenario. The STSUU has the RelayState URL encoded – highlighted in bold italics above.

Is it possible to modify the RelayState in STSUU from the mapping rule? If not, Is there another way to fix this XSS Vulnerability in RelayState. I am not quite sure if it is possible to Base64 encode the RelayState before sending it out to ISAM IdP. The SP could escape the characters , but since this in the URL typed into a browser anybody can change that.

We tried to add an Access Policy for this Federation, just for tracing and I am able to get the Relay state from context.getRequest().getParameter()

RelayState : "/>test<script>alert(1)</script>

But wondering if there is a way to change this request parameter from within access policy.

Thank you!

------------------------------
Rajkumar
------------------------------

Hi Rajkumar,

My two cents...
It seems like a XSS attack using RelayState is a known technique. See the "E90: RelayState sanitization" part of this SAML 2.0 document.
That reference states that you must verify RelayState by checking the URL scheme (for example, disallowing anything but "http" or "https"), and by disallowing unencoded characters.
So what about checking the sanity of the RelayState in the Access Policy, and halt the flow if you detect a possible XSS attack?

Kind regards, Peter.

------------------------------
Peter Volckaert
Senior Sales Engineer
Authentication and Access
IBM Security
------------------------------

Original Message:
Sent: Wed April 29, 2020 09:35 AM
From: rajkumargodi F253
Subject: XSS Vulnerability in RelayState of SAMLAuthnRequest

Hi Team, I am facing the following issue - please share if you think of any fix. Thanks.

One of the Relying Parties is making a request to ISAM IdentityProvider . It includes Target / RelaySate in the SAMLAuthnRequest but this RelayState has XSS vulnerability. From Federation Runtime Trace's RequestSecurityToken – Saml20Claims , we do see that RelayState is encoded as below:

RelayState="&quot;/&gt;tes&lt;script&gt;alert(1)&lt;/script&gt;"

We are getting this RelayState from the Service Provider's SAML Authn Request. ISAM is the IDP in this scenario. The STSUU has the RelayState URL encoded – highlighted in bold italics above.

Is it possible to modify the RelayState in STSUU from the mapping rule? If not, Is there another way to fix this XSS Vulnerability in RelayState. I am not quite sure if it is possible to Base64 encode the RelayState before sending it out to ISAM IdP. The SP could escape the characters , but since this in the URL typed into a browser anybody can change that.

We tried to add an Access Policy for this Federation, just for tracing and I am able to get the Relay state from context.getRequest().getParameter()

RelayState : "/>test<script>alert(1)</script>

But wondering if there is a way to change this request parameter from within access policy.

Thank you!

------------------------------
Rajkumar
------------------------------

Hi Peter, Thank you for sharing the information. I will try the Access Policy approach and see if I can stop the flow.

Regards,
Raj.

------------------------------
Rajkumar
------------------------------

Original Message:
Sent: Thu April 30, 2020 03:15 AM
From: Peter Volckaert
Subject: XSS Vulnerability in RelayState of SAMLAuthnRequest

Hi Rajkumar,

My two cents...
It seems like a XSS attack using RelayState is a known technique. See the "E90: RelayState sanitization" part of this SAML 2.0 document.
That reference states that you must verify RelayState by checking the URL scheme (for example, disallowing anything but "http" or "https"), and by disallowing unencoded characters.
So what about checking the sanity of the RelayState in the Access Policy, and halt the flow if you detect a possible XSS attack?

Kind regards, Peter.

------------------------------
Peter Volckaert
Senior Sales Engineer
Authentication and Access
IBM Security

Original Message:
Sent: Wed April 29, 2020 09:35 AM
From: rajkumargodi F253
Subject: XSS Vulnerability in RelayState of SAMLAuthnRequest

Hi Team, I am facing the following issue - please share if you think of any fix. Thanks.

One of the Relying Parties is making a request to ISAM IdentityProvider . It includes Target / RelaySate in the SAMLAuthnRequest but this RelayState has XSS vulnerability. From Federation Runtime Trace's RequestSecurityToken – Saml20Claims , we do see that RelayState is encoded as below:

RelayState="&quot;/&gt;tes&lt;script&gt;alert(1)&lt;/script&gt;"

We are getting this RelayState from the Service Provider's SAML Authn Request. ISAM is the IDP in this scenario. The STSUU has the RelayState URL encoded – highlighted in bold italics above.

Is it possible to modify the RelayState in STSUU from the mapping rule? If not, Is there another way to fix this XSS Vulnerability in RelayState. I am not quite sure if it is possible to Base64 encode the RelayState before sending it out to ISAM IdP. The SP could escape the characters , but since this in the URL typed into a browser anybody can change that.

We tried to add an Access Policy for this Federation, just for tracing and I am able to get the Relay state from context.getRequest().getParameter()

RelayState : "/>test<script>alert(1)</script>

But wondering if there is a way to change this request parameter from within access policy.

Thank you!

------------------------------
Rajkumar
------------------------------

Hi Rajkumar,

RelayState can't be modified based on SAML2 spec, ISAM IdP sends back the same received RelayState to the SP, I don't think you could change RelayState with mapping rule in ISAM IdP.

If the RelayState will be used in SP as target upon receiving back with the SAML response, it would be better to validate the RelayState value at SP.

In ISAM IdP, for SP init SSO flow, RelayState could be retrieved from SAML claims within mapping rule, so it's possible to validate RelayState at ISAM IdP, e.g. following mapping rule retrieves the RelayState, with some validation logic to add, it could abort a flow by throwing an STS exception within mapping rule.

Best Regards

Chen Yongming


importPackage(Packages.com.tivoli.am.fim.trustserver.sts);
importPackage(Packages.com.tivoli.am.fim.trustserver.sts.uuser);
importPackage(Packages.com.tivoli.am.fim.trustserver.sts.utilities);

var claims = stsuu.getRequestSecurityToken().getAttributeByName("Claims").getNodeValues();

for (var i = 0; i < claims.length; i++) {
   var dialect = claims[i].getAttribute("Dialect");

   if ("urn:ibm:names:ITFIM:saml".equalsIgnoreCase(dialect)) {
     var samlclaims = claims[i].getElementsByTagName("fimc:Saml20Claims");

     if (samlclaims != null) {
       var samlclaim = samlclaims .item(0);
       var relayState = samlclaim.getAttribute("RelayState");
       IDMappingExtUtils.traceString("relayState : " + relayState);

       //TO DO, validate relayState {
         IDMappingExtUtils.throwSTSUserMessageException("relayState contains script, flow is aborted.");
       }
     }
   }
}

------------------------------
Yongming Chen
------------------------------

Original Message:
Sent: Wed April 29, 2020 09:35 AM
From: Rajkumar Godi
Subject: XSS Vulnerability in RelayState of SAMLAuthnRequest

Hi Team, I am facing the following issue - please share if you think of any fix. Thanks.

One of the Relying Parties is making a request to ISAM IdentityProvider . It includes Target / RelaySate in the SAMLAuthnRequest but this RelayState has XSS vulnerability. From Federation Runtime Trace's RequestSecurityToken – Saml20Claims , we do see that RelayState is encoded as below:

RelayState="&quot;/&gt;tes&lt;script&gt;alert(1)&lt;/script&gt;"

We are getting this RelayState from the Service Provider's SAML Authn Request. ISAM is the IDP in this scenario. The STSUU has the RelayState URL encoded – highlighted in bold italics above.

Is it possible to modify the RelayState in STSUU from the mapping rule? If not, Is there another way to fix this XSS Vulnerability in RelayState. I am not quite sure if it is possible to Base64 encode the RelayState before sending it out to ISAM IdP. The SP could escape the characters , but since this in the URL typed into a browser anybody can change that.

We tried to add an Access Policy for this Federation, just for tracing and I am able to get the Relay state from context.getRequest().getParameter()

RelayState : "/>test<script>alert(1)</script>

But wondering if there is a way to change this request parameter from within access policy.

Thank you!

------------------------------
Rajkumar
------------------------------

Hi Yonming,

I got the RelayState in the mapping rule using SAML claims . Now will have to check that and abort if it is not valid url. Thank you so much for your inputs. They are really helpful. 

Regards,
Raj.

------------------------------
Rajkumar
------------------------------

Original Message:
Sent: Tue May 05, 2020 10:05 AM
From: Yongming Chen
Subject: XSS Vulnerability in RelayState of SAMLAuthnRequest

Hi Rajkumar,

RelayState can't be modified based on SAML2 spec, ISAM IdP sends back the same received RelayState to the SP, I don't think you could change RelayState with mapping rule in ISAM IdP.

If the RelayState will be used in SP as target upon receiving back with the SAML response, it would be better to validate the RelayState value at SP.

In ISAM IdP, for SP init SSO flow, RelayState could be retrieved from SAML claims within mapping rule, so it's possible to validate RelayState at ISAM IdP, e.g. following mapping rule retrieves the RelayState, with some validation logic to add, it could abort a flow by throwing an STS exception within mapping rule.

Best Regards

Chen Yongming


importPackage(Packages.com.tivoli.am.fim.trustserver.sts);
importPackage(Packages.com.tivoli.am.fim.trustserver.sts.uuser);
importPackage(Packages.com.tivoli.am.fim.trustserver.sts.utilities);

var claims = stsuu.getRequestSecurityToken().getAttributeByName("Claims").getNodeValues();

for (var i = 0; i < claims.length; i++) {
   var dialect = claims[i].getAttribute("Dialect");

   if ("urn:ibm:names:ITFIM:saml".equalsIgnoreCase(dialect)) {
     var samlclaims = claims[i].getElementsByTagName("fimc:Saml20Claims");

     if (samlclaims != null) {
       var samlclaim = samlclaims .item(0);
       var relayState = samlclaim.getAttribute("RelayState");
       IDMappingExtUtils.traceString("relayState : " + relayState);

       //TO DO, validate relayState {
         IDMappingExtUtils.throwSTSUserMessageException("relayState contains script, flow is aborted.");
       }
     }
   }
}

------------------------------
Yongming Chen

Original Message:
Sent: Wed April 29, 2020 09:35 AM
From: Rajkumar Godi
Subject: XSS Vulnerability in RelayState of SAMLAuthnRequest

Hi Team, I am facing the following issue - please share if you think of any fix. Thanks.

One of the Relying Parties is making a request to ISAM IdentityProvider . It includes Target / RelaySate in the SAMLAuthnRequest but this RelayState has XSS vulnerability. From Federation Runtime Trace's RequestSecurityToken – Saml20Claims , we do see that RelayState is encoded as below:

RelayState="&quot;/&gt;tes&lt;script&gt;alert(1)&lt;/script&gt;"

We are getting this RelayState from the Service Provider's SAML Authn Request. ISAM is the IDP in this scenario. The STSUU has the RelayState URL encoded – highlighted in bold italics above.

Is it possible to modify the RelayState in STSUU from the mapping rule? If not, Is there another way to fix this XSS Vulnerability in RelayState. I am not quite sure if it is possible to Base64 encode the RelayState before sending it out to ISAM IdP. The SP could escape the characters , but since this in the URL typed into a browser anybody can change that.

We tried to add an Access Policy for this Federation, just for tracing and I am able to get the Relay state from context.getRequest().getParameter()

RelayState : "/>test<script>alert(1)</script>

But wondering if there is a way to change this request parameter from within access policy.

Thank you!

------------------------------
Rajkumar
------------------------------