Reputation: 510
I'm trying to figure out how to implement a replay attack detection mechanism with WCF in a web farm scenario.
WCF provides such detection mechanism by using a nonce cache. Correct me if I'm wrong, but the only way to ensure to prevent this attack in a message security and web farm scenario is by using a nonce cache shared across the servers.
In WSE3.0, it used to be possible to provide nonce cache custom implementations
http://msdn.microsoft.com/en-us/library/ff647945.aspx
but there doesn't seem to be any way to do so in WCF (No configuration options, besides I found with Reflector that the NonceCache class is marked as both sealed and internal..)
Any thoughts?
Upvotes: 24
Views: 801
Reputation: 740
Time passes....10 years later...
WCF 4.5 and above, there appears to be a solution. They've added an extensibility point. But there is virtually no information on it. The official documentation states here preventing-replay-attacks-when-a-wcf-service-is-hosted-in-a-web-farm that
To mitigate this scenario WCF 4.5 provides an extensibility point that allows you to implement your own shared NONCE cache by deriving a class from the abstract class NonceCache
The source code for the class that consumes this NonceCache seems to be here
I'm still looking at implementing this but in the complete absence of information about this on the internet, I thought I'd make a note here in case I never return.
Why is this such an underused feature? Anyone serious enough to be implementing anti-replay attacks in WCF is going to have multiple servers behind a load balancer. The out of the box implementation just won't work, as commonly it will allow a round-robin of the servers to accept N replay attacks before rejection begins. As a side effect this actually leaks the number of server's to your attacker. I'm genuinely confused. Is there another defense everyone is using? Is everyone going sticky sessions [shudder]?
Upvotes: 0
Reputation: 186
Firstly there are no silver bullets for this. Each option has its drawbacks. Microsoft recommends one of two options:
While securing your service using transport-level security will protect from the man in the middle scenario it will not protect you against a compromised client. So in effect it's not a robust solution and using stateful security context tokens is the better way of the two. This does require some considerations when developing and deploying.
As I stated in my earlier answer there no silver bullets for this. Here is another option (which you may have already considered) by using detectReplays, maxClockSkew, replayWindow, and replayCacheSize settings. Although I'm not sure about its robustness in a WebFarm scenario it should work given the underlying operation of WCF. Here's a brief article that demonstrates it. The drawback with this option is when you have a client in a different timezone to the server you'll get failures if your maxClockSkew is not set to allow for the timezone differences.
Upvotes: 1