Web Application Security
Webgoat is a project designed and maintained by the Open Wide Application Security Project (OWASP) organization. It is a deliberately insecure web application designed to demonstrate the possible security flaws that can exist in a web application and the significance of testing and protecting the applications against such flaws. It thus provides a testing platform to assess the security of a web application. The testing is done in the Black Box method of testing, and though the source code of the web application is not available, it can be downloaded and viewed. It consists of several lesson plans, among which we will focus on Cross Site Scripting and Blind SQL Injection. We will use the Java and Tomcat environment to run the web application.
The tools required for this application assessment are:
(1) Application Proxy, which enables the user (or tester) to check the data transmission between the Client (Application Browser) and the Server (Web Server). Here, the WebScarab Project by OWASP has been installed. You should have this proxy running when using WebGoat.
(2) Application spider to crawl through the webpages and links.
The Webgoat is available in the Internet for free download and can be downloaded from any site including code.Google.com and sourceforge.net . To start web server running, click "webgoat.bat" in the unzipped Webgoat directory. Launch the application by following the link, http://localhost/WebGoat/attack in the web browser. Apache Tomcat serves as the web server, and connection to the Internet must be removed since at this time, the host machine will be vulnerable to attack.
Cross Site Scripting
The lesson for Cross Site Scripting consists of executing stored Cross Site Scripting attack. The various stages are shown in the screenshots as follows.
In the first stage, the attacker disguises himself as an employee ‘Tom’ and proceeds to update the street address in Tom’s profile with an update.
Next, this change is reflected when the HR, ‘Jerry’ logs in and views the profile of Tom.
The next stage is blocking the above attack using Input Validation, in the Developer version of WebGoat. The third stage is executing a previously stored XSS attack. It can be shown as follows.
We will alter the FreeBSD to Free in the employee Bruce’s profile. This change will be visible in the manager (David) records even though the fix from stage 2 is in place.
In the developer version of WebGoat, there is a fix for this using Output Encoding.
String SQL Injection can be used to bypass authentication. In the below form, we can login as the boss (Neville) by modifying the field “password” to evaluate to true no matter what, through WebScarab.
In stage 2, we implement a fix to ensure that the above SQL Injection attack does not affect anything. This can be done by parameterizing the query in the Login.java form of WebGoat lessons.
A similar injection attack can be achieved through numerical SQL Injection to bypass authorization and the lesson shows a fix for that too.
String SQL Injection can also be used to view Credit Card numbers of individual employees.
2. Google Gruyere
Google Gruyere is a web application, similar to WebGoat but does not use Tomcat. It is insecure, and allows user to create a dummy account, set up environments to store files and scripts. Its insecure feature helps the user learn the methods by which hackers exploit a web application over the internet, and how to defend against such hacker attacks. We can legally execute multiple types of attacks like Cross Site Script attacks against the Gruyere applications. We have demonstrated one such XSS attack during creating a new account. Here, by using a Proxy server, the user is able to disguise himself as the admin instead of any normal user. This is done by inserting and modifying some parameters in the URL field of the Http request sent to the server during the signup process. The steps for the same are as follows:
First, we must sign up for a new account in Google Gruyere as follows:
Intercept the packets/request via WebScabar as follows:
We add a parameter in the URL field ‘is_admin’ and set it to true, thus making ourselves the admin.
Thus we execute an XSS attack by altering the client resources in Gruyere via the application proxy WebScarab.