Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

A8

...

Cross-Site

...

Request

...

Forgery

...

(CSRF)

...

Without an unpredictable CSRF token, attackers can forge malicious requests. An alternate defense is to require the user to prove they intended to submit the request, either through reauthentication, or some other proof they are a real user (e.g.,

...

a

...

CAPTCHA).

...

Anti-CSRF

...

tokens

...

are

...

unique

...

for

...

each

...

session.

...

A

...

less

...

comprehensive

...

solution

...

is

...

to

...

include

...

anti-CSRF

...

tokens

...

with

...

a

...

high-value

...

transactions.

...

The

...

solution

...

works

...

by

...

appending

...

a

...

unique

...

token

...

to

...

the

...

user

...

session,

...

much

...

like

...

a

...

cookie.

...

XSS

...

combined

...

with

...

CSRF

...

can

...

be

...

used

...

to

...

do

...

anything

...

that

...

an

...

authenticated

...

user

...

can

...

do.

...

A.8.1

...

Prevention:

...

A

...

CSRF

...

attack

...

forces

...

a

...

logged-on

...

victim's

...

browser

...

to

...

send

...

a

...

forged

...

HTTP

...

request,

...

including

...

the

...

victim's

...

session

...

cookie

...

and

...

any

...

other

...

automatically

...

included

...

authentication

...

information,

...

to

...

a

...

vulnerable

...

web

...

application.

...

This

...

allows

...

the

...

attacker

...

to

...

force

...

the

...

victim's

...

browser

...

to

...

generate

...

requests

...

the

...

vulnerable

...

application

...

thinks

...

are

...

legitimate

...

requests

...

from

...

the

...

victim.

...

A.8.1.1.

...

Using

...

Synchronizer

...

Token:

...

The

...

preferred

...

option

...

is

...

to

...

include

...

the

...

unique

...

token

...

in

...

a

...

hidden

...

field.

...

This

...

causes

...

the

...

value

...

to

...

be

...

sent

...

in

...

the

...

body

...

of

...

the

...

HTTP

...

request,

...

avoiding

...

its

...

inclusion

...

in

...

the

...

URL,

...

which

...

is

...

more

...

prone

...

to

...

exposure.

...


The

...

unique

...

token

...

can

...

also

...

be

...

included

...

in

...

the

...

URL

...

itself,

...

or

...

a

...

URL

...

parameter.

...

However,

...

such

...

placement

...

runs

...

a

...

greater

...

risk

...

that

...

the

...

URL

...

will

...

be

...

exposed

...

to

...

an

...

attacker,

...

thus

...

compromising

...

the

...

secret

...

token.

...


OWASP'

...

CSRF

...

Guard can automatically include such tokens in Java EE, .NET, or PHP apps. OWASP's ESAPI includes methods developers can use to prevent CSRF vulnerabilities.

CSRFGuard must offer the capability to place the CSRF prevention token within the HTML produced by the protected web application. CSRFGuard 3 provides developers more fine grain control over the injection of the token. Developers can inject the token in their HTML using either dynamic JavaScript DOM manipulation or a JSP tag library. CSRFGuard no longer intercepts and modifies the HttpServletResponse object as was done in previous releases. The currently available token injection strategies are designed to make the integration of CSRFGuard more feasible and scalable within current enterprise web applications. Developers are encouraged to make use of both the JavaScript DOM Manipulation and the JSP tag library strategies for a complete token injection strategy. The JavaScript DOM Manipulation strategy is ideal as it is automated and requires minimal effort on behalf of the developer. In the event the JavaScript solution is insufficient within a particular application context, developers should leverage the JSP tag library. The purpose of this article is to describe the token injection strategies offered by OWASP CSRFGuard 3.

  1. Requiring the user to reauthenticate, or prove they are a user (e.g., via a CAPTCHA) can also protect against CSRF.
  2. Any state changing operation requires a secure random token (e.g CSRF token) to prevent against CSRF attacks
  3. Characteristics of a CSRF Token
    1. Unique per user & per user session
    2. Tied to a single user session
    3. Large random value
    4. Generated by a cryptographically secure random number generator
  4. The CSRF token is added as a hidden field for forms or within the URL if the state changing operation occurs via a GET
  5. The server rejects the requested action if the CSRF token fails validation
  6. In order to facilitate a "transparent but visible" CSRF solution, developers are encouraged to adopt the Synchronizer Token Pattern (http://www.corej2eepatterns.com/Design/PresoDesign.htm

...

  1. )

...

Examples:

...

  1. Include

...

  1. anti

...

  1. CSRF

