none
HttpRequestValidationException / A potentially dangerous Request.Form value was detected

    Question

  • I took the Geneva sample code (FederationForWebApps-VS2008) and customized it to my needs.   Everything seems to work up until the point the STS posts the token back to the relying party.   At this point, I encounter the attached error.   What does this mean in lay person terms?  Where do I begin troubleshooting?


    thanks!



    Server Error in '/rp' Application.
    --------------------------------------------------------------------------------

    A potentially dangerous Request.Form value was detected from the client (wresult="<t:RequestSecurityTo...").
    Description: Request Validation has detected a potentially dangerous client input value, and processing of the request has been aborted. This value may indicate an attempt to compromise the security of your application, such as a cross-site scripting attack. You can disable request validation by setting validateRequest=false in the Page directive or in the configuration section. However, it is strongly recommended that your application explicitly check all inputs in this case.

    Exception Details: System.Web.HttpRequestValidationException: A potentially dangerous Request.Form value was detected from the client (wresult="<t:RequestSecurityTo...").

    Source Error:


    [No relevant source lines]
     


    • Edited by scott_m Saturday, June 15, 2013 1:49 AM
    Wednesday, December 17, 2008 6:34 AM

Answers

  • If you continue to have this issue in the RTW version of WIF, you should check the following sequence using Fiddler or an equivelant tool:

    When the STS posts back to the RP, it will do so with the dangerous parameters that trigger this error.  However, the FAM should catch those parameters and then redirect back to the original RP page - without the offending form values.  If you do not see a 302 in the return sequence, then this redirect failed and the form was posted back to your RP page.  So, if all is working correctly, you should see a 302 to redirect to your STS, whatever pages you process in your STS, then when returning back to the RP, you should see a 302 at the Realm (this parameter is configured in your Web.Config), where the FAM is processing the dangerous post and creating the WIF cookie.  Once the FAM completes, you should end up at the originally requested page.

    If the correct thing is happening, you do not have to turn of FormValidation!

    If you find that there is no redirect and you are coming back to your realm page, and you have to turn off FormValidation to make it work, check the following:

    When the FAM creates a redirect to the STS, it will add several parameters to the query string.  These parameters include wrealm and wctx.  The wrealm is used by the call to FederatedPassiveSecurityTokenServiceOperations.ProcessSignInResponse to create the target for the redirect.  The wctx parameter is used to redirect from the realm page to the originally requested page.  Because this wctx parameter is quite complex, it is easy to mangle it as you go through the STS.

    Your STS will need to preserve the original query string that was sent by the FAM for the call to the creation of the SignInRequestMessage.  How you preserve this string can have a profound effect on the behavior when you return to the RP.  The original wctx parameter is a UrlEncoded set of parameters which must be sent back correctly encoded as a single value.  Once UrlDecoded, they appear to be separate parameters (with names like id and ru).

    In order to preserve the original set of parameters, you can walk the Request.QueryString and save off the values.  Then pass them around as necessary and fold them back together again when returning to the RP.  At the point that the responseMessage is fed to the FederatedPassiveSecurityTokenServiceOperations.ProcessSignInResponse function, the wctx message should be intact and look similar to "rm=0&id=passive&ru=%252fClaimsEnableWebSiteEx01%252fdefault.aspx".  Note that this is an entry in the Parameters collection on the responseMessage and not part of any QueryString.

    If you verify that this is the value for the parameter when you make the call to render the postback page, then you should see the 302 when you get back to the Realm page.  And you can turn validation back on for your pages.

    • Marked as answer by scott_m Tuesday, December 22, 2009 8:44 PM
    Thursday, December 03, 2009 11:06 PM
  • you may have to disable request validation for the page in question - add a ValidateRequest = false to the page directive.

    HTH
    Dominick Baier - http://www.leastprivilege.com
    • Proposed as answer by Dominick BaierMVP Thursday, December 18, 2008 8:23 AM
    • Marked as answer by scott_m Thursday, December 18, 2008 5:37 PM
    Wednesday, December 17, 2008 6:36 AM
  • In the latest WIF SDK for .NET 4.0 the templates now generate a custom RequestValidator to handle this:

    public class WsFederationRequstValidator : RequestValidator
    {
      protected override bool IsValidRequestString(HttpContext context, 
                              string value, 
                              RequestValidationSource requestValidationSource, 
                              string collectionKey, 
                              out int validationFailureIndex)
      {
        validationFailureIndex = 0;
        if (requestValidationSource == RequestValidationSource.Form &&
          collectionKey.Equals(WSFederationConstants.Parameters.Result, StringComparison.Ordinal))
        {
          if (WSFederationMessage.CreateFromFormPost(context.Request) as SignInResponseMessage != null)
          {
            return true;
          }
        }
    
        return base.IsValidRequestString(context, 
                          value, 
                          requestValidationSource, 
                          collectionKey, 
                          out validationFailureIndex);
      }
    }
    

    In the web.config add the following:

    <httpRuntime requestValidationType="WsFederationRequstValidator" />
    That should solve it.

    • Proposed as answer by agonzalest Thursday, June 24, 2010 9:36 PM
    • Marked as answer by scott_m Friday, June 25, 2010 12:41 AM
    Monday, June 14, 2010 8:41 PM
  • In the latest WIF SDK for .NET 4.0 the templates now generate a custom RequestValidator to handle this:

    <httpRuntime requestValidationType="WsFederationRequstValidator" />
    
    That should solve it.

    Note, in 4.5, SignIn request validation changes slightly.   Please see..

    WIF SIgnIn Request Validation in .NET 4.5

    • Marked as answer by scott_m Friday, January 25, 2013 3:06 AM
    Friday, January 25, 2013 3:06 AM

