It's my pleasure to have my first guest post. This post is by none other than @7hunderSon. This post started after a couple of discussions were had on The Many Hats Club Discord chat room on the topic of server side vs client side session management. This presented a great opportunity to have ThunderSon write a post with some collaboration and input from myself.  

A bit of an introduction to ThunderSon from themselves:

I have been part of the community for around 2 years. I gained a lot of interest in web application penetration testing. This led to me taking interest in Application Security and ways to help developers secure their applications.

Guest Post - @7hunderSon

As I was going through an engagement, I came across a web application that was using local storage (LS) in order to store some PII for the user logged in. It was the first time for me to see such an implementation. I decided to see how bad it is, what’s the good in it, and what is the competition. After reading the blogs already available, I decided to write the following blog with @SeanWrightSec.

Client Side Management (Local Storage)

LS is a mechanism that lives inside a browser. Since it is implemented in the browser, the way to access and modify it is by using JavaScript (JS). Saying that, this opens up doors for session hijacking using XSS.

This was refuted in other blogs that were pushing for LS vs Cookies by stating that `If you have XSS, session stealing is a minimal risk compared to other issues`. This statement doesn’t mean that the session issue should be ignored! This is a case in the threat model and it needs to be tackled!

The good part of this story is that by using JS, the developer can instruct the application to send the session only when need be, and not on every request which reduces the attack surface. This effectively eliminates the possibility of Cross Site Request Forgery (CSRF) based attacks.

Another crucial point for using local storage is for storing non-critical data in the browser, which improves the performance by a couple of milliseconds in the flow of the application and that results in a better UX overall. It is also worth noting that since the data is held in the client, this makes it prone to tampering, so additional checks need to be performed on the data to ensure that it has not been tampered with.

The last bit, which has the highest impact on LS, is that LS doesn’t have an expiry, and that it is controlled on the client side. This will strip the developer from revoking or renewing session unless they send the control bits to the client. However, there is also Session Storage which will only store the data for the duration of the browser session, the data will be wiped when the session is no longer available (such as when the browser has been closed).

Moving to the other side, Cookies come to rescue the web application from some of the major pitfalls of LS.

Server Side Management (Cookies)

Since cookies are a simple header field, the maximum data it can store is 4KB. This is a good enforcing mechanism that instructs the developer not to store any data other than the session in the cookies. Any additional data will be accessed by using that user’s cookies.

The other downfall, other than having limited storage, is that cookies are attached to every request sent by the browser to the server. This characteristic of them make the site potentially vulnerable to CSRF based attacks. Intuitively, this increases the attack surface for the attacker. However, there is a relatively new attribute which has been introduced to combat this, the SameSite attribute.

Unlike LS, cookies can have the HttpOnly attribute, which denies JS access to the cookies and prevents XSS attacks to gain direct access to them. This allows the developer to circumvent a case in their threat model.

And last, cookies are managed server side. This gives the developer full power over what happens to that session which allows them to properly take action in case a data breach occurs or any incident that would force the developer to revoke all sessions alive. The expiry time is as well denoted by the developer. This also means that potentially sensitive or critical information is never transmitted to the client and will always reside on the server.

Summary  

Pros Local Storage:

1.     Can hold up to 5MB.

2.     The developer controls on which requests the session is sent in.

3.     Client Side Managed.

Cons Local Storage:

1.     Can be accessed through JS.

2.     Doesn't have an expiry (Session Storage expires once session has expired though).

Pros Cookies:

1.     Can be made inaccessible to JS.

2.     Server Side Managed.

3.     Has an expiry and can be mass revoked.

Cons Cookies:

1.     Can hold up to 4KB. Main usage is for session IDs.

2.     Is sent on every request to the server.

Future posts will be posted which will go into further depth about some of the concepts discussed in this post as well as cover other related topics.