Paranoid Penguin - Get a Clue with WebGoat
Local Web Proxies: Good or Evil?
You need to use a local Web proxy in order to carry out many of the practice attacks in WebGoat. But the only thing that makes them “practice” attacks is the fact that you're running them against an educational Web application running on your own system. The very same tools and techniques can be used for good or evil.
As with any penetration-testing tool, it's up to you to use your local Web proxy responsibly and ethically. If you run WebScarab or Paros when interacting with somebody else's Web server, you may be breaking the law (for example, by probing the site or sending intentionally malformed requests), even if all you're trying to do is learn.
Unless you're being paid to conduct a legal, fully authorized penetration test, you should run these tools only on and against your own systems.
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”.
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).
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.
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.
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.
|Android Candy: Intercoms||Apr 23, 2015|
|"No Reboot" Kernel Patching - And Why You Should Care||Apr 22, 2015|
|Return of the Mac||Apr 20, 2015|
|DevOps: Better Than the Sum of Its Parts||Apr 20, 2015|
|Play for Me, Jarvis||Apr 16, 2015|
|Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites||Apr 15, 2015|
- Tips for Optimizing Linux Memory Usage
- DevOps: Better Than the Sum of Its Parts
- "No Reboot" Kernel Patching - And Why You Should Care
- Return of the Mac
- Android Candy: Intercoms
- Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites
- Designing Foils with XFLR5
- diff -u: What's New in Kernel Development
- Non-Linux FOSS: .NET?
- Consent That Goes Both Ways