...

  1. into

...

  1. the

...

  1. form

...

  1. field

...

  1. in

...

  1. a

...

  1. JSP:
    Code Block
    
    

...

  1. <html:form action="registration-submit">
    

...

  1. <html:hidden property="action"/>

...

  1. 
    <input type="hidden" name=<%=CSRFTokenUtil.SESSION_ATTR_KEY %>

...

  1. 
    

...

  1. Value=<%=

...

  1. CSRFTokenUtil.getToken(request.getSession(false)) %>>
    

...

  1. This

...

  1. creates

...

  1. the

...

  1. token

...

  1. if

...

  1. it

...

  1. doesn't

...

  1. already

...

  1. exist

...

  1. and

...

  1. includes

...

  1. it

...

  1. as

...

  1. a

...

  1. parameter

...

  1. into

...

  1. the

...

  1. HTML

...

  1. form.

...


  1. The

...

  1. next

...

  1. step

...

  1. is

...

  1. to

...

  1. include

...

  1. the

...

  1. mapping

...

  1. into

...

  1. the

...

  1. application:

...

  1. Code Block
    
    If (

...

  1. !CSRFTokenUtil.isValid(request.getSession(false), request)){

...

  1. 
    request mapping.findForward("error");
    

...

  1. }

...

  1. 
    

...

  1. When

...

  1. a

...

  1. Web

...

  1. application

...

  1. formulates

...

  1. a

...

  1. request

...

  1. (by

...

  1. generating

...

  1. a

...

  1. link

...

  1. or

...

  1. form

...

  1. that

...

  1. causes

...

  1. a

...

  1. request

...

  1. when

...

  1. submitted

...

  1. or

...

  1. clicked

...

  1. by

...

  1. the

...

  1. user),

...

  1. the

...

  1. application

...

  1. should

...

  1. include

...

  1. a

...

  1. hidden

...

  1. input

...

  1. parameter

...

  1. with

...

  1. a

...

  1. common

...

  1. name

...

  1. such

...

  1. as

...

  1. "CSRFToken".

...

  1. The

...

  1. value

...

  1. of

...

  1. this

...

  1. token

...

  1. must

...

  1. be

...

  1. randomly

...

  1. generated

...

  1. such

...

  1. that

...

  1. it

...

  1. cannot

...

  1. be

...

  1. guessed

...

  1. by

...

  1. an

...

  1. attacker.

...

  1. Consider

...

  1. leveraging

...

  1. the

...

  1. java.security.SecureRandom

...

  1. class

...

  1. for

...

  1. Java

...

  1. applications

...

  1. to

...

  1. generate

...

  1. a

...

  1. sufficiently

...

  1. long

...

  1. random

...

  1. token.

...

  1. Alternative

...

  1. generation

...

  1. algorithms

...

  1. include

...

  1. the

...

  1. use

...

  1. of

...

  1. 256-bit

...

  1. BASE64

...

  1. encoded

...

  1. hashes.

...

  1. Developers

...

  1. that

...

  1. choose

...

  1. this

...

  1. generation

...

  1. algorithm

...

  1. must

...

  1. make

...

  1. sure

...

  1. that

...

  1. there

...

  1. is

...

  1. randomness

...

  1. and

...

  1. uniqueness

...

  1. utilized

...

  1. in

...

  1. the

...

  1. data

...

  1. that

...

  1. is

...

  1. hashed

...

  1. to

...

  1. generate

...

  1. the

...

  1. random

...

  1. token.

...

  1. Code Block
    <form action="/transfer.do" method="post">

...

  1. 
    <input 

...

  1. value="

...

  1. OWY4NmQwODE4ODRjN2Q2NTlhMmZlYWEwYzU1YWQwMTVhM2JmNGYxYjJiMGI4MjJjZDE1ZDZ==">

...

  1. 
    </form>

...

  1. 
    

...

Caveats:

...

Disclosure

...

of

...

Token

...

in

...

URL

...

Many

...

implementations

...

of

...

this

...

control

...

include

...

the

...

challenge

...

token

...

in

...

GET

...

(URL)

...

requests

...

as

...

well

...

as

...

POST

...

requests.

...

This

...

is

...

often

...

implemented

...

as

...

a

...

result

...

of

...

sensitive

...

server-side

...

operations

...

being

...

invoked

...

as

...

a

...

result

...

of

...

embedded

...

links

...

in

...

the

...

page

...

or

...

other

...

general

...

design

...

patterns.

...

These

...

patterns

...

are

...

often

...

implemented

...

without

...

knowledge

...

of

