Modeling User Interactions for (Fun and) Profit Preventing Request Forgery Attacks in Web Applications Karthick Jayaraman, Grzegorz Lewandowski, Paul G. Talaga, and Steve J. Chapin Syracuse University CSE776 Design Patterns, Summer 2010

Motivation Web applications continue to be poorly built Automated detection Web applications continue to be poorly built How widespread is the problem? It is a pandemic!. Problem sources Nature of web applications Programmer errors Automatic compromise Manual detection Source: Web Application Security Consortium, 2008 Report

Motivation Several defensive coding techniques exist Difficult to get it right Average developer is not a security expert No “method” behind the madness Important : helping the developer

Preview Two important attacks Cross-site request forgery Workflow attacks Root cause – Failure to model intended interaction patterns A systematic methodology for building web applications

Cross-site Request Forgeries

Workflow Attacks Step 1 Step 2 Step 3 Step 4 Choosing a product Providing shipping information Providing payment information Final review, order completion Skipping step 3

Root Causes Attacks violate the intended user-application interaction CSRF: Request originates from a malicious site Workflow attacks: Attackers forces the application to process an incorrect request Lack of strict enforcement of intended user- application interaction Web applications are more complex Average developer is not a secure expert Difficult to get it right

A New Design Methodology Objectives Security by construction Systematic method for enforcing user-application interaction Two parts Modeling intended interaction patterns using the Web DFA model Four design patterns

The Web DFA Model

Design Patterns Pattern Description HTTP request type Choosing an appropriate HTTP request type Secret-token Validation Adding an additional verification step to distinguish requests originating from attacker site from genuine requests. Intent verification Adding an additional verification step to verify user-intent when using auto login. Guarded Workflow Systematic method for designing workflow transactions.

HTTP Request Type Forces Web apps should choose an appropriate HTTP request type for their request Choosing the wrong request can facilitate forgery Choosing the appropriate request is best done in design

HTTP Request Type Solution Transitions to non- sensitive states should use HTTP GET Transitions to sensitive states should use HTTP POST

HTTP Request Type Consequences Known uses Easy to understand – Requests are intention revealing Weak first layer of defense Increased complexity Known uses phpBB punBB

Secret-token Validation Forces HTTP Requests can be repeatedly issued Session cookies are insufficient for preventing forgeries because browsers enable malicious web sites to steal cookies Cryptographic secrets can be application and web pages

Secret-token Validation Solution Use a secret token whenever a sensitive request is made Add a secret token as a parameter to each form <input type=“hidden” name=sid value=“AS887AS9AS” /> Verify the presence of a secret token in sensitive requests Attacker cannot access the secret-token inside the web page. (Browser policy)

Secret-token Validation Consequences Strong defense The session secret should be adequately strong and appropriately protected Known uses phpBB phpMyAdmin

Intent Verification Forces Users do not know when they are tricked by an attacker into a CSRF attack Web applications should verify the intent of each submitted request Intent verification reduces the usability of the application

Intent Verification Solution Introduce an additional verification step at the beginning of each sensitive transaction Additional authentication CAPTCHA

Intent Verification Consequences Known uses Informed user Better detection of bots Hindered usability Known uses www.ebay.com www.amazon.com

Guarded Workflow Forces Subtasks in a workflow should be executed in a predefined order Attackers want to manipulate the normal execution order Subtasks have preconditions that the caller should satisfy before invocation

Guarded Workflow Solution Identify states participating in a workflow {subtask1 , subtask2 , ...., subtaskn } Identify preconditions and postconditions for each transition to the state. To enforce the sequence {subtask1 , subtask2 , ...., subtaskn }, postconditions1 ∪ postconditions2 ∪ .... ∪ postconditionsn-1 ⊂ preconditionsn

Guarded Workflow

Guarded Workflow Consequences Known uses Design by contract. Hard to determine preconditions. Known uses Directed session pattern Design by contract

Conclusion Securing web applications is more complex compared to desktop application Multiple and complementary approaches are required Better system-level techniques Better frameworks Crucial : Well engineered applications that are secure by construction