Configuration Management

patterns & practices Developer Center

Follow these guidelines to avoid introducing vulnerabilities when you configure your WCF application:

Each of these guidelines is described in the following sections.

Use replay detection to protect against message replay attacks

Use the WCF replay detection feature to protect your service against message replay attacks. A message replay attack occurs when an attacker copies a stream of messages between two parties and replays the stream to one or more of the parties. Unless mitigated, the computers subject to the attack will process the stream as legitimate messages, resulting in a range of harmful consequences including unauthorized access to the service.

To enable replay detection in your service

  1. Create a customBinding Element.
  2. Create a <security> element.
  3. Create a localClientSettings element or localServiceSettings element.
  4. Set the following attribute values, as appropriate: detectReplays, maxClockSkew, replayWindow, and replayCacheSize. The following example sets the attributes of both a <localServiceSettings> and a <localClientSettings> element:
      <binding name="NewBinding0">
       <textMessageEncoding />
          replayWindow="00:03:00" />
          replayWindow="00:03:00" />
        <secureConversationBootstrap />
      <httpTransport />

Additional Resources

If you host your service in a Windows service, expose a metadata exchange (mex) binding

If you are hosting your service as a Windows service and are exposing the service by using netTcpBinding, publish the service metadata by creating a mexTcpBinding endpoint so that your clients can discover and use the service. Clients will be able to generate a proxy file by using the ServiceModel Metadata Utility Tool (Svcutil.exe).

Additional Resources

If you don't want to expose your WSDL, turn off httpGetEnabled and remove metadata exchange (mex) endpoints

If you want to block clients from accessing your service's Web Services Description Language (WSDL), you should remove all metadata exchange endpoints and set the httpGetEnabled and httpsGetEnabled attributes to false.

This is potentially important after your clients are built and deployed, if you do not want other clients to discover and use the WCF service. If the metadata is exposed, unwanted clients will be able to generate proxy files (e.g., by using Svcutil.exe) and inspect potentially sensitive methods and parameters offered by the service. If your client programs already have access to the service proxy, set the httpGetEnabled attribute to false.

The following configuration disables sharing service metadata:

<serviceMetadata httpGetEnabled="False" httpsGetEnabled="False"/>

Additional Resources

Encrypt configuration sections that contain sensitive data

Encrypt configuration sections that contain sensitive data such as SQL connection strings. Use the Data Protection API (DPAPI) to encrypt the sensitive data in the configuration file on your WCF server machine.

To encrypt the <connectionStrings> section by using the DPAPI provider with the machine-key store (the default configuration), run the following command from a command window:

aspnet_regiis -pe "connectionStrings" -app "/MachineDPAPI" -prov "DataProtectionConfigurationProvider"

The aspnet_regiis options are:

  • -pe — Specifies the configuration section to encrypt.
  • -app — Specifies your Web application's virtual path. If your application is nested, you need to specify the nested path from the root directory; for example, "/test/aspnet/MachineDPAPI".
  • -prov — Specifies the provider name.
If you need to encrypt configuration file data on multiple servers in a Web farm, use the RSA protected configuration provider because of the ease with which you can export RSA key containers.

Additional Resources