In a previous blog, we discuss Statelessness of HTTP Protocol due to which we implement session. once authenticated session is established then SESSION ID is temporarily equivalent to
strongest authentication methods such as Username and Password, OTP, Smartcards, Biometrics etc
SESSION ID STRUCTURE:
Session ID sturcture is like "name=value" example: JSESSIONID=21D9189EF4375A7D820B90B3B050500Bour basic goal is to secure session ID
FOR DEVELOPERS:
Developers must remember these points in the generation of Session ID:
SESSION ID NAME:
It should not be descriptive, session ID name like
1. PHPSESSID(PHP),
2. ASP.NET_Sessionid(ASP.NET),
3. JSESSIONID(J2EE) etc
can disclose the technologies and programming languages. Best thing is that if we replace the default session ID name to Generic Name like "id".
SESSION ID LENGTH:
To prevent the BRUTE FORCE attacks length of the Session ID must be long enough. Session ID length must be 128 bits.
SESSION ID UNPREDICTABLE OR RANDOM ENOUGH:
That the attacker can't predict it easily if Session ID has 64 bits entropy (randomness) then it will take at least 292 years to successfully guess a valid session ID, assuming the attacker can try 10,000 guesses per second with 100,000 valid simultaneous session available at any given time.
TIME TAKEN FOR SUCCESSFUL BRUTE FORCE ATTACK |
SESSION ID CONTENT:
This content must be meaningless to prevent information disclosure attacks.
Session ID simply an identifier at Client Side |
METHODS OF PASSING SESSION ID:
There are basically three methods for passing Session ID:
1.In the URL (avoid it)
2.HIDDEN FIELD
3.COOKIES (preferred it)
- Among these three COOKIES is preferred because in that we can set the EXPIRATION date and time of Session ID and some other advance things.
- URL is not used because ID is included in URL and ID can disclose in web browser history, bookmarks etc. which can lead to SESSION FIXATION attack.