Introduction To CSRF

Cross-Site Request Forgery (CSRF) is a security vulnerability where an attacker deceives a user's browser into executing unintended actions on a website where the user is logged in. This deception typically occurs when a user interacts with a malicious website or clicks on a carefully crafted link.

The crux of CSRF lies in exploiting the trust relationship between a website and the user's browser. Websites often use session cookies to identify and validate user actions after authentication. If an attacker manages to coerce the user's browser into sending a request to the targeted website where the user is authenticated, the website might mistakenly treat the request as genuine.

For instance, picture a scenario where a user is logged into their online banking account. If the attacker can manipulate the user into clicking a link or visiting a page containing a concealed form that initiates a money transfer, the user's browser will transmit the request to the bank alongside the user's authentication credentials, potentially enabling unauthorized transactions.

How CSRF Works

For a CSRF attack to succeed, three essential conditions must be met:

Relevant Action: The application must have an action that the attacker wants to trigger. This action could be something privileged, like altering permissions for other users, or any action related to user-specific data, such as modifying the user's password.
Cookie-based Session Handling: The execution of the action involves sending one or more HTTP requests, and the application relies exclusively on session cookies to identify the user making those requests. There are no additional mechanisms in place for session tracking or user request validation.
Predictable Request Parameters: The requests responsible for performing the action do not include any parameters whose values are unpredictable or beyond the attacker's ability to guess. For example, if a user is prompted to change their email address, the function is not vulnerable if the attacker needs to know the current email address to initiate the change.

The scenario involves a user changing their email address on a vulnerable website. When the user performs this action, an HTTP request like the following is sent:

POST /email/change HTTP/1.1
Host: vulnerable-website.com 
Content-Type: application/x-www-form-urlencoded 
Content-Length: 30 
Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE 

[email protected]

Here's how the attack works:

The application employs a session cookie to identify the user issuing the request.
The attacker can easily discern the necessary parameter values required for the action.

Proof of Concept (PoC):

<html>
	<body>
		<form action="<https://vulnerable-website.com/email/change>" method="POST">
			 <input type="hidden" name="email" value="[email protected]" />
		</form>
		<script>
			document.forms[0].submit();
		</script>
	</body>
</html>

When a victim user visits the attacker's webpage:

The attacker's page initiates an HTTP request to the vulnerable website.