Main navigation | Main content
This week is about vulnerabilities in web software, specifically the server-side vulnerability of SQL injection. Since desktop machines are less likely to have a SQL server available compared to a web browser, you'll be using some externally-created vulnerable code named WebGoat which contains an internal SQL server. It's more explicitly tutorial-style than many of our other labs; if you like the style you might also look at the modules WebGoat provides on other web vulnerabilities.
Because WebGoat packages a web site that intentionally contains lots of vulnerabilities, you might wonder whether there's a risk from leaving it running. WebGoat itself has a some scary-sounding disclaimers on the login page and recommends that you run it on a computer disconnected from the Internet, but of course that's not a very practical suggestion for the lab machines. Our recommendation is that running it on an Internet-connected computer is sufficiently safe, though we would still recommend killing it when you're not using it. If your personal computer (e.g., laptop) has Java 11 and a browser, you can run it there. (The latest versions since 8.2.0 need Java 15; the older version 8.1.0 works with Java 11.) It's also set up to be easily run in a Docker container if you happen to have that set up. Directions for using these configurations can be found on the WebGoat site here. The rest of the instructions will describe running it on CSE Labs machines; this is a less ideal situation because the machines are all multi-user, but the risk is still limited because the ultimate effect of WebGoat's vulnerabilities is intentionally circumscribed. (The SQL injection vulnerabilities themselves only expose fake databases.)
WebGoat is packaged as a large .jar file, so it's better not to copy it to your home directory; instead we've downloaded a single copy that everyone can use. Choose a random port number between 8000 and 9000 for the server (the examples use 8234) and another random port number between 9000 and 10000 for the database server (the examples use 9234). These port numbers need to be different from any other users doing the lab on the same machine. The WebGoat program will produce lots of (unimportant) messages on the terminal, so we recommend running it in its own terminal window, and because it only allows connections from the same machine, you should run it on a machine where you can also run a web browser (e.g., a lab machine, or Vole if you're remote). As of this writing, the default version of Java on the lab machines has been upgraded to Java 17, so the standard java program should work. (In case it doesn't, you can see all the Java versions installed as Ubuntu packages in /usr/lib/jvm, or a version of Java we used in previous semesters is under /web/classes/Fall-2022/csci4271/soft/jdk-18.0.2.1) The command to start WebGoat looks like:
env WEBGOAT_PORT=8234 WEBGOAT_HSQLPORT=9234 java -jar \ /web/classes/Spring-2023/csci4271/labs/08/webgoat-2023.4.jar
The backslashes at the end of the first line indicates that this is intended to be one long command line, but we've broken it up into pieces because it would be too long otherwise. The shell should interpret it correctly if you cut and paste it all together, as long as the backslash is the last characters on its line. Or you can cut and paste the two parts separately and skip the backslash.
It should take a few seconds to start up and then print a message that looks like Started StartWebGoat in 12.642 seconds. When you want to stop the 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-2023.4; 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) at a URL like:
http://localhost:8234/WebGoat
Where you replace 8234 with the port number you chose in the previous step. (If you don't include the /WebGoat, you may get a blank page or an uninformative error.) You'll have to create an account when you log in for the first time.
The main set of exercises we'd like you to work on in lab are the introduction to SQL and SQL injection that are found in the menu on the left side of the page under (A3) Injection > SQL Injection (intro). It starts with some basic questions that review different aspects of SQL syntax, but the questions are straightforward enough that you should be able to see what's going on from the provided examples, error messages, and a basic knowledge of SQL syntax, for instance as summarized in this site's table, this tutorial, or other places online.
One thing to note is that the SQL queries you'll be messing with all use single quotes around strings, which is the standard SQL syntax for strings. The double quotes you see next to them in some examples are the Java string syntax because the sample code for the program constructing the queries is Java code, using double quotes for strings and + for string concatenation. (Because the SQL standard assigns double quotes to an arguably less important purpose and database vendors have historically not followed the standard in all aspects, several "SQL" servers non-standardly interpret double quotes as an alternative string syntax, but not the one used by WebGoat.)
If you finish with the intro-level SQL injection module, you can go on to the advanced module, which discusses blind SQL injection and has a more difficult example. It's not important that you take the multiple-choice quiz that's the last page of the advanced section; confusingly it's actually mostly about mitigations. The module labeled mitigation mostly covers material that is beyond our scope, though you might still find parts of it interesting.