Friday, January 8, 2010

Replay attacks in Wcf


One important attack against web services is a "replay attack": a malicious man-in-the-middle captures a valid message from a client to a server and resends it. This can cause duplicate transactions or denial of service (DOS).

Typically the way to protect here is to have a timestamp on the message and some expiration policy on the server. This is a very simplified description though, here are all the details.

The sending party attaches this timestamp to the SOAP message:


The receiving party can then decide based on some policy how much after the message was created it is suspected as a replay.

But what is this service policy? We can see an "expires" element in the client message itself, then why does the service need an additional policy?

The answer is that there is a duplicate protection against replay attacks. The client can decide its own policy and express it inside the message. The server should respect this policy and also adds its own policy. For example:

  • Client sends a message in 15:00

  • Client expiration policy is set to 15:05

  • Service gets the message in 15:06

  • Service expiration policy is set to 15:07

  • In this case the message is considered valid by the service, but the service is expected to respect the client policy and reject the message. the situation gets more interesting when we add real network latency and clocks synchronization into the picture.

    In Wcf there are two somehow confusing settings to control the expiration:

  • LocalServiceSecuritySettings.ReplayWindow - The service expiration policy.

  • LocalclientSecuritySettings.TimestampValidityDuration - The client expiration policy as expressed in the message itself.

  • There are various other settings which relate to tolerance for clock differences and I will write a separate post on them some other time.


    What's next? get this blog rss updates or register for mail updates!