I came across the perfect hands on learning tool that teaches about the common web application vulnerabilities. It’s called WebGoat, an open source J2EE insecure web application created by OWASP. The purpose of WebGoat is to educate people and organizations on the various risks that are, unfortunately, plaguing our websites. What better way to learn about website hacking than to hack an insecure website with different known exploits. WebGoat has different lessons and some hints that guide the student. It’s a great, fun way to learn web application security. You can be up and running with WebGoat in no time by downloading a zip file that contains the WebGoat code, the Java run time environment and a configured Tomcat 5.5 server. Tomcat is a free Servlet container that implements Java Servlets/Jsp specification. Tomcat also contains a Java webserver. I chose to download the war file and import it into my Java IDE, called Eclipse, so I can analyze the source code. I put my Mac to the challenge; running Eclipse and Tomcat. Using the Mac turned out to be such a pleasure since everything installed and ran smoothly. After installing and configuring everything, I was able to start the Tomcat server from Eclipse and then point my Firefox browser to http://localhost:8080/WebGoat/attack and run the WebGoat application.

Databases are typically used as the back end to web applications. SQL is a query language that is used to interact with the database. SQL Injection is a common web application “vulnerability” that allows an attacker to send data to the back end database. This “string” is then inserted into an SQL query within the application code and executed in the database. If an SQL injection vulnerability exists, then the application may be severely compromised. In some cases an SQL Injection flaw may even allow an attacker to bypass authentication schemes.  In the below WebGoat lesson the student, acting as the attacker, needs to craft some “string” that, when submitted as the “password”, allows access.

 In order to proceed with the hack we will need to alter the HTML or submit the form and intercept the request in order to modify the password field. We can alter the HTML file locally on our computer and then modify the HTML code. We will change the password field to type=’text’ in order for us to see what we type. We will also change the size of the input field (currently it’s only allows 8 characters). A quicker way I found to do this was to use an awesome “Plugin” to Firefox called Firebug that allowed me to modify the HTML on the fly. The other way to proceed with the hack would be to use a tool called WebScarab to manipulate the data passed back to the server. Notice in the screen shot below that you can now see what I typed in the password field instead of asterisks. Also, my password field now allows 30 characters. 

Here is the altered HTML in case you can’t see it :

<input type=”text” maxlength=”30” size=”30” name=”password”/>.

Why did the “password” I used admin or ‘1′=’1 allow me to logon and bypass the authentication? We need a little background first on basic authentication for websites. The “password” supplied by the user needs to be verified that. indeed, it is the correct password for this user and whoever is logging on is who they say they are. This is done by querying the database and passing the supplied “password” as a parameter to the query. Here is a simple SQL statement that might be constructed in a web application:

SELECT * FROM user_data WHERE password = ‘?’ and username=’admin’

If the query returns the record from the user_data table then we have a match on the user’s supplied password. If there is no match, then the authentication should fail and a message should be sent back to the user as “Login Failed”.

Now let’s substitute the “password” I supplied into the query:

SELECT * FROM user_data WHERE password = ‘admin’ or ‘1′=’1′ and username=’admin’

The or ‘1′ = ‘1′ makes the entire query true, which returns the user admin record and bypasses the logon scheme. With this crafty string we have successfully exploited the SQL injection vulnerability. SQL injection vulnerabilities are remedied by sanitizing the user supplied input. In the above example, if the server side code had some kind of logic to reject the single quote, our method of attack would have been foiled. In fact, there should be a series of validations for the characters that are white-listed versus those that are not allowed and in this way, an invalid character would be stripped out. The fundamental concept here is that only server side code can thwart attacks such as the SQL injection since, as we demonstrated, the client side code can be easily modified. That’s why it is essential that all input validation is performed on the server side. With some knowledge of these types of attacks and diligence at the development phase, SQL injection vulnerabilities can be avoided.