Main navigation | Main content
This week's lab returns to web-vulnerability attacking with examples of Cross-Site Request Forgery (CSRF) vulnerabilities. These arise when site accepts requests on behalf of a user by relying on authentication information like a cookie that it sent automatically, but missing that other aspects of the quest came from an invalid source. As we did with SQL injection, we'll be exercising known vulnerabilties in the WebGoat server; this week we'll also be using the companion tool named WebWolf which is also a web application, but simulates that attacker's site.
As usual in the online lab we'll randomly split you into breakout groups of 2-3 students: please work together, discuss, and learn from the other student(s) in you group. Use the "Ask for Help" button to ask questions or show off what you've done. We also recommend working in groups in the in-person lab, but there you can choose your own groups and physically raise your hand to ask a question. You may still find it useful to use Zoom or tmate for screen sharing in person while respecting social distancing.
Refer back to week 7 for basic background about running WebGoat, or week 8 for advice for connecting to a WebGoat server running on a CSELabs machine over SSH. As before, you should start your own copy of the WebGoat server using a large .jar file we've already installed. This time you'll need to pick three different port numbers for WebGoat, WebWolf, and the SQL server they share. In the examples we'll use a pattern where you pick a number N between 8000 and 9000 to be the WebGoat web interface, and then use N+1 for the WebWolf interface and N+1000 for the SQL server. In particular the examples use 8234, 8235, and 9234, but you'll need to pick different numbers especially if you're on the same machine as another student. Both WebGoat and WebWolf produce lots of (mostly unimportant) messages on the terminal, so we recommend running each in its own terminal window. For instance you can start WebGoat in one terminal with this command:
env WEBGOAT_HSQLPORT=9234 java -jar /web/classes/Fall-2020/csci4271/labs/12/webgoat-server-8.1.0.jar --server.port=8234
and WebWolf in another terminal with this command:
env WEBGOAT_HSQLPORT=9234 java -jar /web/classes/Fall-2020/csci4271/labs/12/webwolf-8.1.0.jar --server.port=8235
When you want to stop either server, you can kill it by typing Control-C in the window where it is running. The program will also store some persistent data in your home directory in a directory named .webgoat-8.1.0; you can remove this if you're done with it.
Once the WebGoat web server is running you can connect to it from your favorite web browser (on the same machine, or with SSH forwarding) at a URL like:
http://localhost:8234/WebGoat
Where of course you replace 8234 with the port number you chose in the previous step. You'll have to create an account when you log in for the first time, though if you didn't delete the data files from before, the same account will still be around. Analogously you can find WebWolf at:
http://localhost:8235/login
Because they share the same backend database, you can use your same WebGoat account for WebWolf.
It's important to keep in mind that there are three different entities involved in a CSRF attack: a benign site (e.g., bank.com), a user of the benign site (the customer whose account is going to be accessed), and a separate malicious web site (e.g., attacker.com). This is the reason for the separation between WebGoat and WebWolf: WebGoat is like bank.com, while WebWolf is like attacker.com. But of course unless you're doing the lab together with a friend, you'll need to play the roles of both the victim and the attacker. When you're logged into WebGoat, you're the victim. But the attacker can use WebWolf's capabilities to set up traps for the victim. In particular for this assignment you need to use WebWolf's "Files" feature to host web pages that the victim will click on. In a complete real world attack the attacker might need to do things like buy ads to attract victims to attacker.com and put enticing messages in links to tempt users to click on them, but for the lab we'll just assume that if the attacker makes a web site, the victim will come along and click on it.
The CSRF module of WebGoat can be reached from the main menu after you log in, first under "(A8:2013) Request Forgeries", and then "Cross-Site Request Forgeries". The different pages of the module each have their own instructions, but we'll mention some extra suggestions for particular steps below:
If you were creating a benign web site, you would generally create an HTML form and the server-side code that processes it in tandem so that they work together. To create a CSRF attack, you as the attacker need to create a new HTML page that the victim will be tempted to click on, but that will have your attacker-desired effect when processed by the bank.com server-side code. In order to see what information your attack page will need to send, you can compare with how the form on the benign site is written. However because the relevant parts of the WebGoat pages are loaded asynchronously, the traditional web browser "View Source" won't show you the information you're interested in. What we recommend instead is the web developer "Inspector" tool in recent versions of Firefox: you can get information about a piece of content on a page by right-clicking on it and choosing "Inspect Element", which pops up information at the bottom of your window, including a tree of HTML tags. If you haven't worked with HTML forms before, the basic structure is a <form> on the outside, whose attributes include where and how the form will be submitted, and then <input> tags inside that, each of which supplies one field's worth of information.
To set up the CSRF attack, you'll need to make your own little web site with a similar form, or something else like JavaScript that will have the right effect when the user clicks on it. You can create this in a text editor, cutting and pasting relevant information from the WebGoat web site. Then save this HTML in a file, upload the file in the Files section of WebWolf, and view the file after uploading it. (Each time you upload a file you'll need to give it a unique name.) Then you can switch to pretending to be the victim and clicking on something the attacker created in the page. Note that to confirm that you carried the attack out successfully, some of the pages will print a unique "flag" value when successfully attacked, which you can cut and paste back into WebGoat.
This question is a fairly small generalization of the previous one, with one more defense that you'll need to subvert. You don't actually have to put in a full review for the attack to count as successful, but you might look into how to control the text of the review and the rating, since those are things a real attacker would want to control.
Like a lot of web attacks, the details here all have to do with quoting and text processing that's needed to squeeze attack data through an unexpected place: in this case specifically using a plain form to create a request that the benign web site sends in a using JSON.
The external link on the WebGoat page was sometimes getting flagged as malicious by Safe Browsing in your testing, so you might want to see this archived version instead.
The key suggestion from the linked blog post is that setting the attribute enctype="text/plain" in the form tag will disable most of the extra escaping that the browser would normally do on form data. Since the JSON uses a lot of double quotes, it's good to know that HTML attributes can use single quotes to avoid having to escape the double quotes. Also, you can avoid line breaks in the attribute by using the fact that they aren't mandatory in JSON; they're equivalent to any whitespace.