In an earlier post, I mentioned that I was going to learn more about testing web application security and share my experiences here. I’m using a tool called the OWASP WebGoat Project to learn some of the basics of testing web application security.

The first lesson that I completed covered vulnerabilities in role-based security. Specifically, it explained how hackers can bypass both display layer and data layer role-based security, and it explained what programmers can do to protect against that particular vulnerability.

Typical Role-Based Security Tests

Most business software that I’ve tested has some sort of role-based security. Typically, some users may be able to edit data while others may only be able to view data. Some users may only be able to see data about themselves while others may be able to see data about everyone in the company.

On these projects, it’s common for the business analyst to make a chart like the one below to describe the permissions for each role.

Functional testers will typically log in to the system as a user in each role and ensure that they only see the appropriate functions and data on the screen. Once all of these roles and functions are verified, the test has passed.

However, by using WebGoat, I found that a hacker may be able to easily bypass role-based security even if the standard functional tests pass. Fortunately, it’s not particularly difficult to test for this vulnerability or to write code to protect against it.

How Do They Do It?

If you understand how hackers bypass role-based security, you can easily test that the code prevents the hack. Of course, this is just one of many ways that hackers can exploit security vulnerabilities, but we need to start somewhere.

Warning: OWASP warns that you should not try these techniques on any production server without explicit permission. They warn that you can lose your job and even go to jail if you use these techniques on production servers without permission. They created WebGoat as way to legally learn these techniques for testing purposes.

Proxies

A key tool used by hackers is called a proxy. Basically, this is a tool that captures information passed to and from your browser. The proxy displays the information that is passed and allows you to change it before it reaches its destination. The proxy that I chose to use is called Burp Proxy which I found on a list of test tools recommended by OWASP. One of the proxy tools, called WebScarab, was actually developed by OWASP.

Bypassing Business Layer Role-Based Security

The first exercise demonstrated how to bypass business layer, role-based security using a proxy. If you want to know all the details, you’ll need to download WebGoat. However, here’s a summary of what I learned.

1) When logged in as a basic user, “Tom Cat”, there is not a button displayed for deleting a profile. Ordinarily, a functional tester would conclude that the role-based security test passed.

2) A tester can click on “ViewProfile”. Then, using a proxy, can capture the parameters that are sent to the server. You can see that an employee ID and an action are passed to the server.

3) In this case, it’s an easy guess that the action for deleting a profile is called “DeleteProfile”. The tester can simply edit the action and pass that along.

4) After the command completes the round trip, the profile is deleted. This is true despite the fact that the tester was not able to see a DeleteProfile button on their screen.

Bypassing Data Layer Role-Based Security

In the above case, the tester was able to perform a function that violated role-based security. In this case, the tester will be able to view data that violates role-based security.

1. The first screen that the tester sees is the same as above. “Tom Cat” can only see his own data.
2. The tester then clicks on ViewProfile and sees the same parameters as in the proxy above. Note that the employee_id = 105.
3. The tester can then simply change the employee_id to something else. It seems reasonable that IDs might be in chronological order, so the tester may try an ID of 106.
4. After the command completes the round trip, information for a different employee is displayed.

How to Protect Against Role-Based Security Vulnerabilities

The key to preventing this specific security vulnerability is to ensure that the code double-checks authorization levels before sending any information to the browser. This needs to be done at both the business layer and the data layer. Once the tester identifies the issue, the developer should be able to correct it. If they’re not sure how to correct it, they can find additional information on the OWASP website.

Remember that this test only identifies one of many possible security flaws in a web application. Identifying and fixing this vulnerability should not give you a false sense of security. It does, however, close off one possible attack.

Your Experiences

I’d like to hear about your experiences with role-based security testing. Have you ever tested with a proxy? Have you ever had someone violate role-based security using a proxy or other tool?