Two posts ago, I wrote a quick post about installing OWASP’s Broken Web App.
This post will be about exploiting the BWA and by that I mean I’m sharing my experience following existing proof of concepts and walkthroughs. For example, reported vulnerabilities from sourceforge and video walkthroughs on irongeek.com. This post assumes you have the OWASP BWA virtual machine up and running and that your target VM’s IP address is mapped to owaspbwa.com in /etc/hosts of your attacking VM.
I’ll do my best to give a complete list of information for each hack. Including where to go, what to do, how to exploit, and why the exploit is a thing.
List of exploiting vulnerabilities by type
Cross Site Scripting (XSS)
Reflected XSS in URL
- action: Click on Learn in the navbar. The click on one of the Papers listed on that page.
- exploit: Change a value to
<script>alert(1)</script> so the url might look like
reflected XSS in search keywords
- action: Search for something like “foobar”.
- description: Variables stored in the url can be modified like above
- exploit: Replace your keyword with the XSS script from 1.
- action: Log in, view an image, and leave a comment.
- description: If there is a lack of validation, you can write code and leave that in your comment.
- exploit: Use a script while writing your comment. A fun one is
<script>x=prompt("Want to play a game?");document.write(x);</script>
- action: Log in
- description: If users are stored in a database, a query is comparing the existing users to the parameters you give. This can be manipulated into whatever you need, even logic that overrides a password
- exploit: Leave the password blank and use
' or 1=1– -&password=aaa as the username
Enumerate useful information which may lead to discovering more crtical vulnerabilities
- action: View a picture
- description: URLs sometimes contain parameters that become SQL queries. These can be manipulated as well
- exploit: Replace the value of the pic id in the URL and make it
-1 union all select 1,2,3,@@version
- View directory contents, not webpages
- action: Try to find common directories that are used in web apps like images/ css/ or config/
- description: Some web applications are not properly configured to stop a user from viewing all the contents in a folder
- exploit: Append to the end of the URL a directory you want to travel to. such as images/
Add or remove accounts (without admin credentials)
- action: Log in to admin (admin/admin), view the account tab and add a new user foo. Re-log in as user (user/user)
- description: Without proper authorization, a regular user could act as an admin
- exploit: Append
index.php?action=account&deleteuser=someoneiwanttodelete to the end of the url
View other user’s data
- action: Log in to a user (bryce:bryce) and click the link “view your uploaded pics”
- description: The action describes the intended use of the functionality. However look in the url, the only thing making sure you are viewing your pictures is the id. What if you changed that id?
- exploit: Modify userid to a different value to see someone else’s uploaded images
Direct Object Reference
- View any user like they were your friend.
- action: Log in and view some on your friends
- description: An account may only be friends with 20 or so other users. They don’t have direct links to users who aren’t friends, so that user can’t see non-friends right? Wrong. Each user is directly referenced by their ID
- exploit: Change the ID in the URL to any number you like, most likely you won’t find a user because it’s random, but if you wrote a script, it could iterate through all the IDs and find every user
There are many possible vulnerabilites in web applications. This post has review Injection attacks, broken authentication, and misconfigurations. OWASP tracks these kinds of vulnerabilities in the Top Ten project. Learn more about how to exploit these vulnerabilites there.