Access Control Rules Tester

Andrew PetukhovDepartment of Computer ScienceMoscow State Universitypetand@lvk.cs.msu.su

Contents

•‘About box’•Motivation: what is flawed access control in web apps?

•Model: how do we view web application?•Method: how to detect inconsistency of access control?

•Implementation: the AcCoRuTe tool•Features and Limitations•Future work

Web Security group at Computing Systems Lab, Moscow State University

Andrew Petukhov

Dmitry Kozlov

Igor Konnov

MSU Computer Science faculty students who participate in our projects:

Georgy Klimov, Edward Toroschin, Denis Zalivin, Alexander Mischenkko

Our contributions to OWASP

• Python tainted mode (SoC 2007)

• Detecting Security Vulnerabilities in Web Applications Using Dynamic Analysis with Penetration Testing (AppSecEU08)

• Static analysis of Python web applications (SoC 2008)

• Teachable Static Analysis Workbench (SoC 2008)

• Access Control Rules Tester (SoC 2008)

• OWASP Site Generator Refresh (SoC 2008)

What is flawed access control?

What is flawed access control? -- continued --

What is flawed access control? -- continued --

Web Application Model

• Web application is not a simple union of Sitemaps available to its users

• Web application is indeed a State transition system:

• State is a set of all accessible resources through GET-requests

• States are changed by POST-requests called actions

• Access control rules are constraints on the set of resources and actions that should be available to particular user at certain time

• So how do we infer access control rules having the black-box scope of view?

• Assumption: if user is not presented a link to resource or action, he is not supposed to access it

Tasks of access control tester

• Be able to build a set of GET- resources and POST-actions accessible through HTML user interface to a user at a given web application state

• Given sets of accessible resources and actions (Ra and Rb) for two different users at certain web application state:

• Be able to verify whether inaccessible resources via user interface are indeed inaccessible through direct requests

• Issue direct requests for {Rb\Ra} while logged in as user a and for {Ra\Rb} while logged in as user b

• Be able to perform checks for different web application states for different users

Deliveries of the Project

• A formal model and algorithm for web application access control assessment

• A guide how to decompose web application into states and transitions

• A workflow how to build Sitemap for a given web application state

• A command line tool, which actually performs access control testing:

• Input: an XML file describing web application States and Transitions and Sitemaps representing each state

• Output: an HTML report (XML is in near future) specifying broken access control URIs and participating users

Sitemap Building Workflow

Access Control Testing Workflow

Features and Limitations

• Automatically maintains the logged-in state while performing access control testing, relogins after forceful session expiration

• Always submits current values extracted from the latest HTTP-responses (instead of recorded ones) for such parameters as session IDs, ASP.NET __EVENTVALIDATION and __EVENTSTATE variables. The set of non-replayable parameters is customizable

• 100% result on the HacMe Bank v2.0 web application

• No support for AJAX

• No support for multi-factor authentication

• No support for anti-automation (CAPTCHAs)

• Toilsome Sitemap building process for web applications containing JavaScript –based navigation and lots of forms

Future work

• Perform in-depth evaluation on real-world web applications

• Add XSD schema for WebApplication.xml and perform validation against it

• Make the tool generate XML reports, create XSLT transformation style sheets

• Implement GUI for creating WebApplication.xml file

• Fix mistakes in English in the documentation (need help form native speakers!!!)

Thank You! Any questions?