Input/Data Validation

• How do I implement input and data validation in WCF?
• What is schema validation?
• What is parameter validation?
• Should I validate before or after message serialization?
• How do I protect my service from denial of service (DoS) attacks?
• How do I protect my service from malicious input attacks?
• How do I protect my service from malformed messages?

How do I implement input and data validation in WCF?

If you need to validate operations that do not accept message or data contracts, use parameter inspectors. Parameter inspectors provide a convenient mechanism to process service method invocations when they are in a parameterized form. Parameter inspectors allow pre- and post-processing of messages through the use of custom validators. Unlike using a schema for validation, a custom validator requires you to write your own custom validation code.

If your service has operations that accept message or data contracts, use schemas to validate your messages. Message validation provides a way to validate messages when operations consume message contracts or data contracts that are not possible to validate using parameter validation. Message validation allows the creation of validation logic inside the schemas, thereby providing more flexibility and reducing development time. Schema validation occurs before serialization or encryption of the message. In order to reduce development time, you can start by using the service.xsd schema file that is generated when you add a service reference to your client.

What is schema validation?

Schema validation allows you to validate incoming messages against a set of configurable Extensible Markup Language (XML) schema documents.

Schema validation is implemented in WCF using message inspectors. Client message inspectors implement the IClientMessageInspector interface, while service message inspectors implement the IDispatchMessageInspector interface.

The following steps show you how to perform message validation using schemas:

1. Use the schema.xsd schema file that is created by svcutil.exe when you add a service reference or create a schema that represents the operations of your service and the types consumed by those operations.
2. Create a .NET class that implements a custom client message inspector and custom dispatcher message inspector to validate the messages sent and received by the service.
3. Implement a custom endpoint behavior to enable message validation on both the client and the service.
4. Implement a custom configuration element on the class that allows you to expose the extended custom endpoint behavior in the configuration file of the service or the client.

Additional Resources

• For more information, see Message Inspectors.

What is parameter validation?

Parameter validation allows you to inspect and validate incoming or outgoing message parameters.

You can inspect or modify the incoming or outgoing messages for a single operation on a WCF client object or WCF service by implementing the System.ServiceModel.Dispatcher.IParameterInspector interface and inserting it into the client or service run time.

public class Validation
{
       public class ValidationParameterInspector : IParameterInspector
        {
            public void AfterCall(string operationName, object[] outputs, object returnValue, object correlationState)
            { … }


public object BeforeCall(string operationName, object[] inputs)
            { …    }
…
}

Additional Resources

• For more information, see How to: Inspect or Modify Parameters.

Should I validate before or after message serialization?

When performing schema validation, you will validate before deserialization because you are validating on the message itself. When performing parameter validation, you will validate after deserialization because you are validating data parameters within the message.

Additional Resources

• For more information, see How to: Inspect or Modify Parameters.

How do I protect my service from denial of service (DoS) attacks?

Configure your service with the ServiceThrottlingBehavior class to limit concurrent client calls, instances, and sessions.

The following example configures the service behavior for serviceThrottling. The three service throttling behavior attributes are described below.

    <behaviors>
      <serviceBehaviors>
        <behavior name="Throttled">
          <serviceThrottling 
            maxConcurrentCalls="1" 
            maxConcurrentSessions="1" 
            maxConcurrentInstances="1"
          />
          <serviceMetadata 
            httpGetEnabled="true" 
            httpGetUrl=""
          />
        </behavior>
      </serviceBehaviors>
    </behaviors>

• MaxConcurrentCalls gets or sets a value that specifies the maximum number of messages actively processing across a ServiceHost object.
• MaxConcurrentInstances gets or sets a value that specifies the maximum number of InstanceContext objects in the service that can execute at one time.
• MaxConcurrentSessions gets or sets a value that specifies the maximum number of sessions a ServiceHost object can accept at one time.

How do I protect my service from malicious input attacks?

Check for known good data and constrain input by validating it for type, length, format, and range. Do not trust any input. An attacker passing malicious input can attempt SQL injection, cross-site scripting, and other injection attacks that aim to exploit your application's vulnerabilities. If your service has operations that accept message or data contracts, use schemas to validate your messages. If you need to validate operations that do not accept message or data contracts, use parameter inspectors.

How do I protect my service from malformed messages?

WCF catches malformed SOAP messages, and you can log this event with WCF auditing. If the envelope is valid but the message fields are malformed in the sense of length, range, format, or type, you can use schema validation to perform message validation.

To log malformed messages using WCF auditing, set the logMalformedMessages attribute to true in the <messagelogging> element. Malformed message logging allows you to see any messages that were rejected by the WCF stack due to validation errors. This can help you determine if someone is attacking your service with poorly formed SOAP messages.

The following steps briefly show you how to perform message validation using schemas:

1. Use the schema.xsd schema file that is created by svcutil.exe when you add a service reference or create a schema that represents the operations of your service and the types consumed by those operations.
2. Create a .NET class that implements a custom client message inspector and custom dispatcher message inspector to validate the messages sent and received by the service.
3. Implement a custom endpoint behavior to enable message validation on both the client and the service.
4. Implement a custom configuration element on the class that allows you to expose the extended custom endpoint behavior in the configuration file of the service or the client.