Modeling User Interactions for Fun and Profit Preventing

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 CSE 776 Design Patterns, Summer 2010

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

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

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

Cross-site Request Forgeries 5

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

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

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

The Web DFA Model 9

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

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

HTTP Request Type l Solution l l Transitions to nonsensitive states should use HTTP GET Transitions to sensitive states should use HTTP POST 12

HTTP Request Type l l Consequences l Easy to understand – Requests are intention revealing l Weak first layer of defense l Increased complexity Known uses l php. BB l pun. BB 13

Secret-token Validation l Forces l l l 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 14

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

Secret-token Validation l Consequences l l l Strong defense The session secret should be adequately strong and appropriately protected Known uses l php. BB l php. My. Admin 16

Intent Verification l Forces l l l 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 17

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

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

Guarded Workflow l Forces l l l 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 20

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

Guarded Workflow 22

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

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