Detecting and Handling Replay Attacks

In Chapter 4, “Protecting an Enterprise WCF Service,” you learned a little about replay attacks. In a replay attack, a hacker intercepts and stores messages flowing over the network and then sends them at some time in the future. At best this can become a nuisance if, for example, a hacker repeatedly replays the same intercepted purchase order sent by a genuine customer to an online bookstore; the bookstore receives hundreds of orders and sends the books to the customer who has not ordered them. At worst, it can lead to large-scale fraud; consider an attacker intercepting a request to credit his bank account and then repeatedly replaying this message to the bank’s servers.

Using reliable sessions can help to mitigate simple replay attacks, as each message must provide a valid sequence identifier and a unique message number. When the session has completed, the sequence identifier becomes invalid, so any subsequent attempt to replay the message should be rejected by the receiver. However, consider the following hypothetical scenario. If a session is long-running, it might be possible for an attacker to edit the <Sequence> block in an intercepted message, modify the message number, set it to some value higher than the message that was received, and then forward this message to the service if the session is still active. When the application hosting the service receives this message, if no message with this number has yet been received, the host will buffer it and then pass it to the service when all the intermediate messages have been received. When a genuine message from the client with this message number is subsequently received, the genuine message will be rejected. How can you handle this situation?

You can use transport-level security to encrypt messages as they traverse the network from machine to machine. Additionally, many implementations of transport-level security include automatic replay detection of packets at the transport layer. But remember that transport-level security operates on a point-to-point basis, and when a service receives the message, it has unrestricted access to its contents. If the service is expected to forward the request on to a service running elsewhere, it can modify the message before it does so. The usual way to protect data, if you cannot trust any intermediate services, is to use message level security. However, message level security is predominantly concerned with protecting the body of a message rather than the data in message headers, which is where the sequence identifiers and message numbers are held.

More Info 

Review Chapter 4 and Chapter 5, “Protecting a WCF Service over the Internet,” for more information about implementing message level security with WCF.

So, to prevent a reply attack, the receiver requires a more secure mechanism than simple sequence identifiers and message numbers for uniquely identifying messages. Fortunately, WCF provides just such a mechanism.

Configuring Replay Detection with WCF

When you enable replay detection, the WCF runtime generates a random, unique, signed, time-stamped identifier for each message. These identifiers are referred to as nonces. On receiving a message, a service can use the signature to verify that the nonce has not been corrupted and extract and examine the timestamp to ascertain that the message was sent reasonably recently (the service can allow for a certain amount of clock-skew between computers and should also recognize that it takes a little time for data to physically traverse the network from the client application). The service can then save the nonce in a cache. When another message is received, the service can retrieve the nonce from the message header. If a matching nonce is found in its cache then this is a copy of an earlier message and should be discarded. If it is not, the message can be processed and its nonce added to the cache.

The WCF security channel implements replay detection by default, although the relevant properties for configuring it are not immediately visible when using the standard WCF bindings. However, it is quite simple to create a custom binding that makes them available. You will adopt this approach in the following exercises.

Create a custom binding for the ShoppingCartService service

1. In Visual Studio 2005, edit the  App.config file for the ShoppingCartHost project by using the WCF Service Configuration Editor.

2. In the left pane, click the Bindings folder. In the right pane, click the New Binding Configuration link. In the Create a New Binding dialog box, select customBinding and then click OK.

   In the right pane, change the Name property to ShoppingCartServiceCustomBindingConfig.

   If you recall from Chapter 2, “Hosting a WCF Service,” the WCF runtime creates a channel stack for sending and receiving messages. Incoming messages arrive at a particular address (such as a port or a URL) using an appropriate transport (such as TCP or HTTP). When you host a service, the WCF runtime “listens” for incoming request messages sent by client applications to the specified address by using a transport channel. Incoming messages pass through the transport channel to an encoding channel, which parses the message, and the WCF runtime can then invoke the relevant operation in the service using the information in this parsed data. Outgoing response messages are encoded by the encoding channel (a message can be encoded as text, or as binary data), before being passed to the transport channel for transmission back to the client application.

   A channel stack must always have at least these two channels: a transport channel and an encoding channel. When you create a new custom binding, the WCF Service Configuration Editor automatically adds elements for using the HTTP transport and text encoding. You have been using the TCP transport in previous exercises in this chapter, so you will change the transport channel.

3. In the lower right pane, select the httpTransport stack element and then click Remove. Click Add. In the Adding Binding Element Extension Sections dialog box, select tcpTransport and then click Add.

   A point worth emphasizing from Chapter 2 is that the order of the channels in the channel stack is important. The transport channel must always be the final item, and it is conventional for the encoding channel to be placed immediately above the transport channel. Verify that the tcpTransport element is in position 2 in the list and the textMessageEncoding element is in position 1. If the positions are different, use the Up and Down buttons to swap them over.

4. Click Add in the lower right pane. In the Adding Binding Element Extension Sections dialog box, select security and then click Add. Use the Up and Down buttons to place the security element in position 1 at the top of the stack, above the textMessageEncoding element.

5. In the left pane, click the security node underneath the ShoppingCartServiceCustomBindingConfig node. In the right pane, set the AuthenticationMode property to SecureConversation. This mode uses the protocol defined by the WS-SecureConversation specification to establish a secure session between the service and client applications (see the sidebar after this exercise for details).

6. In the right pane, click the Service tab. Verify that the DetectReplays property is set to True by default.

