Transcript KarthickJayaraman_WebSecurity

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

How widespread is the
problem?


Automatic
compromise
It is a pandemic!.
Automated
detection
Problem sources

Nature of web
applications

Programmer errors
Manual
detection
2
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
3
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
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


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 userapplication interaction

Web applications are more complex

Average developer is not a secure expert

Difficult to get it right
7
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
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

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
11
HTTP Request Type

Solution

Transitions to nonsensitive states should
use HTTP GET

Transitions to sensitive
states should use HTTP
POST
12
HTTP Request Type


Consequences

Easy to understand – Requests are intention revealing

Weak first layer of defense

Increased complexity
Known uses

phpBB

punBB
13
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
14
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)
15
Secret-token Validation


Consequences

Strong defense

The session secret should be adequately strong and
appropriately protected
Known uses

phpBB

phpMyAdmin
16
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
17
Intent Verification

Solution

Introduce an additional verification step at the beginning of
each sensitive transaction

Additional authentication

CAPTCHA
18
Intent Verification


Consequences

Informed user

Better detection of bots

Hindered usability
Known uses

www.ebay.com

www.amazon.com
19
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
20
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
21
Guarded Workflow
22
Guarded Workflow


Consequences

Design by contract.

Hard to determine preconditions.
Known uses

Directed session pattern

Design by contract
23
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
24