Analyze and exploit session-related vulnerabilities

Imagine that SecureXit has developed a web-based document submission portal where users can upload their resumes, profile pictures, certificates, and other documents.

The portal is designed to accept only approved file types, such as JPG, PNG, and PDF. However, the application's file upload mechanism may have weak validation controls.

As a Cyber Security Analyst at SecureXit, your task is to evaluate whether an attacker could upload a file that violates the application's security policy by manipulating the HTTP request through Burp Suite.

1. Lab Environment: Kali Linux and an intentionally vulnerable web application configured in an isolated virtual machine using VirtualBox or VMware.

2. Security Tools: Burp Suite Community Edition and a web browser configured to intercept and analyze HTTP requests.

3. Basic Knowledge: Understanding of HTTP requests, file upload mechanisms, MIME types, file extensions, and basic web application security.

Downloaded the OWASP Broken Web Applications VM (version 1.2, released 3 Aug 2015) from VulnHub, via the SourceForge mirror link ​

http://OWASP_Broken_Web_Apps_VM_1.2.7z (1.7 GB)

Extracted the .7z archive using 7-Zip to obtain the .vmdk disk image.

Imported the VM into Oracle VirtualBox alongside existing machines (Kali Linux, Wazuh, metascan, hackme).

Configured Storage: the OWASP_Broken_Web_Apps-cl1.vmdk disk was attached to the SATA controller, with the IDE controller left empty.

Configured Network: Adapter 1 set to Bridged Adapter, bound to the host's wireless interface, with Promiscuous Mode set to Deny — this places the VM on the same LAN segment as the host for direct browser access.

Powered on the VM. The login banner confirmed access details:

Web apps: http://10.159.241.170/

Application login: username owaspbwa, password owaspbwa

Browsed to http://10.159.241.170 from the host browser and confirmed the owaspbwa landing page, listing the bundled training applications (WebGoat, WebGoat.NET, ESAPI SwingSet, Mutillidae II, RailsGoat, Bricks, etc.)

Selected OWASP WebGoat → Session Management Flaws from the left-hand menu to begin the exercises.

Hijack a Session / Spoof an Authentication Cookie

Goal: bypass WebGoat's authentication check by manipulating the AuthCookie value rather than supplying valid credentials.

Moved to Spoof an Authentication Cookie and logged in with the suggested test account webgoat / webgoat.

On login, WebGoat issued an AuthCookie with value 65432ubphcfx and a JSESSIONID, and displayed: "Welcome, webgoat – You have been authenticated with PARAMETERS."

Logged in again with the second suggested account, aspect / aspect. The resulting AuthCookie was 65432udfqtb.

Compared both cookie values side by side:

Observed that both cookies share the same leading block, 65432, and that the trailing characters are a simple Caesar-shifted encoding of the username:

• webgoat → shift (w=x, e=f, b=c, g=h, o=p, a=b, t=u) → ubphcfx
• webgoat = taogbew  shift w=x,e=f,b=c,g=h,o=p,a=b,t=u => ubphcfx
• aspect → shift (a=b, s=t, p=q, e=f, c=d, t=u) → udfqtb

aspect = tcepsa shift  a=b,s=t,p=q,e=f,c=d,t=u =>  udfqtb

Applying the same +1 letter shift to the target username alice (a=b, l=m, i=j, c=d, e=f) gives fdjmb. Combined with the constant prefix, the forged cookie becomes 65432fdjmb.

Used Firefox DevTools → Storage → Cookies to edit the AuthCookie value on the live session to 65432fdjmb and refreshed the page.

The application responded: "Congratulations. You have successfully completed this lesson. Welcome, alice – You have been authenticated with COOKIE."

Result: authentication was bypassed entirely by predicting another user's cookie from its encoding pattern, with no need to know Alice's real password.

Exercise 2 – Session Fixation.

Goal: force a victim to use a session ID chosen by the attacker, then reuse that same ID after the victim authenticates to inherit their logged-in session

Stage 1 – Hacker Joe crafts the phishing link

• Acted as Hacker Joe, drafting a fake "Goat Hills Financial" account-verification email addressed to jane.plane@owasp.org, spoofed as from admin@webgoatfinancial.com

• Edited the embedded link to append a self-chosen Session ID (SID) parameter: http://10.159.241.170/WebGoat/attack?Screen=132&menu=1800&SID=hacker_will_set_id_kadir7233

• Sent the mail; WebGoat confirmed Stage 1 complete.

Stage 2 – Victim Jane receives and opens the link

• Switched to the Victim Jane view and opened the received email, which reproduced the attacker's link containing the planted SID.

• Clicking the link landed on the Goat Hills Financial HR login page, confirming Stage 2 complete.

Stage 3 – Victim logs in using the fixed session

• Logged in as Jane with credentials Jane / tarzan while the URL still carried SID=hacker_will_set_id_kadir7233.

• The application authenticated Jane without issuing a new session ID, silently binding her authenticated session to the attacker-supplied SID. WebGoat confirmed Stage 3 complete.

Stage 4 – Hacker Joe reuses the fixed SID

• Switched back to Hacker Joe and, before reusing the link, first tested it with an invalid SID (SID=NOVALIDSESS), which correctly returned an empty/unauthenticated login page — confirming the SID itself is what grants access.

• Replayed the original crafted link — ...&SID=hacker_will_set_id_kadir7233 — the exact value planted in Stage 1.

• WebGoat displayed: "Congratulations. You have successfully completed this lesson." and rendered Jane Plane's authenticated HR record directly to the attacker, including:

Result: because the application accepted a session identifier supplied externally (via URL) instead of generating a fresh one at login, the attacker who fixed the SID before authentication was able to hijack the victim's authenticated session afterward — without ever learning her password — and retrieve her personal and financial data.

Key Observations and Mitigations

• We can set cookies with HttpOnly and use the Secure flags to prevent JavaScript access.

• After authentication website need to regenerate the session id always.

• Check the session ID remains the same before login and after authentication if the session id remain same and it is vulnerable to Session Fixation.

• To mitigate session fixation in PHP, regenerate the session ID immediately upon user authentication or privilege change using session_regenerate_id(true) and harden your php.ini or runtime settings to block URL-based or uninitialized session IDs.

• Token Rotation: Issue fresh tokens or refresh token families on use so that replayed or stolen legacy tokens are immediately invalidated.

• Avoid Custom Formats: Never use weak, predictable string concatenations or custom encodings; rely on standard cryptographic frameworks backed by cryptographically secure pseudo-random number generators (CSPRNGs). 

• We can also implement the Content Security Policy (CSP) to mitigate XSS attacks on the websites or applications.

• Use the SameSite=Strict cookies to prevent cross-site session fixation attacks.

Great job!

• Successfully intercept and analyze file upload requests using Burp Suite.

• Identify weak file validation mechanisms by testing file extensions, MIME types, and file content in the controlled lab.

• Verify upload security controls, assess server-side execution risks, and document findings with appropriate mitigation recommendations.

Topic : Reporting and Security Practices

1) Writing vulnerability assessment and penetration testing reports