Session Hacking | Session Management Attacks | The Basics

So we are here to discus one more topic related to web application hacking, that is session hacking. Note that session hijacking and session hacking are closely related terms but are slightly different. In session hacking application level attacks are concerned where as in session hijacking application level attack as well as TCP/IP level attacks are covered. Session hacking in other terms can also be called as Session Management Attack. So here I must clear we are discussing session hacking not session hijacking. People with confusion in session hacking and session hijacking should read this post carefully I hope that would help them clear up their confusion.

So first of all what is session, session can be termed as an entity which is responsible for handling your state over internet like whether you are logged in or not or which item you have added to your cart while shopping etc. And most common and well known method known for managing sessions are cookies.

Web applications become vulnerable to session hacking due to improper generation and mishandling of cookies while undergoing process. The data that is passed as cookie is known as token so in fact we can say that weak token generation methods and weakness in handling them is main reason for session getting hacked.

What are common weak token generation methods ?

One of the most common mistake many new web developers make is they design tokens to be meaningful. That means most likely the token is created from user-name, password, email id, telephone or mobile number, country, region, time and similar information about logged user. And if token does not include password there is 100% chance that hacker can log in as any user he/she wants since all other information is readily available in user's profile to create a new legal tokens as cookie values.

Next weak token generation method may include generation of token value that is predictable. Predictable token can be generated in several ways for example creating a pattern to generate token, using only hexadecimal values, using known token generation methods, using hidden sequences while generating tokens.

Lastly creating a session token which is fully time independent or fully time dependent. One of the biggest mistake that can be done while creating tokens for handling session. In fact many experienced hackers might even crack token generated using this method in few minutes. It's never a good idea to use this method for generating tokens.

What are common token mishandling methods ?

The very first in list is coding for cookies in improper way to work in LAN network.

Next is appearance of tokens in session logs and URL.

And third is storing cookies in wrong way.

Lastly thinking that we have implemented SSL means we are secure to session related attacks.

A session token vulnerable to attack means complete session is vulnerable to attack. Underestimating session handling can prove to be serious. So here we end up with basics of session hacking in next post we will have our look on how to perform session hacking attack against weak cookie generation and then in next post to it how to perform attacks on token mishandling methods and lastly how to perform hacked session CSRF attack. Till then thanks for reading, have a nice time and keep visiting.

Session Management Attacks Countermeasure

From last few posts we are discussing session hacking or we can say attacks against session management. So after having a small look over session hacking and some of its regular types its time to have a look on its countermeasures. Same as any other web application countermeasures session hacking countermeasures also depend upon type of application and its implementation or you can say type of vulnerability a web application can suffer from. In this following post we will discuss some preventive measures which can be practically implemented over any web application against session hacking.

Generating Strong Tokens:

Following are some tips to generate strong tokens for protecting sessions against predictable token vulnerability.

• Use large value for token.
• Check each value for randomness before implementing in session management.
• Make sure token's complexity can't be broken using brute force, so use real large values with possible random characters.
• Never use weak hashes, hexadecimal values, octal values or something like that which generates predictable values for token generation.
• Don't use time dependent variables to generate token.
• Tokens should consist of nothing more than an identifier used by the server to locate the relevant session object to be used for processing the user’s request and make sure there should be enough number of tokens so that it should not be easy for anyone to attack.
• Token generation method should be different for each token.

Now information that can be used to generate tokens,

• IP address of user.
• Port number from which user sent request.
• User's browser protocol or User Agent details.
• Absolute time of request in milliseconds.

Now why above things can be used for generating tokens though they can be predictable. The reason is we are not actually advising you to use any one of them we are advising you to use each of them, by doing so you'll be able to generate a token which will be highly unpredictable and due to time of request you can manage to terminate session after some specific interval of time.

Protecting Tokens From Mishandling:

Following are some measures that should be taken on behalf of developer against mishandling of tokens.

• All tokens should be passed from HTTPS and not from HTTP.
• A page must not use HTTPS and HTTP simultaneously.
• If possible all pages should be implemented using HTTPS including static and help pages. Use HTTPS for all pages rather than switching from HTTP to HTTPS for specific pages since it can act as vulnerability which can help attacker to steal session.
• Session log should never be transmitted in URL.
• Session token should die after some specific interval of time (10 min - 1 hour not more).
• If remember me function is enabled a user must be notified about with how many computers he/she has stored session and whether he/she wants to remove it or not. To get an idea implementation visit http://shetoldme.com.
• A user can't be allowed to login from two computers at the same time.
• The domain and path scope of an application’s session cookies should be set as restrictively as possible.
• A site should be checked for XSS and CSRF attacks which can help an attacker attack session.

To protect users in LAN environment the Network admin should implement SniffJoke. SniffJoke is Linux based anti-sniffing technology developed by Delirandom, for download and more information visit http://www.delirandom.net . You can implement any anti-sniffing technology but we are recommending SniffJoke because its free and open so you can not only download and use it but can also modify according to your needs.

So here we end countermeasure against session management attacks. Thanks for reading, have a nice time and keep visiting.