All replies

  • you may have to disable request validation for the page in question - add a ValidateRequest = false to the page directive.

    HTH
    Dominick Baier - http://www.leastprivilege.com
    • Proposed as answer by Dominick BaierMVP Thursday, December 18, 2008 8:23 AM
    • Marked as answer by scott_m Thursday, December 18, 2008 5:37 PM
    Wednesday, December 17, 2008 6:36 AM
  • Dominick Baier said:

    you may have to disable request validation for the page in question - add a ValidateRequest = false to the page directive.

    HTH


    Dominick Baier - http://www.leastprivilege.com




    Thanks.   That fixed it.

    Is that a potential secure hole?

    Is this something the RTM build of Geneva framework will address?
    • Edited by scott_m Wednesday, December 17, 2008 3:53 PM typo
    Wednesday, December 17, 2008 3:52 PM
  • Well - it is listed as a "known issue" in the docs.

    But there is no way to "fix" this - the request validation features makes sure no-one tries to post potentially dangerous data to a page (e.g. <a-z...). Since the token is in XML there is not much you can do.

    You shouldn't rely on automatic request validation anways (and encode all output) - so I don't see this as "hole".

    HTH
    Dominick Baier - http://www.leastprivilege.com
    Thursday, December 18, 2008 8:25 AM
  • It shouldn't be posting XML in the first place in my opinion. It was my understanding that when the token is being posted back to the relying party, the SAML token (XML) is encrypted according to the relying party. The relying party can then take this encoded value, decode it and decrypt it into a valid SAML Token to verify.
    Thomas
    Tuesday, December 23, 2008 6:04 PM
  • Then have a look at the token - it is standard XML encrypted data - and that involves angle brackets...

    Dominick Baier - http://www.leastprivilege.com
    Tuesday, December 23, 2008 10:24 PM
  • If you continue to have this issue in the RTW version of WIF, you should check the following sequence using Fiddler or an equivelant tool:

    When the STS posts back to the RP, it will do so with the dangerous parameters that trigger this error.  However, the FAM should catch those parameters and then redirect back to the original RP page - without the offending form values.  If you do not see a 302 in the return sequence, then this redirect failed and the form was posted back to your RP page.  So, if all is working correctly, you should see a 302 to redirect to your STS, whatever pages you process in your STS, then when returning back to the RP, you should see a 302 at the Realm (this parameter is configured in your Web.Config), where the FAM is processing the dangerous post and creating the WIF cookie.  Once the FAM completes, you should end up at the originally requested page.

    If the correct thing is happening, you do not have to turn of FormValidation!

    If you find that there is no redirect and you are coming back to your realm page, and you have to turn off FormValidation to make it work, check the following:

    When the FAM creates a redirect to the STS, it will add several parameters to the query string.  These parameters include wrealm and wctx.  The wrealm is used by the call to FederatedPassiveSecurityTokenServiceOperations.ProcessSignInResponse to create the target for the redirect.  The wctx parameter is used to redirect from the realm page to the originally requested page.  Because this wctx parameter is quite complex, it is easy to mangle it as you go through the STS.

    Your STS will need to preserve the original query string that was sent by the FAM for the call to the creation of the SignInRequestMessage.  How you preserve this string can have a profound effect on the behavior when you return to the RP.  The original wctx parameter is a UrlEncoded set of parameters which must be sent back correctly encoded as a single value.  Once UrlDecoded, they appear to be separate parameters (with names like id and ru).

    In order to preserve the original set of parameters, you can walk the Request.QueryString and save off the values.  Then pass them around as necessary and fold them back together again when returning to the RP.  At the point that the responseMessage is fed to the FederatedPassiveSecurityTokenServiceOperations.ProcessSignInResponse function, the wctx message should be intact and look similar to "rm=0&id=passive&ru=%252fClaimsEnableWebSiteEx01%252fdefault.aspx".  Note that this is an entry in the Parameters collection on the responseMessage and not part of any QueryString.

    If you verify that this is the value for the parameter when you make the call to render the postback page, then you should see the 302 when you get back to the Realm page.  And you can turn validation back on for your pages.

    • Marked as answer by scott_m Tuesday, December 22, 2009 8:44 PM
    Thursday, December 03, 2009 11:06 PM
  • Hi Dominick,

    I got the same error when working with WCF Data Service and STS. In my case, the RP is a WCF Data Service hosted in web application. How can i set the validateRequest property in this case? Since we will not be having any page, only a service, what is the work around in this case?

    Thanks in advance,

    Regards,

    Karim

    Friday, May 07, 2010 6:19 PM
  • Have you tried configuring the <pages validateRequest="false" /> in web.config as described here: http://www.asp.net/learn/whitepapers/request-validation?

    Vani.

    Wednesday, May 12, 2010 9:18 PM
    Moderator
  • In the latest WIF SDK for .NET 4.0 the templates now generate a custom RequestValidator to handle this:

    public class WsFederationRequstValidator : RequestValidator
    {
      protected override bool IsValidRequestString(HttpContext context, 
                              string value, 
                              RequestValidationSource requestValidationSource, 
                              string collectionKey, 
                              out int validationFailureIndex)
      {
        validationFailureIndex = 0;
        if (requestValidationSource == RequestValidationSource.Form &&
          collectionKey.Equals(WSFederationConstants.Parameters.Result, StringComparison.Ordinal))
        {
          if (WSFederationMessage.CreateFromFormPost(context.Request) as SignInResponseMessage != null)
          {
            return true;
          }
        }
    
        return base.IsValidRequestString(context, 
                          value, 
                          requestValidationSource, 
                          collectionKey, 
                          out validationFailureIndex);
      }
    }
    

    In the web.config add the following:

    <httpRuntime requestValidationType="WsFederationRequstValidator" />
    That should solve it.

    • Proposed as answer by agonzalest Thursday, June 24, 2010 9:36 PM
    • Marked as answer by scott_m Friday, June 25, 2010 12:41 AM
    Monday, June 14, 2010 8:41 PM
  • In the latest WIF SDK for .NET 4.0 the templates now generate a custom RequestValidator to handle this:

    <httpRuntime requestValidationType="WsFederationRequstValidator" />
    
    That should solve it.

    Note, in 4.5, SignIn request validation changes slightly.   Please see..

    WIF SIgnIn Request Validation in .NET 4.5

    • Marked as answer by scott_m Friday, January 25, 2013 3:06 AM
    Friday, January 25, 2013 3:06 AM
  • If you continue to have this issue in the RTW version of WIF, you should check the following sequence using Fiddler or an equivelant tool:

    When the STS posts back to the RP, it will do so with the dangerous parameters that trigger this error.  However, the FAM should catch those parameters and then redirect back to the original RP page - without the offending form values.  If you do not see a 302 in the return sequence, then this redirect failed and the form was posted back to your RP page.  So, if all is working correctly, you should see a 302 to redirect to your STS, whatever pages you process in your STS, then when returning back to the RP, you should see a 302 at the Realm (this parameter is configured in your Web.Config), where the FAM is processing the dangerous post and creating the WIF cookie.  Once the FAM completes, you should end up at the originally requested page.

    If the correct thing is happening, you do not have to turn of FormValidation!

    If you find that there is no redirect and you are coming back to your realm page, and you have to turn off FormValidation to make it work, check the following:

    When the FAM creates a redirect to the STS, it will add several parameters to the query string.  These parameters include wrealm and wctx.  The wrealm is used by the call to FederatedPassiveSecurityTokenServiceOperations.ProcessSignInResponse to create the target for the redirect.  The wctx parameter is used to redirect from the realm page to the originally requested page.  Because this wctx parameter is quite complex, it is easy to mangle it as you go through the STS.

    Your STS will need to preserve the original query string that was sent by the FAM for the call to the creation of the SignInRequestMessage.  How you preserve this string can have a profound effect on the behavior when you return to the RP.  The original wctx parameter is a UrlEncoded set of parameters which must be sent back correctly encoded as a single value.  Once UrlDecoded, they appear to be separate parameters (with names like id and ru).

    In order to preserve the original set of parameters, you can walk the Request.QueryString and save off the values.  Then pass them around as necessary and fold them back together again when returning to the RP.  At the point that the responseMessage is fed to the FederatedPassiveSecurityTokenServiceOperations.ProcessSignInResponse function, the wctx message should be intact and look similar to "rm=0&id=passive&ru=%252fClaimsEnableWebSiteEx01%252fdefault.aspx".  Note that this is an entry in the Parameters collection on the responseMessage and not part of any QueryString.

    If you verify that this is the value for the parameter when you make the call to render the postback page, then you should see the 302 when you get back to the Realm page.  And you can turn validation back on for your pages.

    Great Point!

    I had similar issue when my asp.net web had  no managed default web page (typically default.aspx).  In IIS, the saml token post is done to the app root which causes IIS to try to server up a default page event though it may not be the final destination page.  In my case the default page for the app was default.html.  This enlists the native file handler which disallows HTTP post.    Changed my default page to default.aspx which caused IIS to allow my http post.  Once the http post of the SAML token was allowed the subsequent redirect worked fine (no required validation disabling needed).  I dont think this is documented very well in WIF so be aware.


    • Edited by scott_m Saturday, June 15, 2013 1:48 AM
    Saturday, June 15, 2013 1:47 AM