CYBE231 Lab 6 - OWASP

In this lab we were given an OWASP box that hosts a variety of websites that are intentionally vulnerable. Since attacking these web apps could cause damages, we made a snapshot at the beginning to be able to revert to if needed. To start the lab we were given of example of SQL injection that we used to get logged into a bank account. It was something very simple password' OR '1'='1' and were able to get logged in. We then had to go find another vulnerable site of our own. I decided to go to the Damn Vulnerable Web App SQL injection page, to see what I could do. I ended up finding that user search box was vulnerable to injection. The injection that I found to be the most useful was 1' OR 0=0 union select user(), version() #. Breaking this down, the first part 1' OR 0=0 closes the SQL statement that does the search, and the OR statement evaluates true to cause the next part to work. The second part union select user(), version() # uses built-in SQL function to get the user running the statement, and the operating system version. These two things are then combined in a union since the output is look for a pair of data types. The ending # comments out the rest of the SQL statement and prevents the rest of the call from breaking our own SQL statement.

Doing so, gets a result that looks like this:

The next thing that we did was go back to the banking app, and take a look at the search bar on it. We saw this was also vulnerable to injection and would print our queries to the database, where we used it to read out all the “remember_me” cookies that kept users logged in. Using these cookies, we were able to change our own cookie, and login as another user, which we then used to send money from one user to another as proof that we had full control. We were then asked to find a cookie vulnerability on another site. I decided to go the Damn Vulnerable Web App Cookie page. This page gives a pair of logins that can be used webgoat, and ascpect, and told to get in as alice. Logging in with those users gives us the cookies, 65432ubphcfx and 65432udfqtb respectively. Seeing that first parts are the same, we can assume that that is the same across all users, with the second half being the username backwards, then shifted up 1 letter. We used these to create our own cookie for alice. It was 65432fdjmb which allowed us to login as alice and act like her.

For the final vulnerability in the lab we worked on Cross Site Scripting. Going back to the bank site, we could put in our own information in the about section of our profile that shows up when someone searches for a user. To test if it was vulnerable to XSS we made it <b>MONEY</b>, so that it would render bold if the field was interpreted as HTML, and not escaped properly. Going back to the search page, we looked for our assumed name, and the word MONEY was rendered bold! The nex thting that we did was use this to create an alert of the user’s screen when searched. This worked also, and while these last 2 have been harmless, we moved int o using BEEF, to host a fake authentication page that we could load whenever a user searched for our name.

The final thing that we touched on in this lab was Burp Suite. How when it is acting as a proxy, it can be used to keep track and replay traffic of a website. Burp Suite can also be used to spider a site, and find non-listed pages on the site. In our case it found an uploads’ directory that contained uploads of all the user’s bank statements.