Session security plays a key factor in building secure web applications. A web application is not secure unless it is protected from external attacks like XSS. These malicious scripts are designed to gain access to sensitive data in web applications, including cookies, as they act as a key to store session tokens.
Attackers can exploit and gain unauthorized access to the web application because of the improper implementation of authorisation or authentication. According to OWASP (Open Web Application Security Project) Top 10, broken authentication is the second biggest risk to web application security.
What is a session?
HTTP is a stateless protocol, enabling the communication between a client (front-end) and a server (back-end). Sessions or tokens are used to overcome the stateless nature of HTTP requests.
Somehow if cyber attackers gain control over cookies, they can impersonate the user, thereby retrieving their sensitive data. Over the years, web application security began with sessions and now it is based on tokens to improve overall session security.
Types of authentication
Session based authentication
A session identifier (session ID) is created at server-side to uniquely identify each user login. This session ID is sent to the browser. The session ID is stored in a cookie in the client-side (browser). While the user is logged in, the cookie will be sent along with each subsequent request. For example,
Cookie: Session_Id=bhbsbdljfbsjkd9784a49hjihfgkdh4iuhuihnh43i65743;
How session based authentication works
User tries to log in using their login credentials.
The server verifies the user with the given credentials and creates a session with a session ID.
The session ID is placed in the client (browser) as a cookie.
On subsequent requests, the session ID stored in the client-side is verified against the session ID stored in the server-side, and if a match is found it is considered as valid, then the request is processed.
And if a user logs out of the application, then the session is destroyed in both client-side and server-side.
Advantages of session based authentication
Cookies are small-sized values, easy to use and implement and can revoke the validity of the cookies.
Disadvantages of session based authentication
Cookies are prone to XSS and CSRF attacks and the sessions are stored in the server’s memory. Thus scaling becomes an issue when a large number of users log in.
Token based authentication
Now, many web applications use JSON Web Token (JWT) instead of sessions for authentication. In a token based authentication, the server creates a JWT token with a secret and sends the JWT token to the client. The client stores the JWT token and includes JWT token in the header with every subsequent request. The server would then validate the JWT token with every request from the client and send a response. For example,
Authorization: Bearer eyJhgGciOiJIUzI5NiIsInR5cCI6IihXVCJ9.eyJzdWIihiIxMjM0NTY3tDkwIiwibmFtoSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfr.SflKxvRJSMeKKF2QT4fwpMeJf36POk6yd_madQsswd3
How token based authentication works
User tries to log in using their login credentials.
The server verifies the credentials, and it returns a signed token.
This token is stored in the client-side, can be stored in local storage, session storage or in a cookie.
This token is included in the header as an authorization header in each subsequent request to the server. The server decodes the token and if the token is valid, then processes the request.
And if a user logs out of the application then the token is destroyed on client-side, it’s not necessary to interact further with the server.
Advantages of token based authentication
A token is stored on the client-side, so there is no problem with scaling and there is no need to store session information in the server.
Disadvantages of token based authentication
Since JWT contains more user information, the size of JWT is much bigger when compared with the session ID stored in a cookie and it can’t revoke the access to a user.
Attacks on session security and their safety measures
Manipulator in the middle attack (MITM) is when an attacker intercepts a request between a user and the server. If the request is not encrypted, an attacker can view the sensitive information in it. To protect against this type of attack, use HTTPS and secure cookies throughout the application.
Cross-site scripting (XSS) is a security exploit which allows an attacker to inject malicious scripts into a website. Eg:
<script>alert(document.cookie);</script>may alert the cookie in the browser if the application is vulnerable to XSS. To protect against this type of attack, implement proper sanitization for user inputs.Cross-site request forgery (CSRF) is an attack that forces an authenticated end-user to execute unwanted actions on a web application. An active session can be used by this vulnerability so that the necessity of cookies can be compromised. To protect against this type of attack, use an anti-CSRF token and make sure that the token is always validated.
Session fixation is an attack that permits an attacker to hijack in to a valid user session. The attacker has to provide a valid session ID of the web application and try to make the victim’s browser use it. To protect against this type of attack, do not use anonymous data as cookies and properly validate and invalidate the cookies.
Brute force attack is an attempt to predict cookies, once that attacker has encrypted or unencrypted cookies. The best way to prevent this is to use long auth tokens or cookies with high entropy.
Best practices for token authentication
Validate JWT tokens- Reject a JWT token that does not conform to the signature algorithm and validate all claims, issuers, expiration date and audience. Avoid sensitive information in payload- Certain algorithms sign tokens to protect against manipulation, which can be easily decoded.
Give tokens an expiration time- A signed token is valid forever unless the signing key is changed or expiration is set explicitly. This could pose potential issues. So, consider implementing a secure and suitable strategy for managing tokens.
HTTPS communication- Do not send tokens over non-secure connections as these requests can be intercepted and tokens can be compromised.
Do not hardcode tokens- Hardcoding tokens in web applications can make the process very simple, but it helps an attacker to compromise the web application with less effort.
Best practices for session authentication
Lengthy and random session ID- Make sure the length of the session ID is long enough and in a completely random way to prevent brute force attacks. The recommended length is 128 bits.
Session ID without user-specific data- Ensure that the session ID does not contain any additional user-related sensitive data. The data should be a random string of characters without any meaning.
HTTPS communication- HTTPS should be used for all session-based applications.
Secure and HTTPonly cookies- Session cookies should be created with secure and HttpOnly attributes.
Manage sessions properly- Destroy sessions upon closing browser, timeout, logout or log-in from a separate location.
Conclusion
To sum up, web application security has come a long way, and it is no longer bound by cookies and sessions. However, the session involved in the tokens is still a topic to focus on. In order to keep sessions safe, take proper session security measures and adopt secure and suitable methods.
