Threats

• Messages may traverse untrusted intermediaries on an insecure network – any of whom could capture the message and resend the message to the service.
• A replayed message will often cause data inconsistencies (especially true of update operations)

Vulnerabilities

• Limited support for preventing replayed messages
• Many replay caches do not support web farms - meaning that a replayed message could be sent to a separate server in a farm and defeat an in-memory replay cache.

Countermeasures

• Cache a unique identifier for incoming messages, and use message replay detection to identify and reject messages that match an entry in the replay detection cache.
• See the Message Replay Detection Design Pattern for a detailed analysis of detecting replayed web service messages:
  • http://msdn.microsoft.com/practices/default.aspx?pull=/library/en-us/dnpag2/html/wss_ch5_msgreplaydet.asp 
• See the Implementing Message Replay Detection Design Pattern for information on how to implement this pattern using Microsoft WSE 3.0
  • http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/wss_ch5_msgreplaydet.asp 
• We also have a quickstart for this pattern available on our GotDotNet workspace - see http://practices.gotdotnet.com/projects/sopatterns