...

CSRF

...

and

...

an

...

understanding

...

of

...

CSRF

...

prevention

...

design

...

strategies.

...

While

...

this

...

control

...

does

...

help

...

mitigate

...

the

...

risk

...

of

...

CSRF

...

attacks,

...

the

...

unique

...

per-session

...

token

...

is

...

being

...

exposed

...

for

...

GET

...

requests.

...

CSRF

...

tokens

...

in

...

GET

...

requests

...

are

...

potentially

...

leaked

...

at

...

several

...

locations:

...

browser

...

history,

...

HTTP

...

log

...

files,

...

network

...

appliances

...

that

...

make

...

a

...

point

...

to

...

log

...

the

...

first

...

line

...

of

...

an

...

HTTP

...

request,

...

and

...

Referer

...

headers

...

if

...

the

...

protected

...

site

...

links

...

to

...

an

...

external

...

site.

...

In

...

the

...

latter

...

case

...

(leaked

...

CSRF

...

token

...

due

...

to

...

the

...

Referer

...

header

...

being

...

parsed

...

by

...

a

...

linked

...

site),

...

it

...

is

...

trivially

...

easy

...

for

...

the

...

linked

...

site

...

to

...

launch

...

a

...

CSRF

...

attack

...

on

...

the

...

protected

...

site,

...

and

...

they

...

will

...

be

...

able

...

to

...

target

...

this

...

attack

...

very

...

effectively,

...

since

...

the

...

Referer

...

header

...

tells

...

them

...

the

...

site

...

as

...

well

...

as

...

the

...

CSRF

...

token.

...

The

...

attack

...

could

...

be

...

run

...

entirely

...

from

...

javascript,

...

so

...

that

...

a

...

simple

...

addition

...

of

...

a

...

script

...

tag

...

to

...

the

...

HTML

...

of

...

a

...

site

...

can

...

launch

...

an

...

attack

...

(whether

...

on

...

an

...

originally

...

malicious

...

site

...

or

...

on

...

a

...

hacked

...

site).

...

Additionally,

...

since

...

HTTPS

...

requests

...

from

...

HTTPS

...

contexts

...

will

...

not

...

strip

...

the

...

Referer

...

header

...

(as

...

opposed

...

to

...

HTTPS

...

to

...

HTTP

...

requests)

...

CSRF

...

token

...

leaks

...

via

...

Referer

...

can

...

still

...

happen

...

on

...

HTTPS

...

Applications.

...

The

...

ideal

...

solution

...

is

...

to

...

only

...

include

...

the

...

CSRF

...

token

...

in

...

POST

...

requests

...

and

...

modify

...

server-side

...

actions

...

that

...

have

...

state

...

changing

...

affect

...

to

...

only

...

respond

...

to

...

POST

...

requests.

...

This

...

is

...

in

...

fact

...

what the RFC 2616 requires for GET requests. If sensitive server-side actions are guaranteed to only ever respond to POST requests, then there is no need to include the token in GET requests.

In most JavaEE web applications, however, HTTP method scoping is rarely ever utilized when retrieving HTTP parameters from a request. Calls to "HttpServletRequest.getParameter" will return a parameter value regardless if it was a GET or POST. This is not to say HTTP method scoping cannot be enforced. It can be achieved if a developer explicitly overrides doPost() in the HttpServlet class or leverages framework specific capabilities such as the AbstractFormController class in Spring.

For these cases, attempting to retrofit this pattern in existing applications requires significant development time and cost, and as a temporary measure it may be better to pass CSRF tokens in the URL. Once the application has been fixed to respond to HTTP GET and POST verbs correctly, CSRF tokens for GET requests should be turned off.

A.8.1.2.

...

Without

...

the

...

Synchonizer

...

Token

A8.1.2.1

...

Checking

...

The

...

Referer

...

Header

...

Although

...

it

...

is

...

trivial

...

to

...

spoof

...

the

...

referer

...

header

...

on

...

your

...

own

...

browser,

...

it

...

is

...

impossible

...

to

...

do

...

so

...

in

...

a

...

CSRF

...

attack.

...

Checking

...

the

...

referer

...

is

...

a

...

commonly

...

used

...

method

...

of

...

preventing

...

CSRF

...

on

...

embedded

...

network

...

devices

...

because

...

it

...

does

...

not

...

require

...

a

...

per-user

...

state.

...

This

...

makes

...

a

...

referer

...

a

...

useful

...

method

...

of

...

CSRF

...

prevention

...

when

...

memory

...

is

...

scarce.

...

This

...

method

...

of

...

