In our previous post, we explored Cross-Site Scripting (XSS), where an attacker injects malicious scripts to execute within a victim's browser context. Today, we move into a different realm of client-side exploitation. Instead of just running code, we will learn how to weaponize the browser's own mechanisms to force users into performing actions they never intended, bypass the most fundamental security rules of the web, and lead them into digital traps.

This post covers three critical pillars: Cross-Site Request Forgery (CSRF), Cross-Origin Resource Sharing (CORS) misconfigurations, and Open Redirects.

1. Cross-Site Request Forgery (CSRF): The Unintended Action

CSRF is an attack that tricks a victim's browser into performing an unwanted action on a different website where the victim is currently authenticated.

The Mechanism of Trust

CSRF works because browsers automatically include ambient authority — such as session cookies — in every request sent to a specific domain, regardless of where that request originated. If you are logged into your bank and visit a malicious site in another tab, that site can send a background request to your bank to "Transfer $5000 to Attacker." Because your browser sends your valid session cookie with that request, the bank's server may assume you authorized the transaction.

Hunting for CSRF

To find CSRF, you must look for state-changing requests (usually POST, PUT, or DELETE) that do not require a unique, unpredictable token. Common targets include:

• Email/Password Changes: A successful CSRF here leads to full account takeover.
• Profile Updates: Changing a user's phone number or address.
• Action Triggers: Deleting content, adding administrative users, or disabling security features.

Pro-Tip: Always check if the application validates the Referer or Origin headers, or if it uses the SameSite cookie attribute to prevent cookies from being sent in cross-site contexts.

2. CORS Misconfigurations: Breaking the Same-Origin Policy

As we learned in Volume 1, the Same-Origin Policy (SOP) is the bedrock of web security, preventing scripts on attacker.com from reading data from bank.com. However, modern web apps often need to share data across different domains. Enter Cross-Origin Resource Sharing (CORS).

CORS is a mechanism that allows a server to explicitly tell the browser: "I trust this other origin to read my data".

The Vulnerability: Excessive Trust

Vulnerabilities arise when developers misconfigure CORS headers, essentially poking a hole in the SOP. Common high-reward misconfigurations include:

• Reflection of the Origin Header: The server reads the Origin header from the request and reflects it back in Access-Control-Allow-Origin. If combined with Access-Control-Allow-Credentials: true, any site on the internet can use JavaScript to read the victim's private data (like API keys or messages) while they are logged in.
• Wildcard (*) with Credentials: While a simple wildcard * is safe for public data, modern browsers block the combination of * and Allow-Credentials. Attackers look for servers that try to manually implement this logic and fail.
• Null Origin: Some developers allow the null origin for testing. An attacker can use a sandboxed iframe to generate a request with a null origin and steal sensitive information.

Impact vs. CSRF

While CSRF allows you to perform actions, a CORS misconfiguration allows you to read sensitive data that the SOP would otherwise protect.

3. Open Redirects: The Gateway Drug

An Open Redirect occurs when an application takes a user-controllable parameter (like ?url=, ?next=, or ?redir=) and uses it to redirect the user to an external site without proper validation.

Why it Matters

On its own, an open redirect is often labeled as "Low" severity. However, it is a powerful tool for:

• Phishing: Tricking a user into thinking they are still on a trusted domain (e.g., https://target.com/login?redir=https://attacker-phish.com).
• Bypassing OAuth Filters: If a company uses a whitelist for OAuth redirect URIs, an open redirect on one of those whitelisted pages can be used to steal sensitive access_token or code values.
• Bypassing SSRF/XSS Filters: Some security filters only check the initial domain; a redirect can sometimes "teleport" your payload past these checks.

Real-World Case: Shopify once paid a bounty for an open redirect on their login page that allowed attackers to redirect users to malicious domains after they successfully authenticated.

Chaining for Max Impact

The best bug hunters don't stop at a single bug. They chain these together. For example:

1. Use an Open Redirect to lead a user to your malicious site.
2. Trigger a CORS misconfiguration to steal their private API key.
3. Use a CSRF vulnerability to add your own email address to their account using that stolen key.

In the next post, we will look at even more complex client-side scenarios, including Hacking Browser Extensions and Thick Clients, where we will decompile code to find hidden validation flaws.