This is the last in a series five posts for the vulnerable web application Hacme Books.
Broken Access Control
Access control is one of the major security concerns in any application. Elevated access to a system may result in disaster ranging from lost data to bringing the system down for some time. It is possible to overlook the access control scenarios that are horizontal in nature. Most developers effectively check for administrator privileges within the escalated code blocks.
In this case, I, as an attacker, will try to look at my profile or any previous order. When I check my profile I would not be logged on to the system with my used id and password but I will break in without an authentication token.
If we look at the application, there is a major problem in the ‘Forgot Your Password’ option. The screen does not ask for any information from the user except the username. In a real-time application it might not be a problem because the password may be sent using a different channel such as e-mail, but in this case the problem is that the attacker comes to know that database interaction is taking place just with one reference to the user name. This has the ability to cause a serious security issue.
Sometimes the developers might leave comments in HTML code that is in JSP. Often the confusion is mistaking HTML for JSP comments. To start this attack we need some additional information. We will need to have a couple of user accounts on the system and will need to complete a couple of purchases. This will generate the seed data for the underlying attack.
The accounts must be created on the system so it is obvious that we will create bogus accounts, here I am going to create two accounts named test and hacker.
First I will logon with the test account, we have not made any purchase using this account, so if we click on view orders we will see the screen with message that explains that this user has never purchased anything.
Browse Orders Screen for user ‘Test’
Now we will try to see the records for the other user name that we created, because nothing has been purchased by the ‘test’user, we’ll try getting information for the other user ‘hacker’. To do this we just go ahead and modify the contents of the address bar to point the other user we want to see the orders for.
Insecure Direct Object Reference
The url to view the previous orders of user with user name ‘hacker’ would be:
http://localhost:8080/HacmeBooks/browseOrders.html?userId=hacker this will display all the previous orders by the user ‘hacker’. So the theory was correct and we were able to bypass the access token needed to view the previous orders placed by a user. If we have a look at the result, the screen contains the credit card numbers as well that can be misused.
Retrieving the other User Data
This attack scenario highlighted two major problems during working with this application. The first was that developer left comments in source code that provided the attacker with the clues necessary to launch the attack. In fact, that was the platform to launch the attack.
Second, there is no horizontal privilege check. So instead of the user who made purchases, the attacker was able to view the data by sending a manipulated http request in URL of the application page. This is a classic example of the OWASP Insecure Direct Object Reference web vulnerability.