Paranoid Penguin - Get a Clue with WebGoat

Hack, analyze and learn from an intentionally insecure Web application.
Configuring Your Browser

You're almost ready to start WebGoat, but there's one last thing to do: configure your Web browser to direct all traffic to your local proxy (for example, WebScarab or Paros). This is done in precisely the same way as specifying a proxy server; to a Web browser, a local proxy and a proxy server are the same thing. The only real difference is that instead of a proper fully qualified domain name, you need to give the name localhost or the IP address Be sure to specify the correct port too—the one on which your local proxy is listening (8008 unless you changed it).

Figure 1 shows the proxy configuration screen in Firefox. Access this screen from the Edit menu: Edit→Preferences→Advanced→Network→Connection→Settings. This dialog is very similar in other browsers. If your browser's proxy configuration dialog has a proxy-exceptions field, like Firefox's “No Proxy for:” box shown in Figure 1, make sure this field is blank or that it at least does not contain the values or localhost.

Figure 1. Configuring Firefox for Proxy Use

Starting WebGoat

Now, you've got JDK 1.5, you've got a local Web proxy running, and you've reconfigured your browser to use the proxy. It's time to milk the goat!

To start WebGoat, open a bash shell in your terminal window program of choice (I'm still partial to plain-old xterm), and change your working directory to the one WebGoat unzipped into—/home/darthelm/WebGoat-5.0 on my system. You don't need to be logged in as root to start WebGoat, but you do need to start WebGoat with root privileges—for example, via sudo, so you will need root's password. Therefore, to start WebGoat listening on TCP port 80, issue this command:

sudo sh ./webgoat start80

If you're running Apache or some other process on TCP port 80 (though I don't recommend doing so), you can start WebGoat on TCP port 8080, with this command:

sudo sh ./webgoat start8080

In either case, you'll be prompted for root's password, and WebGoat will start up, logging startup messages and errors both to your shell and also to the file WebGoat-5.0/tomcat/logs/catalina.out. Note that you can run WebGoat safely in the background by appending an ampersand (&) to your startup command, but there's little point. Although you'll, thus, be able to issue other commands from the same shell, all those log messages still will make that particular shell nearly unusable. It's better simply to open another terminal window.

Using WebGoat

And, now, you can log in to WebGoat. Simply point the browser you just reconfigured to (or if you started WebGoat on TCP 8080). You'll be prompted for a user name and password. Enter “guest” for both values. If you receive the page shown in Figure 2, you're ready to go!

Figure 2. WebGoat Welcome Screen

If you don't see the screen shown in Figure 2, double-check your browser's proxy setting, make sure your local Web proxy is running, and check the terminal in which you started WebGoat for error messages. Also, make sure you used sudo to start WebGoat—you might think that using the start8080 command would make this unnecessary, as TCP 8080 is an unprivileged port, but I've never had any luck running WebGoat as an unprivileged process.

Once you get the welcome screen, click the Start WebGoat button to begin.

WebGoat Structure and Tips

The first lesson in WebGoat is an introduction to the WebGoat interface. It walks you through a simple HTTP transaction and gives you the opportunity to use WebGoat's various buttons: Hints, Show Params, Show Cookies, Show Java and Lesson Plans. The Hints and Lesson Plans buttons are particularly important (your local Web proxy is more useful for viewing HTTP parameters and cookies), but I find that Lesson Plan pop-ups don't render properly under KDE's Konqueror browser (they render fine in Firefox).

After the first lesson, the lessons in WebGoat tend to assume that prior to running WebGoat, you've done some studying of Web application security, by at least reading the report “OWASP Top 10 2007” (available from, in the “Top 10 Project” section). Therefore, I highly recommend you download the full PDF version of this report, read it carefully, and keep it available while you're running WebGoat.

Some of WebGoat's lessons are self-explanatory; the lesson text itself or the lesson plan tells you everything you need to know in order to complete the exercise successfully. Other lessons, however, are not as straightforward. The Hints button can help, but even then you may find yourself copying and pasting an attack string suggested in a hint, without really understanding how the attack works.

So my other piece of advice, besides reading “OWASP Top 10 2007”, is to feel free to jump around between lessons. They are not presented in order of difficulty, nor do later lessons build on earlier ones, as far as I can tell. If a given lesson is too hard for you, feel free to try a different one instead. You always can try the harder lesson again later.

This doesn't mean WebGoat is poorly organized; it just means that the lessons are nonsequential, being instead grouped by type (Code Quality, Invalidated Parameters, Buffer Overflows and so forth). In summary, you will have a much more positive WebGoat experience if you first read the “OWASP Top 10 2007”, attempt whichever lessons strike your fancy, paying attention to each lesson's Lesson Plan button, and click the Hints button as necessary. And, if all else fails, there's always Google!



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

sudo and root password

waynorthny's picture

Mick ---

Thanks for a good hands-on article on securing web apps. As you point out, this is one of the most important security challenges facing Web sites (and Web users) today.

One quibble, though. In the "Starting WebGoat" section, you twice mention that invoking sudo requires knowledge of the root password. Not so! The various *buntu distributions are a case in point: the root password is randomly assigned by the installer and not made available. However, the /etc/sudoers file is configured so any user in the "admin" group can use sudo to perform administration --- by supplying their own password, not root's.