What Is a Replay Attack?
A replay attack occurs when a cybercriminal网络罪犯 eavesdrops偷听，窃听 on a secure network communication, 拦截intercepts it, and then fraudulently欺骗地 delays or resends it to misdirect the receiver into doing what the hacker wants. The added danger of replay attacks is that a hacker doesn't even need advanced skills to decrypt a message after capturing it from the network. The attack could be successful simply by resending the whole thing.
How It Works
Consider this real-world example of an attack. A staff member at a company asks for a financial transfer by sending an encrypted message to the company's financial administrator. An attacker eavesdrops on this message, captures it, and is now in a position to resend it. Because it's an authentic message that has simply been resent, the message is already correctly encrypted and looks legitimate合法的 to the financial administrator.
In this scenario, the financial administrator is likely to respond to this new request unless he or she has a good reason to be suspicious. That response could include sending a large sum of money to the attacker's bank account.
Stopping a Replay Attack
Preventing such an attack is all about having the right method of encryption. Encrypted messages carry "keys" within them, and when they're decoded at the end of the transmission, they open the message. In a replay attack, it doesn't matter if the attacker who intercepted the original message can read or decipher破译 the key. All he or she has to do is capture and resend the entire thing — message and key — together.
To counter this possibility, both sender and receiver should establish a completely random session key, which is a type of code that is only valid for one transaction and can't be used again.
Another preventative预防性的 measure for this type of attack is using timestamps on all messages. This prevents hackers from resending messages sent longer ago than a certain length of time, thus reducing the window of opportunity for an attacker to eavesdrop, siphon抽取 off the message, and resend it.
Another method to avoid becoming a victim is to have a password for each transaction that's only used once and discarded. That ensures that even if the message is recorded and resent by an attacker, the encryption code has expired and no longer works.
Sign out user but server side not clear the authenticate session
As you figured out it is a limitation of ASP.NET forms authentication and there is almost nothing to do to invalidate other user sessions. The problem in this case is exacerbated due to the way the authentication ticket is created and maintained. When such a (APS.NET authentication) ticket is created it is only maintained in the cookie. No record or status about this ticket is maintained on the server side including information about expiry after a timeout. All such information is encoded into the ticket. Hence, so long as the user’s ticket is valid i.e. the timeout has not expired the ticket can be stolen and misused. Even restarting Internet Information Services or for that matter the computer can not invalidate the ticket. This issue discovered by Foundstone and reported to Microsoft, has been acknowledged and published by Microsoft in KB Article 900111.
As Microsoft stated if these requirements are met, you can protect your authentication token as much as possible:
- Use SSL by configuring the Web application in Microsoft Internet Information Services. This ensures the forms authentication feature will never issue a cookie over a non-SSL connection.
- Enforce TTL and use absolute expiration instead of sliding expiration.
- Use HttpOnly cookies to ensure that cookies cannot be accessed through client script, reducing the chances of replay attacks.
In the next major version we would like to change default ASP.NET Forms authentication to ASP.NET Identity (Owin) which offers some techniques how to solve the session scenarios.