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

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

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

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

5. Cross-site Request Forgeries

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

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

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

9. The Web DFA Model

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

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

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

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

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

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

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

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

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

19. Intent Verification Consequences Known uses Informed user
Better detection of bots
Hindered usability
Known uses

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

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

22. Guarded Workflow

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

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