CS 373 – Week 7

This week covered web security.

Lab 1

Lab 1 explored attacking web vulnerabilities using WebGoat. WebGoat is a deliberately insecure web application used to teach about web vulnerabilities. It is maintained by OWASP. After starting WebGoat on the Linux VM, we are able to navigate the web app and explore various lessons with interactive lab exercises.

The first attack we are exploring is Stored Cross Site Scripting. An XSS attack is when malicious code is injected into otherwise trusted websites and the injected code is used by another user. In this case we are exploring a Stored XSS attack, which means that the injected code is being stored in the web application database and served to other users.

We are given a web portal and logins for different users. We want to launch a stored XSS attack against the “Street” filed in the “Edit Profile” page from the user Tom, so that the user Jerry is affected by the attack.

After logging in as Tom, we edit his address in his profile so that it contains <script>alert(‘Hey Jerry’);</script> instead of a legitimate address. This will then be stored in the database so that when his profile is viewed, the script with be ran and print the alert.

We can confirm this by logging in to Jerry’s account and viewing Tom’s profile. See the above image.

The second attack we explored was the Improper Error Handling (Fail Open) Attack. We are given a login page that accepts a username and password. This challenge was difficult and I had to check out the hints to solve it. My first approach was to use the Tamper Data plugin we had installed for this lab to change the data being submitted, changing the Username, Password, and Submit fields in the POST. I also tried changing the Cookie and Referrer headers without success.

After looking at the back end Java code, it appeared that in the catch block we could be authenticated if a parameter in the form was omitted. Since there are also checks that the username is not blank, we must omit the password parameter. The full solution shows using a program called web scarab to modify the post request and delete the password parameter but I was not able to replicate this functionality in the Tamper Data plugin we installed.

So instead of deleting the Password parameter in the request itself, I went into the page inspector and changed the name of the Password parameter to NotPassword. Now, when the Java parser tries to retrieve the password parameter, it will throw an exception because it cannot find it, leading to the makeSuccess() function being called and webgoat being logged in.

The final attack in this lab was the Numeric SQL injection attack. The sample page include a drop down where we can select different cities in the United States and then print their weather data in a table. The site also shows the SQL query made to the database above the table.

When viewing the POST request in Tamper data, we can see that a station parameter is being sent to backend where a SQL query is being made to get information for that city. This parameter is being substituted at the end of the SQL query: “SELECT * from weather_data WHERE station = “. So, we can complete this query, add a semicolon, and then add a second query to print all the data in the table. Our new station parameter would be “101; SELECT * from weather_data;”.

Now the results page shows that our second query was made after the first and all the cities in the weather_data table are displayed. Interestingly, there are two cities not listed in the drop down that we now can see data for. In a production application, this kind of attack may lead to even more sensitive data being breached, such as user passwords or financial data.