Token Up - USENIX are going through XHR to /api For t h os e of you wh o d on' t d o f rontend work...
Transcript of Token Up - USENIX are going through XHR to /api For t h os e of you wh o d on' t d o f rontend work...
Token UpToken UpKeeping Hands out of theKeeping Hands out of the
Cookie JarCookie JarErin BrowningErin Browning
1
$whoami$whoami
3 . 1
Erin Browning
Senior Security Engineer
a.k.a., I'm a hacker
3 . 2
You can contact me at:
@efrowning
3 . 3
3 . 4
3 . 5
Slack is hiring!Slack is hiring!Slack is used by millions of people every day – we needengineers who want to make that experience as secure
and enjoyable as possible.
slack.com/jobs
3 . 6
All of the code-blocked frowning.wtf URLs arefake.
Please don't attack my website.
4
5
The ProblemThe Problem
6 . 1
I'm an attacker.
I want to take over accounts on your website.
6 . 2
Your site probably looks like this:
API: www.frowning.wtf/api
Frontend client: www.frowning.wtf
Mobile clients
6 . 3
Your sessions probably look like one or more of these:
JWTsRandomized session tokenAPI tokens
6 . 4
As you break your website out from a monolith tomicroservices, how do you store sessions/tokensbetween an API and your browser-based frontend
client?
6 . 5
Auth0's answer:
6 . 6
Is storing your auth in local storage that bad?
Let's find out.
6 . 7
In this talk:In this talk:Common vulnerabilities that execute in a browserModern application structuresHow to take advantage of browser-basedprotections
7 . 1
1UP1UP
7 . 2
Two common attacks
8 . 1
8 . 2
What is XSS?
Cross site scripting
8 . 3
Attacker created javascript is executed in the user'sbrowser in the context of site the user visited
More at: owasp.org/index.php/Cross-site_Scripting_(XSS)
8 . 4
How?
Injection!
8 . 5
Cannonical testing example:<script>alert(1);</script>
8 . 6
What can you do with XSS?
Steal cookiesTake actions as the userLike changing passwordsChange page content
8 . 7
8 . 8
What is CSRF?
Cross-Site Request ForgeryMore at: owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
8 . 9
Forces a user to perform actions they didn't intend ona website to which they're authenticated
8 . 10
How?
By default, cookies are included in requests sent crossdomain.
8 . 11
8 . 12
8 . 13
What do these attacks have in common?
8 . 14
All of these attacks execute in the user's browser
8 . 15
How are these attacks different?
8 . 16
XSS > CSRF
8 . 17
8 . 18
How can we reduce the impact of these attacks?
9 . 1
9 . 2
First, let's talk about a typical application structure:www.frowning.wtf - contains your frontend +any monolith codewww.frowning.wtf/api - apiwww.frowning.wtf/admin - administrator site
10 . 1
10 . 2
Where is your authentication stored in the browser?
10 . 3
Probably in a cookie
That cookie is probably scoped to *.frowning.wtf
If not, it'll be in local storage, placed there by yourjavascript
10 . 4
Interactions are going through XHR to /apiFor those of you who don't do frontend work:
XHR is an API called XMLHttpRequest.It lets you transfer data between a web browser running JS
and a server without reloading the page.
10 . 5
Traditional CSRF protection stores a random token in aform in an HTML page.
That token gets stored on the server as well.
When the form is submitted, the token is sent with theform data and validated on the server.
10 . 6
Your API may be using a CSRF token, or it may just berelying on monolith form CSRF protection--aka, your
api may be vulnerable.
10 . 7
Improvement: use subdomains
11 . 1
Now you have:
api.frowning.wtfwww.frowning.wtfadmin.frowning.wtf
11 . 2
You can scope cookies to www, admin and api insteadof using *.
The API cookie can have the secure and HTTPonly flagsset.
Secure means that cookie will only be sent over HTTPS
HTTPonly means js can't touch it
Yes, the names are confusing, so remember: for HTTPonly, only HTTP requests can accessthe cookie.
11 . 3
You XHR your requests to api from www.
11 . 4
How do you even do CSRF protection to your API?
11 . 5
Depends on ~content types~
multipart/form-datatext/plainapplication/x-www-url-form-encodedapplication/jsonapplication/xml
11 . 6
multipart/form-data, can go cross origintext/plain, can go cross originapplication/x-www-url-form-encoded,can go cross originapplication/json, can't go cross origin withoutCORSapplication/xml, can't go cross origin withoutCORS
11 . 7
What is CORS?
11 . 8
We care about CORS because of the protection offeredby the Same Origin Policy (SOP).
11 . 9
What is the Same Origin Policy?
Lots of requests can't be made from URL1 to URL2 ifthey differ on the following things:
Protocol (e.g., HTTP vs HTTPS)PortHost
11 . 10
CORS must be set on the assets you are accessing.
11 . 11
How do you reduce the impact of XSS?
API isn't running js.
www could still be vulnerable, and the site could sendrequests through XHR.
11 . 12
Improvement: use iFrames
12 . 1
Instead of using CORS, create an iFrame on www toapi.
Use the window.postMessage APIdocs at developer.mozilla.org/en-US/docs/Web/API/Window/postMessage
12 . 2
window.postMessage() enables cross-origincommunication through DOM-based
Windows can send and receive messages from eachother through events.
events.
12 . 3
12 . 4
ALWAYS ALWAYS ALWAYS validate your origin
if (event.origin !== www.frowning.wtf)return;
// .. otherwise do some stuff
12 . 5
Improvement: use websockets
13 . 1
Verify your Origin header.
13 . 2
The attacker would need to fake the origin header inthe victim's browser.
Modern browsers don't let you set your own originheader.
13 . 3
Common problems:
Sites don't check auth before upgrading theconnection. The protocol upgrade request will haveaccess to the browser's cookies. Therefore, checkauth when upgrading.
13 . 4
Similarities
iFrames and websockets both have trustworthy originsin the browser.
14 . 1
Ultimately, how can you avoid CSRF hitting your API?
By dropping all requests to API that aren'tapplication/json
14 . 2
How can you avoid XSS?
You can't completely.
14 . 3
Should you store auth in local storage?
Not unless you're sure you can prevent XSS.
14 . 4
How do you know you have a good understanding ofall this?
Tell me why XSS is worse in all these cases.
14 . 5
Special ThanksSpecial Thankslvh @latacora
Leigh Honeywell @tallpoppy
The latacora team
The Product Security teams @Slack
15 . 1
see you on the internet bb
16