We have shared a series of articles on testing and we are very sure that all of you are the testing experts now! What if we tell you that ensuring only the application accuracy and performance are not enough? How about the “application security” piece?
Yes, that’s right! In the next few articles, we’ll be sharing the list of basic security functional testing that anyone (be it developers, quality engineers, project managers, and even designers) can do as early as during the development phase. Read through our articles, go back and check your application, and…
(We’re kidding about the last frame. Please don’t use a knife/gun okay~ 😂)
For this article, we’ll be looking at the areas to test and check for stateful sessions.
Note: We won’t be covering the security theory in-depth. Please read up here if you wish to know more.
Test #1: All tokens are stored in the browser cookies
After a user has signed in to the application, there would typically be a session token and a CSRF token generated. All tokens should not be in clear-text and should be stored in the browser cookies.
On top of that, check for the following in the browser cookies:
- there is an expiration period (a.k.a time-to-live) for all tokens
- the ‘Secure’ flag is set for all tokens
- the session token has the ‘HttpOnly’ flag set
Test #2: Session tokens are always unique
A session token uniquely identifies a user who is logged on to the application. It should be newly generated each time the user logs in and should have an expiration period (see the point above). This is to prevent other users from performing actions, be it accidental or malicious, using the original user’s token.
How you can check:
- Login to the application > Open browser console > Copy the session token to a text file
- Re-login to the application > Copy the new session token
- Both the old and new session tokens should not be the same
Test #3: Application checks the validity of the session token
Once this session token has been tampered with, invalidated, or expired, the recommended behaviour is that the application should log the user out.
How you can check:
- Open the browser console (right click on your browser > Inspect)
- Expand on the ‘Cookies’ under ‘Storage’ section in the ‘Application’ tab
- Identify the session token and copy the value
- Paste this value somewhere (in text file or something)
- Overwrite the session token value in the web browser with some random value
- Try triggering an API call from the application
- The user should be logged out from the application
Test #4: Concurrent/simultaneous sessions are disallowed
This is the system owner’s decision to decide if concurrent (active) sessions by the same user are allowed (regardless of the IP addresses).
If the decision is to disallow concurrent (active) session, then the application must terminate the first session the moment the second session (by the same user) starts so as to reduce the chances for attackers to obtain session details from any abandoned user session.
Of course, you can add a user-friendly message to inform the user (in the first session) that another active session is ongoing and thus this session will be ended.
If the decision is to allow concurrent (active) session, then the application must have ways to inform the user about the other active sessions (i.e. showing the login IP address, login date and time of all the active sessions) and allow the user to manually terminate the sessions remotely. Here’s an example (from Google) of how it looks like:
Test #5: Session token is invalidated and removed from browser cookies upon logout
As mentioned in Test #1, each token should have a time-to-live (TTL) and must be invalidated when its TTL is met. When users sign out from the application, the tokens must also be invalidated and removed from the browser cookies. Here are the three scenarios in which users are considered signing out of the application:
As scenarios (a) and (b) are self-explanatory and straightforward, we’ll only be talking about the inactive session (a.k.a idle timeout) scenario, which often gets overlooked.
Other than tracking the session token TTL, the application should also keep track of the session inactivity (or session idle) timeout period.
The session inactivity (or session idle) timeout period refers to the time period in which a session will remain active when there is no activity (i.e. no calling of HTTP request) happening in the session.
This inactivity timeout period is recommended to be less than or equals to the session token’s TTL.
How you can check for ( c ):
- Login to the application and idles at the landing page
- Trigger a HTTP request from the application after X* minutes of inactivity
*X = max. session inactivity timeout period + 1
- The application should log the user out (i.e. bring the user back to the Login screen)
We hope that this article will help everyone identify any potential security loopholes early! It would be ideal if someone in the product team, after reading this article, is able to start thinking and triggering discussions about the potential security loopholes for each user story during sprint planning.
Oh! Just in case you didn’t finish reading the article, here’s the checklist (you’re welcome~):
Ensuring the security of an application is and should be everyone’s responsibility! Let’s all do our part in keeping our applications safe and secure~