다음을 통해 공유


WIF Troubleshooting: A Potentially Dangerous Request.Form Value Was Detected from the Client

Symptoms

While processing an RSTR (Request for Security Token Response), System.Web throws the following exception:

 

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

   at System.Web.HttpRequest.ValidateString(String s, String valueName, String collectionName)

   at System.Web.HttpRequest.ValidateNameValueCollection(NameValueCollection nvc, String collectionName)

   at System.Web.HttpRequest.get_Form()

   at System.Web.HttpRequest.get_HasForm()

   at System.Web.UI.Page.GetCollectionBasedOnMethod(Boolean dontReturnNull)

   at System.Web.UI.Page.DeterminePostBackMode()

   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

   at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

   at System.Web.UI.Page.ProcessRequest()

   at System.Web.UI.Page.ProcessRequest(HttpContext context)

   at ASP.default_aspx.ProcessRequest(HttpContext context)

   at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()

 

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. To allow pages to override application request validation settings, set the requestValidationMode attribute in the httpRuntime configuration section to requestValidationMode="2.0". Example: <httpRuntime requestValidationMode="2.0" />. After setting this value, you can then disable request validation by setting validateRequest="false" in the Page directive or in the <pages> configuration section. However, it is strongly recommended that your application explicitly check all inputs in this case.

 

Cause

The web service was invoked where a parameter included an XML tag:

(wresult="<t:RequestSecurityTo...").

 

Resolution

You can turn off request validation, or you could create a class to handle validation.

 

Turning off validation:

Add the following to your web.config:

<pages validateRequest="false" />

If you are using ASP.NET 4, you will also need the following in the web.config:

<httpRuntime requestValidationMode="2.0" />

 

Creating a class to handle validation

WIF SDK 4.0 provides you with a sample validator you can use for solving the error without giving up the validation. In fact, FedUtil.exe does everything for you if you launch it on a web site (but not for other project types). If you need to do it by hand, you can just add the class:

 

 

//-----------------------------------------------------------------------------
//
// THIS CODE AND INFORMATION IS PROVIDED 'AS IS' WITHOUT WARRANTY OF
// ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO
// THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A
// PARTICULAR PURPOSE.
//
// Copyright (c) Microsoft Corporation. All rights reserved.
//
//
//-----------------------------------------------------------------------------
  
using System;
using System.Web;
using System.Web.Util;
using Microsoft.IdentityModel.Protocols.WSFederation;
 
/// <summary>
/// This SampleRequestValidator validates the wresult parameter of the
/// WS-Federation passive protocol by checking for a SignInResponse message
/// in the form post. The SignInResponse message contents are verified later by
/// the WSFederationPassiveAuthenticationModule or the WIF signin controls.
/// </summary>
  
public class  SampleRequestValidator : RequestValidator
{
    protected override  bool IsValidRequestString( HttpContext context,  string  value, RequestValidationSource requestValidationSource, string collectionKey, out int  validationFailureIndex )
    {
        validationFailureIndex = 0;
  
        if ( requestValidationSource == RequestValidationSource.Form && !String.IsNullOrEmpty( collectionKey ) && collectionKey.Equals( WSFederationConstants.Parameters.Result, StringComparison.Ordinal ) )
        {
            var unvalidatedFormValues = System.Web.Helpers.Validation.Unvalidated(context.Request).Form;
            SignInResponseMessage message = WSFederationMessage.CreateFromNameValueCollection( WSFederationMessage.GetBaseUrl( context.Request.Url ), unvalidatedFormValues ) as SignInResponseMessage;
 
            if ( message != null )
            {
                return true;
            }
        }
 
        return base.IsValidRequestString( context, value, requestValidationSource, collectionKey, out  validationFailureIndex );
    }
}

   

And add the following line in the web.config:

 <httpRuntime requestValidationType="SampleRequestValidator" />

 

More Information

The request validation feature in ASP.NET provides a certain level of default protection against cross-site scripting (XSS) attacks. In previous versions of ASP.NET, request validation was enabled by default. However, it applied only to ASP.NET pages (.aspx files and their class files) and only when those pages were executing.

In ASP.NET 4, by default, request validation is enabled for all requests, because it is enabled before the BeginRequest phase of an HTTP request. As a result, request validation applies to requests for all ASP.NET resources, not just .aspx page requests. This includes requests such as Web service calls and custom HTTP handlers. Request validation is also active when custom HTTP modules are reading the contents of an HTTP request.

As a result, request validation errors might now occur for requests that previously did not trigger errors. To revert to the behavior of the ASP.NET 2.0 request validation feature, add the following setting in the Web.config file:

<httpRuntime requestValidationMode="2.0" />

However, we recommend that you analyze any request validation errors to determine whether existing handlers, modules, or other custom code accesses potentially unsafe HTTP inputs that could be XSS attack vectors.