Are you botching the security of your AngularJS applications? (DevFest 2016)

@PhilippeDeRyck
ARE YOU BOTCHING THE SECURITY
OF YOUR ANGULARJS APPLICATIONS?
Philippe De Ryck
DevFest 2016, Brussels, Belgium
https://www.websec.be

@PhilippeDeRyck
WHAT IS THE BIGGEST THREAT TO AN ANGULARJS APPLICATION?
DEVELOPERS (THAT ARE NOT SECURITY-AWARE)

@PhilippeDeRyck
KNOWLEDGE IS KEY TO BUILDING SECURE APPLICATIONS
§ My goal is to help you build secure web applications
− In-house training programs at various companies
− Hosted web security training courses at DistriNet (KU Leuven)
− Talks at various developer conferences
− Slides, videos and blog posts on https://www.websec.be
§ I have a broad security expertise, with a focus on Web Security
− PhD in client-side web security
− Main author of the Primer on client-side web security
− Part of the organizing committee of the SecAppDev course
§ I’m also a chef, so demo’s will be food-related!

@PhilippeDeRyck
CROSS-SITE SCRIPTING (XSS)
§ In an XSS attack, malicious content is injected into your application’s pages
− In the “original” XSS attacks, an attacker injected JavaScript code
− Today, injected content can be JavaScript, CSS, HTML, SVG, …

@PhilippeDeRyck
https://www.youtube.com/watch?v=K0noqLisW_c

@PhilippeDeRyck
§ The real problem is that injected content runs in your context
− Complete access to your client-side data and code
− Ability to use any permissions the user has granted to your application
− The full power of XHR to contact your backend, in the name of the user
§ XSS attacks are very powerful, and unfortunately very common
− XSS is ranked 3rd in the OWASP top 10 and 4th in the SANS top 25

@PhilippeDeRyck
http://colesec.inventedtheinternet.com/beef-the-browser-exploitation-framework-project/

@PhilippeDeRyck
HOW DO YOU PROTECT AGAINST XSS?
§ The root cause behind XSS is confusion between data and code
− Untrusted data is mixed with trusted code, and sent to the browser
− The browser will never know which part is data and which is code
<div><h3>
Your search for
“<i>Crazy Cats<script>alert(“Miauw!”)</script></i>”
returned 5 results
</h3></div>
<div><h3>
Your search for “$query” returned $count results
</h3></div>

@PhilippeDeRyck
§ The server needs to render the data harmless
− By escaping “dangerous” parts in the data
<div><h3>
Your search for “encode($query)” returned $count results
</h3></div>

@PhilippeDeRyck
<div><h3>
Your search for
“<i>Crazy Cats<script>alert(“Miauw!”)</script></i>
returned 5 results
</h3></div>

@PhilippeDeRyck
§ The escaping process is context-sensitive
− HTML body <h1>DATA</h1>
− HTML attributes <div id=‘DATA’>
− Stylesheet context body { background-color: DATA;}
− Script context alert(“DATA”);

@PhilippeDeRyck
SO, WHAT’S THE DEAL WITH ANGULARJS?
§ AngularJS is often used as a library within traditional applications
− The server builds an HTML page, including AngularJS templates
− The server needs to render user-supplied data harmless to protect against XSS
<script src=“…/angular.js”></script>
…
<div><h3>
Your search for
“<i>encode($query)</i>”
returned $count results
</h3></div>

@PhilippeDeRyck
§ But is that even possible in an AngularJS environment?
<div class=”ng-app”>
{{constructor.constructor(‘alert(1)’)}}
</div>
<div class="ng-app">
<b class="ng-style: {x:constructor.constructor('alert(1)')()};" />
</div>

@PhilippeDeRyck
§ But is that even possible in an AngularJS environment?
− No
§ AngularJS attempted to prevent this with the expression sandbox
− Prevents direct access to global JavaScript functionality
− Impossible to lock down completely, so only available in AngularJS 1.2 - 1.6
− Angular2 offers offline template compilation

@PhilippeDeRyck
RULE #1
DO NOT COMBINE TEMPLATES WITH USER-SUPPLIED DATA ON THE SERVER
Provide the data separately to the client-side AngularJS application

@PhilippeDeRyck
AND WHAT IF WE DO IT THE ANGULAR WAY?
§ Remember the confusion between data and code?
− Templates and JavaScript code are considered the application’s code
− Data fetched from APIs is considered data
§ AngularJS knows which parts are untrusted
− And automatically applies Strict Contextual Escaping (SCE)
− SCE applies to all data bindings with ng-bind or {{ }}
− SCE is on-by-default since version 1.2
§ But what if we actually want to allow some HTML in the user’s data?

@PhilippeDeRyck
http://stackoverflow.com/questions/9381926/angularjs-insert-html-into-view/25513186#25513186

@PhilippeDeRyck
ALL IS GREAT … UNTIL YOU GET A CALL ONE EVENING
What, no way! What happened? Did they steal our data?
No, it’s worse! Much worse!
They loaded the EmberJS library!
We’ve been hacked!
Then what?!

