Home/ Questions/Q 8404187
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-09T22:32:06+00:00

We are creating a message like following which is a SignInRequestMessage var message =

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0