Secure Session Management and Cookies

There are many mitigation techniques for deterring a session from being abused by a malicious actor in a Cross Site Scripting (XSS) or Cross Site Request Forgery (CSRF) based attack in the context of a typical layer 7 web app interaction. The core establishment of trust, when a user needs to be authenticated into a web app, can use a myriad of different authentication schemes for which the underlying caching system is heavily reliant on for initial authentication of the end user. Cookies, XSS, and CSRF have a dangerous interconnection in web application security. Cookies provide authentication to the webapp on the clients behalf for future requests, if for example a web application does not properly sanitize the information coming into for the form the user is interacting with for login (as a user case), a bad actor can insert malicious code that will be ran on a user’s machine when they load the page, and can steal their authenticated identity by having the malicious code/script retrieve authenticated cookies from the users browser and send it to the attackers server. This can then be used to alter information such as money transfer, credential changes, etc depending on how the underlying webapp is set up and what API or underlying service the user may be interacting with. Though in hindsight it doesn’t matter as long as the attacker is able to successfully import the cookies information into his local session to interact with the end resources via traditional user means.

In the context of a banking login system, or any online system that authenticates through a login portal using standardized authentication methods, such as but not limited to, username, password, One Time Password (OTP), x509, etc…

I would argue most common way of deterring identify theft by way of session hijacking is by using a session ID that is generated using a pseudo random number generator (PRNG, as true randomness is not possible as the algorithms to create a deterministic system by which one can reverse engineer if the pattern is known and seed number ), and it is important that these session ID's are not easily visible or follow any fingerprinting formats, so as to not make an attackers job any easier, this could be considered part of the reconnaissance stage of OSIT. This token is sent to the browser and stored as a cookie (the  HTTP-only and Secure flags should be set in the cookie or header fields to mitigate theft as well as disallow samesite flag) or the session id can be held in a database on the server side to help prevent those attacks in exchange for performance, which is typically not done on websites that have frequent user activity due to the performance degradation and added capital cost.

Transport layer security and webapp redirects from port 80 to 443 should be implemented for safety from network traffic eavesdropping, which ideally should be closed or set to a non-standardized port number. By encrypting traffic with Public Key Infrastructure (PKI) instruments of Transport Layer Security/Secure Sockets Layer (TLS/SSL), we can help to ensure that all the attackers will see is cipher text if traffic is intercepted, which will be all but useless to them.

This information should not be appended or concatenated to the end of the URL for passing vis URL Rewriting, as it poses serious security risks. Some organizations use this as a justification for when users are not able to store cookies due to company security settings, but this just leaves the application open to session fixation attacks and easy eavesdropping due to logging systems that typically capture URL locations that a user is browsing to.