Demonstrating Cross-Site Request Forgery
One of the most common vulnerabilities in web applications is known as HTML injection or cross-site scripting, and one of the simplest ways of showing such a problem exists involves loading a JavaScript alert dialog. Those who understand the ramifications of such an issue know that it creates the potential for far more malicious activity, but the alert box is an easy demonstration that the application can be automatically manipulated.
Other vulnerability, though, may be more subtle and not as readily visualized. Take cross-site request forgery, for example. It’s easy to understand that there’s a problem when an application lets you manipulate the data of other users – the site should validate the account making requests before executing them. What may not be so obvious is that problems can still arise even when the application checks the account first. If no system exists for verifying that the account owner actually intended to perform a given action, it may be possible to hijack that user’s session and make requests without them knowing. The technical term for this behavior is cross-site request forgery.
To illustrate the problem, it’s handy to have a simple proof-of-concept – an “alert box” for CSRF. Recently I tested an application with CSRF issues; to demonstrate the problem, I created an index.html file with code similar to this:
<html>
<body>
<p id="status">Loading...</p>
<div id="loader" style="display:none;"></div>
<iframe src="index2.html" style="display:none;"></iframe>
<script>
loader = document.getElementById("loader");
for (var i = 0; i < 100; i++) {
x = document.createElement("img");
x.src = "http://app/message/delete?message_id=" + i;
loader.appendChild(x);
}
document.getElementById("status").innerHTML = "Finished.";
</script>
</body>
</html>
Ignore the iframe for a moment and look at the script section. This page creates a series of image elements, each with the source attribute set to an interface for deleting messages in the application. The code cycles through a range of ID values as it creates the images and can work quite fast.
Now suppose the application uses GET requests for deleting messages without any further validation. Suppose a logged-in user visited the site where I uploaded this page. Each time one of those images is added to the page, the browser will send a GET request to the delete interface. It doesn’t matter that the address doesn’t actually point to an image file – the browser doesn’t know that beforehand, so it sends the request regardless. And since the request is sent in the context of the user’s session, any of their messages with IDs in this attack range will end up getting deleted. The application never realizes the delete requests came from a malicious page without the user’s knowledge.
The iframe pointing to index2.html helps to demonstrate another CSRF issue. In the example above, the server accepted GET requests and thus we only needed to create images to exploit the interface. But that doesn’t mean simply switching to POST requests will provide greater protection. Let’s say adding a message requires an unvalidated POST request. We can include this code in the index2.html file:
<html> <body> <form method="POST" action="http://app/message/add"> <input type="hidden" name="subject" value="Hi there!"> <input type="hidden" name="message" value="Visit my page."> </form> <script> document.forms[0].submit(); </script> </body> </html>
This page creates a form with predetermined values and then immediately submits it. By including it as an iframe in our original page, we can execute the POST request silently in the background. Once again, if a user visits the page while logged in, the request is sent with their session cookies, and the application never realizes where the request came from.
While these examples are simple and would need to be adjusted to actually work against a vulnerable interface, they can help you show instead of just tell when you’re explaining CSRF problems. Feel free to add them to your hacking toolbox.