CSRF

...

mitigation

...

is

...

also

...

commonly

...

used

...

with

...

unauthenticated

...

requests,

...

such

...

as

...

requests

...

made

...

prior

...

to

...

establishing

...

a

...

session

...

state

...

which

...

is

...

required

...

to

...

keep

...

track

...

of

...

a

...

synchronization

...

token.

...

However,

...

checking

...

the

...

referer

...

is

...

considered

...

to

...

be

...

a

...

weaker

...

from

...

of

...

CSRF

...

protection.

...

For

...

example,

...

open

...

redirect

...

vulnerabilities

...

can

...

be

...

used

...

to

...

exploit

...

GET-based

...

requests

...

that

...

are

...

protected

...

with

...

a

...

referer

...

check

...

and

...

some

...

organizations

...

or

...

browser

...

tools

...

remove

...

referrer

...

headers

...

as

...

a

...

form

...

of

...

data

...

protection.

...

There

...

are

...

also

...

common

...

implementation

...

mistakes

...

with

...

referer

...

checks.

...

For

...

example

...

if

...

the

...

CSRF

...

attack

...

originates

...

from

...

an

...

HTTPS

...

domain

...

then

...

the

...

referer

...

will

...

be

...

omitted.

...

In

...

this

...

case

...

the

...

lack

...

of

...

a

...

referer

...

should

...

be

...

considered

...

to

...

be

...

an

...

attack

...

when

...

the

...

request

...

is

...

performing

...

a

...

state

...

change.

...

Also

...

note

...

that

...

the

...

attacker

...

has

...

limited

...

influence

...

over

...

the

...

referer.

...

For

...

example,

...

if

...

the

...

victim's

...

domain

...

is

...

"site.com"

...

then

...

an

...

attacker

...

have

...

the

...

CSRF

...

exploit

...

originate

...

from

...

"site.com.attacker.com"

...

which

...

may

...

fool

...

a

...

broken

...

referer

...

check

...

implementation.

...

XSS

...

can

...

be

...

used

...

to

...

bypass

...

a

...

referer

...

check.

...

In

...

short,

...

referer

...

checking

...

is

...

a

...

reasonable

...

form

...

of

...

CSRF

...

intrusion

...

detection

...

and

...

prevention

...

even

...

though

...

it

...

is

...

not

...

a

...

complete

...

protection.

...

Referer

...

checking

...

can

...

detect

...

some

...

attacks

...

but

...

not

...

stop

...

all

...

attacks.

...

For

...

example,

...

if

...

you

...

HTTP

...

referrer

...

is

...

from

...

a

...

different

...

domain

...

and

...

you

...

are

...

expecting

...

requests

...

from

...

your

...

domain

...

only,

...

you

...

can

...

safely

...

block

...

that

...

request.

...

A

...

8.1.2.2

...

Checking

...

The

...

Origin

...

Header

The Origin HTTP Header standard was introduced as a method of defending against CSRF and other Cross-Domain attacks. Unlike the referer, the origin will be present in HTTP request that originates from an HTTPS url.

If the origin header is present, then it should be checked for consistency.

A 8.1.2.3

...

Challenge-Response

...

Challenge-Response

...

is

...

another

...

defense

...

option

...

for

...

CSRF.

...

The

...

following

...

are

...

some

...

examples

...

of

...

challenge-response

...

options.

...

  • CAPTCHA

JSP implementation

Code Block

<tr>
<td><img src="Captcha.jsp"/></td>
    
<td>Please enter text seen in image
            <input name="captcha_text">
<></td>
</tr>Class implementation implementation&nbsp; Captcha captcha = (Captcha)
     Request.getSession(false).getAttribute(Captcha.NAME);
String answer = request.getParameter("captcha_text");
    
if (!captcha.isCorrect(answer))
{
                 Return mapping.findForward("error");
     }\\

While

...

challenge-response

...

is

...

a

...

very

...

strong

...

defense

...

to

...

CSRF

...

(assuming

...

proper

...

implementation),

...

it

...

does

...

impact

...

user

...

experience.

...

For

...

applications

...

in

...

need

...

of

...

high

...

security,

...

tokens

...

(transparent)

...

and

...

challenge-response

...

should

...

be

...

used

...

on

...

high

...

risk

...

functions.

...

  • Re-Authentication

...

  • (password)

...

  • One-time

...

  • Token

...

A.8.2.

...

References:

...

https://www.owasp.org/index.php/Top_10_2013-A8-Cross-Site_Request_Forgery_(CSRF)

...

http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/HTTPUtilities.html

...