This project is read-only.
Project Description
Secure your session cookie (and other session-based) cookies for replay attacks using this easy to use ASP.NET HttpModule.
This project is an ASP.NET implementation of the paper "A secure cookie protocol" which can be found here:


Although you configure HttpOnly and Secure, your cookies are still open for replay attacks. This is a serious issue when high security is needed because of the cookies written by ASP.NET or your code are decoupled from any form of authentication or validation.

Most commonly used and "open for attack" cookie is the FormsAuthenticationTicket cookie which is also open for replay attacks, for more information please read: . That is why this module allows you to configure which cookies should be secured. This module also does not require server side state (read paper) allowing it to have a minimal performance impact per request.

The aim of this project is not to deliver a production ready shippable assembly.

3 reasons why you need to incorporate the code yourself in your product/organization:
  1. This code has no dependencies like log4net etc., so the logging is up to you (ofcourse you can easily implement the ILogger interface from the codebase)
  2. This code has (not yet) a pluggable configuration hook, so if you don't like the default way of configuring you can change it very easily (again, I don't want dependencies)
  3. Please incorporate this code in your build including the unit tests, these unit tests allow the next developers to understand what it is solving and why

There is one thing that is not implemented as stated in the paper: including the SSL Session Id in the hash. This has two reasons:
  1. it is not straight forward when hosted in IIS or WAS to retrieve the SSL Session Id
  2. IE and some other browsers renegotiate a new SSL Session Id for each tab while the session cookies are shared
So I decided to replace this with either: the client certificate public key and when this one is not available the client host address. When the client host address is being used, the solution is less secure because the replay attacks are still possible when the client uses a proxy....

File any bugs or improvements, I will be happy to implement them or give you access to the codebase!

Last edited Aug 4, 2010 at 8:33 AM by TimMahy, version 15