Web applications are built on the stateless HTTP protocol, so session management is an application-level responsibility. Session security is critical to the overall security of an application.
Top session management threats include:
A session hijacking attack occurs when an attacker uses network monitoring software to capture the authentication token (often a cookie) used to represent a user’s session with an application. With the captured cookie, the attacker can spoof the user’s session and gain access to the application. The attacker has the same level of privileges as the legitimate user.
Countermeasures to prevent session hijacking include:
● Use SSL to create a secure communication channel and only pass the authentication cookie over an HTTPS connection.
● Implement logout functionality to allow a user to end a session that forces authentication if another session is started.
● Make sure you limit the expiration period on the session cookie if you do not use SSL. Although this does not prevent session hijacking, it reduces the time window available to the attacker.
Session replay occurs when a user’s session token is intercepted and submitted by an attacker to bypass the authentication mechanism. For example, if the session token is in plaintext in a cookie or URL, an attacker can sniff it. The attacker then posts a request using the hijacked session token.
Countermeasures to help address the threat of session replay include:
● Re-authenticate when performing critical functions. For example, prior to performing a monetary transfer in a banking application, make the user supply the account password again.
● Expire sessions appropriately, including all cookies and session tokens.
● Create a “do not remember me” option to allow no session data to be stored on the client.
Man in the Middle Attacks
A man in the middle attack occurs when the attacker intercepts messages sent between you and your intended recipient. The attacker then changes your message and sends it to the original recipient. The recipient receives the message, sees that it came from you, and acts on it. When the recipient sends a message back to you, the attacker intercepts it, alters it, and returns it to you. You and your recipient never know that you have been attacked.
Any network request involving client-server communication, including Web requests, Distributed Component Object Model (DCOM) requests, and calls to remote components and Web services, are subject to man in the middle attacks.
Countermeasures to prevent man in the middle attacks include:
● Use cryptography. If you encrypt the data before transmitting it, the attacker can still intercept it but cannot read it or alter it. If the attacker cannot read it, he or she cannot know which parts to alter. If the attacker blindly modifies your encrypted message, then the original recipient is unable to successfully decrypt it and, as a result, knows that it has been tampered with.
● Use Hashed Message Authentication Codes (HMACs). If an attacker alters the message, the recalculation of the HMAC at the recipient fails and the data can be rejected as invalid.