Web applications remain the largest security risk for any company.
The reason is two-fold. First, most software services have moved to a web based environment giving malicious hackers a much larger landscape to attack. Second, most organizations put a majority of their resources, i.e. dollars and manpower, into network and perimeter security leaving the web unguarded.
In most cases, it is up to the web developer to secure sites as best they can. Those who know how to patch known vulnerabilities in the code they use find their services in constant demand.
For most developers, securing the sites they build is applying best practices that they are already aware of to the areas of their sites that are commonly exploited. So web application security is not so much about learning a new skill set as it is knowing where a web application is most vulnerable.
To help find vulnerabilities in their code web developers can turn to called WebScarab.
Introducing WebScarab
WebScarab is a Java based tool maintained by OWASP (The Open Web Application Security Project) used for intercepting and requests and responses between a browser and HTTP/S server. Using the fuzzer tool, you can find possible vulnerabilities in your web site’s code.
So to begin this tutorial, let’s go ahead and download WebScarab from here.
We also need to create a dictionary to use when we carry out a mock attack later on so open up a text editor and enter the line,‘) OR 1=1–. Save the file with the name attack.txt.
Note: WebScarab will look to the dictionary and try each of the contents as a username or password when trying to attack a website. A real attack dictionary will contain many more lines to increase the odds that the attack will be successful. We know that this SQL Injection code will work against the Hacme Casino so in the interest of time it is the only entry in our dictionary.
Next you are going to have to configure your web browser so that you can capture the requests and responses. To do this, you will have to set the proxy settings of your browser as follows:
- HTTP – localhost
- SSL (Secure) – localhost
- Port (for both) – 8008
The No Proxy for box in Firefox should be cleared. Likewise, the Exceptions box in Internet Explorer should be empty.
So if you were using Internet Explorer you should see:
Now that your browser is set, you are ready to get started.
But before you go plugging away at your web site, it would be wise for you to see just how WebScarab works. To do this, we are going to learn on a web site set up with vulnerabilities built into it for training purposes.
The Hacme Casino site was built by Foundstone just for this purpose. What is nice about the Casino site is that is has a built in web server so you can run it directly from any Windows computer without having to install a web server.
You can grab a copy of that from McAfee here.
Fuzzing for Vulnerabilities
Now that you have all the tools you need let’s see just how easy it is to find security holes in a web site. Start off by launching WebScarab. You are only going to see two tabs at this point, Summary and Intercept. Since we are looking for a bit more information, we are going to click on Tools à Use full-featured interface à Ok. Then, restart WebScarab and start a new session by clicking File à New so that you can tell WebScarab where to save your session.
We can give WebScarab something to look for by launching the Hacme Casino web server from your computer and then opening the browser we configured earlier and typing http://localhost:3000 in the address bar.
After you hit Enter, you will see some activity in WebScarab as the page loads. Once the page is up, try to login. Since we are just trying to capture the conversation for right now, what we use as a username and password doesn’t matter so use something like login for both.
When you turn back to WebScarab, look for /account/login under the path. Here, right-click and choose Use as fuzz template.
Now we are going to see if the login section of this web site is vulnerable to an attack.
Click on the Fuzzer tab and then the Sources button at the bottom of the page. Browse to the attack.txt file we created earlier and select that. Be sure to include something in the Description (I used Test for this example) box and then click Add and then Close.
Now we need to tell WebScarab to use Test (or whatever you used as your description) as the Fuzz Source for both the user_login and user_password parameters. You can do that by simply clicking on Fuzz Source and selecting your file.
Note: For in-depth testing you would most likely have two separate files, one may contain common usernames like admin, user, etc. and the other file would contain passwords.
When everything is loaded, click on Start and you will see WebScarab testing the values listed in your attack.txt file for the username and password.
Note where the value for
user_loginand
user_passwordis
‘) OR 1=1--. The location will have changed from
http://localhost:3000, which is the home page, to
http://localhost:3000/lobby/games, which is what a user who successfully logged in would see. The reason they would see this is because this site is vulnerable to a MySQL vulnerability. If the location remains http://localhost:3000 then the attempt was unsuccessful because the exploit did not work.
WebScarab does take a bit of work because you have to tear through many different parts of your application by hand to see if they are vulnerable but it is far cheaper than spending thousands of dollars for some of the automated tools that aren’t as reliable.
