Access Control Rules Tester

1. Access Control Rules Tester • Andrew Petukhov • Department of Computer Science • Moscow State University • petand@lvk.cs.msu.su

2. 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

3. Web Security group at Computing Systems Lab, Moscow State University MSU Computer Science faculty students who participate in our projects: GeorgyKlimov, Edward Toroschin, Denis Zalivin, Alexander Mischenkko • Andrew Petukhov Igor Konnov Dmitry Kozlov

4. 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)

5. What is flawed access control?

6. What is flawed access control? -- continued --

7. What is flawed access control? -- continued --

8. 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

9. 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

10. 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

11. Sitemap Building Workflow

12. Access Control Testing Workflow

13. 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

14. 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!!!)

15. Thank You! Any questions?