There are two friends of cybersecurity experts, Eve and Charlie. Eve is a fresher security analyst for a tech company, and Charlie is an experienced security researcher who studies vulnerabilities in web applications.
One day, Eve and Charlie meet for coffee and discuss the different web application vulnerabilities they’ve seen. Eve mentions that she’s been seeing a lot of reports lately about a vulnerability called SSRF (Server-Side Request Forgery).
Charlie nods and explains that SSRF is a vulnerability where an attacker can trick a server into making requests to other servers that the attacker controls. Eve asks for an example, and Charlie tells her a story:
"Imagine there’s a website where you can enter a URL, and the website will fetch the URL’s content and display it for you. This feature is helpful because it allows users to see the contents of external web pages without leaving the website. But if the website doesn’t validate the URL the user provides, an attacker can enter a malicious URL pointing to a server the attacker controls. The server will then make a request to a vulnerable internal server, which will send the attacker sensitive information or perform other malicious actions on behalf of the attacker.
Charlie demonstrates the vulnerability with the following code snippet:
$url = $_GET['url'];
$data = file_get_contents($url);
echo $data;
?>
Eve is alarmed and asks how this can be prevented. Charlie explains that the key is to validate user input, and to use a whitelist approach where only approved URLs are allowed. Eve suggests adding input validation and implementing a whitelist approach to ensure that only trusted external URLs are allowed.
Charlie agrees and suggests the following code changes to prevent the vulnerability:
$url = $_GET['url'];
$whitelist = ['https://example.com', 'https://trusted-site.com'];
if (in_array($url, $whitelist)) {
$data = file_get_contents($url);
echo $data;
} else {
echo 'Invalid URL';
}
?>
Eve nods and says she understands the issue and solution but is curious about how this differs from another vulnerability called CSRF (Cross-Site Request Forgery).
Charlie explains that CSRF is a vulnerability where an attacker tricks a user into acting on a website without their knowledge or consent. Eve asks for an example, and Charlie tells her another story:
"Imagine there’s a website where you can change your email address by filling out a form. But the website doesn’t use a CSRF token to prevent attackers from tricking users into changing their email addresses without their consent. An attacker could create a fake form that looks like the real one and trick the user into entering their email address. When the user submits the form, the attacker could intercept the request and change the email address on the user’s account to an address the attacker controls.
Eve and Charlie continue their conversation and discuss the importance of using CSRF tokens to prevent CSRF attacks. Charlie explains that if a web application doesn’t use CSRF tokens, attackers can exploit the vulnerability to perform actions on behalf of the user without their knowledge or consent, as he had explained earlier in his story.
Eve nods and asks, “But how can developers implement CSRF tokens to protect their web applications?”
Charlie explains that the process is pretty simple. When a user logs in to the web application, the server generates a unique token and stores it in the user’s session data. When the user submits a form, the server includes the token in a hidden field in the form, along with any other data that the user has entered.
When the server receives the request, it checks to see if the token in the request matches the token stored in the user’s session data. If the tokens match, the server processes the request. If the tokens don’t match, the server rejects the request.
To demonstrate how this works, Charlie shows Eve a vulnerable code snippet that allows an attacker to change a user’s email address without their knowledge or consent:
<input type="text" name="email" placeholder="Enter new email address">
<button type="submit">Submit</button>
</form>
Charlie explains that an attacker could create a fake form that looks like the real one and trick the user into entering their email address. When the user submits the form, the attacker could intercept the request and change the email address on the user’s account to an address the attacker controls.
He then shows Eve the same code snippet but with a CSRF token added:
<input type="hidden" name="csrf_token" value="<?php echo $_SESSION['csrf_token']; ?>">
<input type="text" name="email" placeholder="Enter new email address">
<button type="submit">Submit</button>
</form>
Charlie explains that when the user logs in, the server generates a unique token and stores it in the user’s session data. When the user submits the form, the server includes the token in a hidden field in the form. When the server receives the request, it checks to see if the token in the request matches the token stored in the user’s session data. If the tokens match, the server processes the request. If the tokens don’t match, the server rejects the request.
Eve nods and says she understands how CSRF tokens work and how we can use them to prevent CSRF attacks.
In simple, SSRF is a vulnerability where an attacker tricks a server into making requests to other servers the attacker controls, while CSRF is a vulnerability where an attacker tricks a user into acting on a website without their knowledge or consent.
But that’s not where our story ends 😉
After their discussion about vulnerabilities had finished, Eve couldn’t resist trying to prank Charlie. She quickly whipped up a fake login page for Charlie’s website and sent him the link, pretending it was a new login feature he needed to test.
Charlie clicked the link and entered his login credentials, not suspecting a thing. But little did he know Eve had added a CSRF attack to the fake login page. When Charlie submitted the form, it triggered a request to his website that changed his email address to a silly and embarrassing one.
Eve couldn’t help but chuckle at her prank. But then, Charlie started laughing too. “Good one, Eve! You got me good!” he said.
It turned out that Charlie had anticipated that Eve might try to pull a prank on him using CSRF. So he had set up a unique CSRF token on his website that only he knew about. When Eve tried to change his email address, her CSRF attack failed because the token was invalid.
Eve was surprised but impressed. “You really know your stuff, Charlie!” she said, still laughing. “I guess the student has become the teacher.”
Charlie just smiled and shrugged. “Hey, I learned from the best,” he said, gesturing to Eve.
The two friends laughed and finished their coffee, discussing the importance of staying vigilant and always being prepared for new vulnerabilities and attack vectors. And they both agreed that, in the end, the best defense against hackers is a strong and collaborative security community. ❤
This blog is intended to teach you the basics of SSRF and CSRF vulnerabilities - how they works and how to prevent it. I Hope you all enjoyed the discussion between Eve and Charlie. If you loved my content, do drop a like and repost.
This is Winnish Allwin signing off! 👋
