Difference between revisions of "OWASP ModSecurity Securing WebGoat Section4 Sublesson 02.3"

Revision as of 03:46, 30 November 2008

2 Access Control Flaws -> 2.3 LAB: Role Based Access Control

Lesson overview

The WebGoat lesson overview is included with the WebGoat lesson solution.

Lesson solution

Refer to the zip file with the WebGoat lesson solutions. See Appendix A for more information.

Strategy

In this WebGoat lab, each role has permission to certain resources (A-F). Each user is assigned one or more roles. Only the user with the 'Admin' role should have access to the 'F' resources but there is a vulnerability where the user doesn't need the 'Admin' role can access these 'F' resources; this is exploited by intercepting a request in a web proxy and altering the Employee ID number.

The WebGoat solution is to modify the back end source code and add an 'isAuthorized' method.

A ModSecurity solution would be to Lua-persist the Role Based Access Control configuration to 2 *.data files. In essence, the 'isAuthorized' method is implemented within ModSecurity instead of the WebGoat source code.

Implementation

One *.data file would contain a list of roles with the resources that they have access to, something like this:

Entry{ 
  role = "Admin",
  resources = "A,B,D,F"
} 

Entry{ 
  role = "User",
  resources = "A,B,C"
}
...

The second *.data file would contain each user and their roles:

Entry{
  employee_id = 101,
  roles = "User, Manager"
}
...

ModSecurity would intercept the request and call a Lua script which would determine if the request to the resource was valid or not.

Comments

• In the real world, a web interface would serve as a front end to the *.data files.