1. Stateless Anti-CSRF
@johnwilander at Dagstuhl 2012
Germany

2. Stateless is Good
• Don't need to synchronize between
servers
• No bloated session objects on
servers
• REST

3. REST Constraint
Stateless
The client–server communication is further
constrained by no client context being stored
on the server between requests. Each request
from any client contains all of the information
necessary to service the request, and any
session state is held in the client.

4. Stateless
Double Submit
(CSRF Protection)

5. Double Submit
(CSRF protection)
Anti-CSRF value
as cookie ...
... and
request parameter

6. Double Submit
(CSRF protection)
cookie ≠
request parameter
Cannot read the
anti-CSRF cookie to
include it as parameter

7. Double Submit
(CSRF protection)
Anti-CSRF cookie can
be generated client-side
=> no server-side state

8. Demo Double
Submit

9. Are We Fully
Protected Now?

10. Are We Fully
Protected Now?
Of course not

11. The Other
Subdomain
https://securish.1-liner.org https://other.1-liner.org
Search
Buy!

12. The Other
Subdomain
https://securish.1-liner.org https://other.1-liner.org
<script>alert('XSS')</script> Search
XSS
OK
Buy!

13. The Other
Subdomain
https://securish.1-liner.org https://other.1-liner.org
<script> Search
$.cookie(
"doubleSubmitToken",
"knownValue",
{ path: "/",
domain: ".1-liner.org" });
</script>
Buy!

14. Demo Subdomain
XSS Double Submit
Bypass

15. I proposed some sort of
Triple Submit
CSRF Protection

16. Triple Submit
(CSRF protection)
Initial request of
rich internet app

17. Triple Submit
(CSRF protection)
Random HttpOnly cookie
Cookie value as
JavaScript variable

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

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

20. The 3rd Submit
• The server sets an httpOnly cookie
response.addHeader("Set-Cookie",
randomName a random randomValue + ";
with + "=" + name and random
value
HttpOnly; path='/'; domain=.1-liner.org");
• 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

21. The 3rd Submit
• The server sets an httpOnly cookie
with a random name and random
value
<script>
• The server tells the<%= randomValue %>;
var ANTI_CSRF_TRIPLE = client the value
of the random cookie, not the name
</script>
• The Client submits the name and
value of the cookie as a request
parameter

22. The 3rd Submit
• Cookie value as parameter
• The cookie name
• The cookie value

23. Can XSS overwrite
HttpOnly cookies?

24. Yes.
When a browser reaches
its limit for cookies for a
domain
it starts to delete older
cookies, including
Credit: http://webstersprodigy.net/2012/08/03/analysis-of-john-wilanders-triple-submit-cookies/

25. So the attacker can delete
the HttpOnly cookie(s)
this way and then set
them to a controlled
value,
effectively overwriting

26. var overflowCookieJar =
function() {
var name = "marker",
val = "markerVal",
counter = 0;
// Set an initial cookie as a marker
$.cookie(name, val,
{path: "/", domain: ".1-liner.org"});
// Set new cookies until marker is gone
while($.cookie(name) == val) {
$.cookie(name + counter++, val,
{path: "/", domain: ".1-liner.org"});
}
// Return number of cookies needed
return counter;
}

27. Demo Subdomain
XSS Triple Submit
Bypass

28. Overflow the
Cookie Jar
• Chrome 22: 150-180 cookies
needed
• Firefox 15: 150 cookies needed
• Safari 6: ≈1000 cookies needed

29. The Demo System is an
OWASP Project
1-liner.org