Listen to this Post
Introduction:
Cross-Site Request Forgery (CSRF) remains one of the most overlooked yet critical web security flaws, allowing attackers to force authenticated users to execute unwanted actions. While automated scanners often miss these logic-based vulnerabilities, manual inspection of client-side code—specifically JavaScript files—can reveal hidden endpoints and unprotected state-changing requests. This article dissects a real-world bug bounty methodology that leverages JavaScript analysis to uncover CSRF vulnerabilities, providing a technical roadmap for security researchers and developers alike.
Learning Objectives:
- Understand how to analyze JavaScript files to discover hidden API endpoints and parameters.
- Learn to identify and manually test for missing anti-CSRF tokens in state-changing requests.
- Master practical exploitation techniques using browser dev tools and command-line utilities.
You Should Know:
1. Harvesting Hidden Endpoints via JavaScript Analysis
Modern web applications bundle extensive client-side logic into JavaScript files. These files often contain API routes, hidden parameters, and developer comments that are not visible in the standard HTML source.
– Step‑by‑step guide:
1. Open your browser’s Developer Tools (F12) and navigate to the Network tab. Reload the target page and filter by `JS` or `Script` to capture all loaded JavaScript files.
2. Alternatively, use a command-line tool like `curl` or `wget` to download the main JS bundles:
curl https://target.com/static/js/main.chunk.js -o main.js
3. Use `grep` with regex patterns to hunt for API endpoints, hidden parameters, or developer notes:
grep -Eoh "(/api/v[0-9]/[a-zA-Z0-9/_-]+)|(csrf|xsrf|token)" main.js
4. For a more automated approach, tools like LinkFinder or JSParser can be used to extract URLs and endpoints:
python3 linkfinder.py -i main.js -o cli
5. Analyze the output. Look for endpoints that perform state-changing actions like POST /user/delete, POST /update-email, or POST /transfer-funds. These are prime candidates for CSRF testing.
- Identifying the Presence (or Absence) of Anti-CSRF Tokens
Once you have a list of potential sensitive endpoints, you must determine how the application implements CSRF protection. This involves inspecting the HTTP requests sent by the application when performing an action.
– Step‑by‑step guide:
1. Log into the application and perform a sensitive action (e.g., changing an email address). In the Network tab, locate the corresponding request.
2. Inspect the request headers and body. Look for parameters named csrf, xsrf, _token, authenticity_token, or a custom header like X-CSRF-TOKEN.
3. Check the request’s Initiator in DevTools. It will often show you the exact line of JavaScript code that triggered the request. Clicking it reveals the client-side logic responsible for building the request.
4. If a token is present, note where it comes from. Is it in a `meta` tag in the HTML? Is it fetched via a separate API call (e.g., GET /api/csrf-token)?
5. The vulnerability appears when the token is not present, is static (e.g., always the same value, like "token":"1234"), or is not properly verified by the server.
3. Crafting a Proof-of-Concept (PoC) for CSRF Exploitation
If you confirm that a state-changing request lacks a valid anti-CSRF token, the next step is to create a proof-of-concept to demonstrate the impact. This involves creating a simple HTML page that forces the victim’s browser to make the malicious request.
– Step‑by‑step guide:
1. Recreate the exact request parameters and method (GET or POST) needed to perform the action.
2. For a GET-based request, you can use an `` tag with a crafted `src` attribute:
<img src="https://target.com/user/delete?id=123" style="display:none" />
3. For a POST-based request, you must use a hidden form that auto-submits using JavaScript:
<html> <body> <form id="csrfForm" action="https://target.com/api/change-email" method="POST"> <input type="hidden" name="email" value="[email protected]" /> </form> <script> document.getElementById("csrfForm").submit(); </script> </body> </html>
4. Host this HTML on a server you control (or a simple Python HTTP server: python3 -m http.server 8080).
5. Ensure the victim is authenticated on the target site. Then, lure them to visit your malicious page. If the email changes or the action is performed without any interaction (and without a valid CSRF token), the vulnerability is confirmed.
4. Bypassing Weak CSRF Protections Found in JS
Sometimes, developers attempt custom CSRF protections that are flawed. JavaScript files are the best place to find these weaknesses. For example, an application might rely on the `Origin` or `Referer` header, or it might use a double-submit cookie mechanism that is improperly implemented.
– Step‑by‑step guide:
1. Check for Header Validation: If the request includes a custom header like X-Requested-With: XMLHttpRequest, the server might be checking for it. You can add this header to your PoC using JavaScript’s `fetch` API. However, modern browsers enforce CORS policies on custom headers, which can prevent simple form-based attacks. If the server uses CORS permissively, you might still succeed.
2. Analyze Cookie-Based Tokens: In a double-submit cookie pattern, the CSRF token is sent both as a cookie and as a request parameter. The server checks if they match. If the JavaScript reveals that the cookie is set without the `HttpOnly` flag, you might be able to read it via a separate XSS vulnerability. Without XSS, this is generally secure, but if the cookie is set on a subdomain, it might be exploitable.
3. Look for Token Reusability: Capture a valid token from a legitimate request. Create your PoC and hardcode that captured token. If the server accepts it more than once, or for a different user session, that’s a massive flaw. The JavaScript might show you that tokens are generated based on weak factors (like timestamp or username), allowing you to predict them.
5. Automating the Hunt with Tools (Linux/Windows)
While manual analysis is key, automating the initial reconnaissance saves time. A combination of command-line utilities can be used to parse JS files en masse.
– Step‑by‑step guide (Linux):
1. First, use `gau` (GetAllUrls) or `waybackurls` to gather historical URLs for the target:
echo "target.com" | gau | grep ".js$" > js_urls.txt
2. Use `httpx` to check which JS files are still live:
cat js_urls.txt | httpx -status-code -content-type | grep "200"
3. Download all live JS files and search for endpoints and potential CSRF-related comments:
cat live_js.txt | while read url; do curl -s $url | grep -Eo "(/[a-zA-Z0-9/_-]{5,})|(CSRF|xsrf)" | sort -u; done
4. For Windows, you can use PowerShell:
$urls = Get-Content .\js_urls.txt
foreach ($url in $urls) {
(Invoke-WebRequest -Uri $url).Content | Select-String -Pattern "(/[a-zA-Z0-9/<em>-]{5,})|(CSRF|xsrf)" | ForEach-Object { $</em>.Matches.Value } | Sort-Object -Unique
}
What Undercode Say:
- Key Takeaway 1: Client-side code is a treasure map. Never trust that JavaScript files are “just frontend code”; they are the blueprint to the server’s backend architecture and hidden attack surfaces.
- Key Takeaway 2: CSRF is not dead. While frameworks often include built-in protections, custom implementations and misconfigurations leave applications vulnerable. The absence of a token in a request captured from the browser’s network tab is a red flag that warrants immediate manual investigation.
Analysis: This methodology underscores a fundamental shift in web application security auditing. The most severe vulnerabilities are often found not by blasting the server with payloads, but by patiently reading the application’s own source code. For defenders, this means implementing robust Content Security Policies to limit script sources, conducting regular reviews of exposed endpoints in JavaScript, and ensuring CSRF protection is applied universally and verified server-side. For bug bounty hunters, the ability to read and interpret JavaScript is no longer optional—it is the primary skill that separates script-kiddie scanning from professional-grade vulnerability discovery.
Prediction:
As single-page applications (SPAs) and frameworks like React, Vue, and Angular continue to dominate web development, the attack surface will shift further into the client. We predict a rise in “client-side CSRF” and API misuse vulnerabilities discovered specifically through JavaScript analysis. Consequently, automated security tools will evolve to include sophisticated JavaScript parsers and runtime analyzers, but the human ability to understand application logic from code will remain an indispensable skill for the foreseeable future.
▶️ Related Video (76% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Harissn018 Bugbounty – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
