Question

We are creating a message like following which is a SignInRequestMessage

var message = Microsoft.IdentityModel.Protocols.WSFederation.WSFederationMessage.CreateFromUri(Request.Url);

It has the following properties:

Microsoft.IdentityModel.Protocols.WSFederation.SignInRequestMessage

Action: "wsignin1.0"

message.Parameters

Count = 2
    [0]: {[wa, wsignin1.0]}
    [1]: {[wtrealm, javascript:alert(/test/)]}

Notice the second parameter in the message is a javascript, and when adfs redirect to it, we actually see the alert.

This happens when user is logged in, and within the same session we try to enter URL like following

https://localhost/StarterSTSLib/Login.aspx?wa=wsignin1.0&wtrealm=javascript:alert(/test/)

Does anyone have any suggestion on how we prevent the wtrealm from this cross site scripting vulnerability?

Was it helpful?

Solution

Production ready STS like ADFS does not rely on wtrealm to reply the token back. Whoever manages the ADFS will setup the app/relying party and specify the ednpoint where the token is posted to.

The STS generated by WIF "add sts reference" will take the wtrealm as the endpoint to post the token. That's why it is a development STS, not production ready.

In short on depends on the STS implementation wheter to use wtrealm as the endpoint. You should have a repository that asociates realms with urls like adfs.

OTHER TIPS

What you need here is URL encoding. Non-alphanumeric characters need to be replaced with their %xx (hex) representations...

https://example.com/StarterSTSLib/Login.aspx?wa=wsignin1.0&wtrealm=javascript%3aalert%28%2ftest%2f%29

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top