Paranoid Penguin - Get a Clue with WebGoat

Hack, analyze and learn from an intentionally insecure Web application.
Using WebGoat: a Sample Lesson

Because WebGoat is itself a tutorial, it would be redundant for me (and beyond the scope of a single article) to walk through every lesson. Similarly, Web proxies are too versatile and complex to explain fully here. (In the future, I may very well devote an entire article to them.) But, I can walk you through a sample WebGoat lesson, including correct proxy use, as an illustration.

One of my favorite WebGoat lessons is the one on fail-open authentication mechanisms. If it's possible to make a user-authentication transaction fail in a way that results in successful authentication, that authentication mechanism is said to “fail open”. Needless to say, this is not the way a secure access mechanism behaves! But, it's a common Web coding mistake.

WebGoat covers this under the “Improper Error Handling” section, in the “How to Bypass a Fail Open Authentication Scheme” lesson. To start this lesson, click the “Improper Error Handling” link on the left-hand frame of the WebGoat interface, and then click the “How to Bypass a Fail Open Authentication Scheme” link that appears below it.

In this lesson, you'll enter a user name and password, use your local Web proxy to intercept the resulting HTTP request before it reaches the server (WebGoat), edit the request and then send it on its way.

Therefore, you need to put your Web proxy into intercept mode (trap mode on Paros). Figure 3 shows WebScarab set up for interception—all you need to do is check the box next to “Intercept requests”. Paros is similar: click the Trap tab, and check the box next to “Trap request”.

Figure 3. Putting WebScarab into Intercept Mode

Now, whenever you navigate to a new Web page or submit a Web form, the resulting HTTP request will be intercepted and stopped by your local proxy, allowing you to alter the request before forwarding it on. (WebScarab will pop up an edit window in the same virtual desktop as your browser session; Paros won't, so you'll need to click on your Paros window manually.)

Continuing the sample lesson, you now can go back to your browser, and type in the user name webgoat and some arbitrary string for a password (Figure 4).

Figure 4. Entering User Name and Password

Be sure your local Web proxy is in intercept/trap mode before clicking the Login button. After you do, WebScarab will pop up an Edit Request window like the one shown in Figure 5.

Figure 5. Editing an Intercepted HTTP Request

And now, we work our magic. In this Edit Request window, click the Text tab, select the string Password=blobbo&, and delete it. That's right, we're erasing the entire Password parameter from our authentication submission. This should result in a failed authentication, right?

But, when you click the Edit Request window's Accept button and switch back to your browser, you'll see the screen shown in Figure 6.

Figure 6. The Attack Succeeded!

The attack succeeded: you just logged in without knowing, or even attempting to submit, a password! Before clicking on other links, you may want to turn off your Web proxy's intercept/trap mode; otherwise, you'll need to click the proxy's Accept button (Continue in Paros) repeatedly simply to navigate to and load the page.

The last thing you should do before leaving this lesson is, arguably, the most important: click WebGoat's Show Java button, and see exactly what coding errors led to this fail-open condition. You'll find WebGoat's code to be well-commented and easy to analyze, even if you're a novice programmer. Remember, the whole point of using WebGoat is not only to see what can go wrong, but also to learn how to prevent it from going wrong in the first place.



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.