7. Examine the ReplayCacheSize property.

   When implementing replay detection, the WCF runtime on the server computer will cache nonces in memory. The value of this property determines the maximum amount of memory it will use, specified as a number of cached nonces. When this limit is reached, the oldest nonce is removed from the cache before a new one is added. The default value should be sufficient, but you might want to consider reducing it if memory is at a premium. However, don’t make it so small that nonces are discarded too quickly as you could render the service vulnerable to replay attacks again.

8. Examine the ReplayWindow and MaxClockSkew properties.

   The ReplayWindow specifies the time for which nonces are considered valid. If the timestamp in a received nonce is outside the time window specified here, it is discarded as being too old. However, WCF recognizes that the system clock on different computers might not be completely synchronized, and the MaxClockSkew property enables you to specify the maximum clock difference to allow. It is also possible that the timestamp for a nonce could appear to be for a short time in the future if the clock on the server computer is running slow, so the MaxClockSkew property allows the service to accept nonces with a future timestamp provided they are within the range specified.

   Note 

   The security custom binding element enables you to configure replay detection for client applications as well, by using the properties in the Client tab.

9. In the left pane, click the ShoppingCartServiceCustomBindingConfig node.

   The ShoppingCartService service uses transactions and reliable sessions, so you must add channels that implement these features:

   • In the lower right pane, click Add. In the Adding Binding Element Extension Sections dialog box, select reliableSession and then click Add.

   • Repeat this process and add the transactionFlow element to the binding.

   • Rearrange the channel stack so that the transactionFlow element is in position 1, the reliableSession element is in position 2, the security element is in position 3, the textMessageEncoding element is in position 4, and the tcpTransport element is in position 5, as shown in the following image. This is the recommended order for these channels:

     

10. In the left pane, expand the ShoppingCartService.ShoppingCartServiceImpl service in the Services folder, right-click the Endpoints folder, and then click New Service Endpoint. In the right pane, set the properties of this endpoint using the values in this table:

    Open table as spreadsheet

    Property	Value
    Name	ShoppingCartServiceCustomEndpoint
    Address	net.tcp://localhost:9090/ShoppingCartService
    Binding	customBinding
    BindingConfiguration	ShoppingCartServiceCustomBindingConfig
    Contract	ShoppingCartService.IShoppingCartService

11. Save the file, and then exit the WCF Configuration Editor.

The WS-SecureConversation Specification

The WS-SecureConversation specification is yet another specification being developed by members of OASIS. It enables two participants (a service and a client application) to establish and share a security context for exchanging multiple messages (a conversation) in a secure and optimal manner without needing to include comprehensive security credential information in every message. Participants exchange and validate credentials at the start of the session, and negotiate security tokens derived from the authorized credentials. Subsequent messages in the conversation contain these derived tokens rather than a complete set of credentials to enable the recipient to authenticate the source. The process of validating these derived tokens is faster than fully authenticating each message from the original set of credentials.

The WS-SecureConversation specification builds on other WS-* specifications, such as WS-Security, so you can create a security context based on a variety of authentication and encryption mechanisms, as described in Chapter 4.

For detailed information about the WS-SecureConversation specification, see the Web Services Secure Conversation Language (WS-SecureConversation) document on the Microsoft Web site at http://msdn.microsoft.com/library/en-us/dnglobspec/html/WS-secureconversation.pdf.

You can now add a corresponding binding to the client application and then configure the client to use this binding.

Create a custom binding for the WCF client application

1. In Visual Studio 2005, edit the  App.config file for the ShoppingCartClient project by using the WCF Service Configuration Editor.

2. In the left pane, add a new customBinding binding configuration to the Bindings folder and set the Name property to ShoppingCartClientCustomBindingConfig.

3. Remove the httpTransport element and replace it with a tcpTransport element.

4. Add a security element. Set the AuthenticationMode property of this security element to SecureConversation.

5. Add a reliableSession and a transactionFlow element to the custom binding.

6. Rearrange the channel stack so that the transactionFlow element is in position 1, the reliableSession element is in position 2, the security element is in position 3, the textMessageEncoding element is in position 4, and the tcpTransport element is in position 5.

7. In the left pane, add a new endpoint to the Endpoints folder under the Client folder. Set the properties for this endpoint using the following values:

   Open table as spreadsheet

   Property	Value
   Name	CustomBinding_ShoppingCartService
   Address	net.tcp://localhost:9090/ShoppingCartService
   Binding	customBinding
   BindingConfiguration	ShoppingCartClientCustomBindingConfig
   Contract	ShoppingCartClient.ShoppingCartService.ShoppingCartService

8. Save the file, and then exit the WCF Configuration Editor.

9. In Visual Studio 2005, edit the  Program.cs file in the ShopingCartClient project. In the Main method, change the statement that creates the proxy object to reference the CustomBinding_ShoppingCartService endpoint, as shown in bold below:

    static void Main(string[] args) {     …     try     {         // Connect to the ShoppingCartService service         ShoppingCartServiceClient proxy = new             ShoppingCartServiceClient("CustomBinding_ShoppingCartService");         …     }     … }

10. Start the solution without debugging. In the ShoppingCartClient console window displaying the message “Press ENTER when the service has started,” press Enter.

    The client application executes exactly as before, except that this time it is using the custom binding, with replay detection enabled, to communicate with the ShoppingCartService service.

11. Press Enter to close the client application console window. In the host application console window, press Enter to stop the service.