Paranoid Penguin - Get a Clue with WebGoat
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 127.0.0.1. 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 127.0.0.1 or localhost.
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.
And, now, you can log in to WebGoat. Simply point the browser you just reconfigured to http://127.0.0.1/WebGoat/attack (or http://127.0.0.1:8080/WebGoat/attack 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!
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.
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 www.owasp.org, 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!
|Speed Up Your Web Site with Varnish||Jun 19, 2013|
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
- Speed Up Your Web Site with Varnish
- Containers—Not Virtual Machines—Are the Future Cloud
- Linux Systems Administrator
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Non-Linux FOSS: libnotify, OS X Style
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Android's Limits
- Reply to comment | Linux Journal
1 hour 23 min ago
- Yeah, user namespaces are
2 hours 40 min ago
- Cari Uang
6 hours 11 min ago
- user namespaces
9 hours 5 min ago
9 hours 30 min ago
- One advantage with VMs
11 hours 59 min ago
- about info
12 hours 32 min ago
12 hours 33 min ago
12 hours 34 min ago
12 hours 36 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?