@PhilippeDeRyck
LET’S INVESTIGATE THE STACKOVERFLOW ADVICE …
https://docs.angularjs.org/api/ng/service/$sce
https://docs.angularjs.org/error/$sce/unsafe

@PhilippeDeRyck
LETTING ANGULARJS 1.X DO THE WORK FOR YOU
§ Simple data will be encoded for the right context with SCE
§ AngularJS will not allow you to directly use untrusted data
§ Sanitizing untrusted data makes it safe to use
§ Static HTML snippets can be marked as safe if absolutely necessary
<p>{{var}}</p>var = “test<script>alert(1)</script>”
<p ng-bind-html=“var”></p><input ng-model=“var” />
<input ng-model=“var” />
angular.module(“…”, [‘ngSanitize’]
<p ng-bind-html=“var”></p>
<p ng-bind-html=“var”></p>var = $sce.trustAsHtml(“<b>test</b>)”

@PhilippeDeRyck
AND IT’S EVEN BETTER IN ANGULARJS 2.X
§ All data is sanitized by default
§ Static HTML snippets can be marked as safe if absolutely necessary
<input ng-model=“var” /> <p>{{var}}</p>
<p>{{var}}</p>var = domSanitizer.bypassSecurityTrustHtml(“<b>test</b>)”

@PhilippeDeRyck
http://stackoverflow.com/a/25513186

@PhilippeDeRyck
RULE #2
DO NOT MARK UNTRUSTED DATA AS SAFE
Use the built-in sanitizer to remove dangerous features from the untrusted data

@PhilippeDeRyck
XSS VULNERABILITIES WILL POP UP EVENTUALLY
§ You can deploy a second line of defense with Content Security Policy
− Server-driven browser-enforced security policy
− In case there is an XSS attack, the script will be severely constrained or even blocked
− CSP evolved to an extensive and powerful browser security policy
§ CSP locks down what can happen in a web page
− Refuses to execute inline script and style
− Only loads external resources if they are explicitly whitelisted
§ CSP has severe incompatibility problems with traditional web applications
− But is easy to deploy on an AngularJS application

@PhilippeDeRyck
A QUICK OVERVIEW OF CSP’S DIRECTIVES
§ CSP has directives for all kinds of resources
− default-src applies to any resource, if there’s no more specific directive
− img-src, script-src, style-src, …
§ A directive can have numerous valid values
− Keywords: ‘none’, ‘self’, *
− Expressions: https://websec.be, https:, https://websec.be/jquery.js, *.websec.be
§ If absolutely necessary, you can re-enable inline scripts, styles and eval
− By adding the ‘unsafe-inline’ or ‘unsafe-eval’ keywords to the directives

@PhilippeDeRyck
BROWSER SUPPORT FOR CSP LEVEL 1 IS AWESOME
http://caniuse.com/#search=csp

@PhilippeDeRyck
WRITING SANE CSP POLICIES
§ Deploy CSP using the Content-Security-Policy response header
− <meta> tags are a good alternative if headers are too difficult to use
§ Make your policy as secure as possible
− Avoid ‘unsafe-inline’ and ‘unsafe-eval’ , especially for scripts
− Be specific about which files you want to include to avoid bypass attacks
− Define all important directives to avoid override attacks with <meta> tags
§ Use available tools and features to make your life easier
− Google’s CSP Evaluator
− Report-uri.io for policy generation & report collection
https://csp-evaluator.withgoogle.com/
https://report-uri.io/

@PhilippeDeRyck
RULE #3
DO NOT IGNORE THE TREMENDOUS POWER OF CSP
Make sure your apps are compatible, and lock down your CSP policy

@PhilippeDeRyck
THE FOCUS HERE TODAY WAS PURELY ON ANGULARJS
§ But there’s a lot more to building a secure application
− The web has evolved a lot in the last few years
− Plenty of new threats, but also plenty of new security technologies
§ Essential security principles to apply to your AngularJS applications
− Deploy your applications over HTTPS
− Use strong authentication mechanisms
− Perform access control in the right places, with the right data
− Protect against common threats against session management

@PhilippeDeRyck
ADDITIONAL INFORMATION
§ I’m running a 2-day web security course on December 6 and 7
− Information and registration on https://essentials.websec.be
§ https://www.websec.be contains a lot of information about web security
− The slides for this talk will be available there
− Slide decks, videos and blog posts about various security topics
− Subscribe to the mailing list to stay up to date
§ Feel free to contact me with feedback, questions, or speaking invitations
philippe.deryck@cs.kuleuven.be /in/philippederyck

@PhilippeDeRyck
THE RULES OF ANGULARJS SECURITY
#3 DO NOT IGNORE THE TREMENDOUS POWER OF CSP
#2 DO NOT MARK UNTRUSTED DATA AS SAFE
#1 DO NOT COMBINE TEMPLATES WITH USER-SUPPLIED DATA
#0 YOU TELL ALL YOUR FRIENDS ABOUT THESE RULES!

Are you botching the security of your AngularJS applications? (DevFest 2016)

More Related Content

What's hot (20)

Similar to Are you botching the security of your AngularJS applications? (DevFest 2016) (20)

Recently uploaded (20)

Are you botching the security of your AngularJS applications? (DevFest 2016)