BOOSTING ANGULAR

hackerbot69

20170324_DeRyck_AngularSecurity

BOOSTING THE SECURITY

OF YOUR ANGULAR APPLICATION

Philippe De Ryck

March 2017

https://www.websec.be

@PhilippeDeRyck


ANGULAR APPLICATIONS RUN WITHIN THE BROWSER

JS code

HTML code

Load application

JS code / HTML code

JS code

HTML code

JS Application

HTML Template

Fetch data from API

Raw data

Data

@PhilippeDeRyck

2


ABOUT ME – PHILIPPE DE RYCK

§ My goal is to help you build secure web applications

− Hosted and customized in-house training

− Specialized security assessments of critical systems

− Threat landscape analysis and prioritization of security efforts

− More information and resources on https://www.websec.be

§ My security expertise is broad, with a focus on Web Security

− PhD in client-side web security

− Main author of the Primer on client-side web security

@PhilippeDeRyck

3


CROSS-SITE SCRIPTING IN ANGULAR

@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

5


THE TRUE POWER BEHIND XSS

@PhilippeDeRyck

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

6


TO TALK ABOUT THE FUTURE, WE MUST TALK ABOUT THE PAST

Welcome

https://websec.be/?username=Philippe

Welcome Philippe

Welcome Philippe

https://websec.be/?username=dude

Welcome dude

Welcome dude ng-be

https://websec.be/?username=pwned

Welcome pwned

Welcome pwned

@PhilippeDeRyck


TRADITIONAL XSS DEFENSES


Welcome



Welcome



Welcome <blink>dude</blink>



var username = “”;


”>


@PhilippeDeRyck


DOESN’T THIS LOOK FAMILIAR?

@PhilippeDeRyck

https://xkcd.com/327/


SEPARATING DATA AND CODE WITH ANGULAR

Welcome {{username}}

https://websec.be/?username=alert(‘no!’

Welcome

<bscript>alert(’no!’)</script& Welcome alert(‘no!’)

gt;

https://websec.be/?username=dude

Welcome

<blink>dude</blink>

Welcome dude

@PhilippeDeRyck


BUT ANGULAR IS FLEXIBLE, AND ESCAPING IS NOT MANDATORY

Welcome

htmlSnippet=“dude”

Welcome dude

Welcome dude ng-be

htmlSnippet=pwned

Welcome pwned

Welcome pwned

@PhilippeDeRyck


RESPECT THE AUTHORITY OF THE SANITIZER

§ Sanitization is enabled by default when you bind HTML into the DOM

− The majority of you will not even notice the sanitizer at work, which is great!

− Make sure you do this via Angular, not by directly calling the DOM API

§ Similar to Angular 1, functions to bypass sanitization are available

− A minor modifications aims to raise developer awareness about its effect

bypassSecurityTrustHtml()

bypassSecurityTrustScript()

bypassSecurityTrustStyle()

bypassSecurityTrustUrl()

bypassSecurityTrustResourceUrl()

@PhilippeDeRyck


DISMISS XSS LIKE A KING, GET PWNED LIKE A SKIDDIE

@PhilippeDeRyck

https://github.com/angular/angular/issues/8511

Redacted for your safety!


TAKEAWAY #1

ANGULAR ALREADY PROTECTS YOU AGAINST XSS, JUST GET OUT OF THE WAY

§ The normal way of binding data is using interpolation

− Angular will automatically apply escaping

− Binding data this way will never result in the injection of unsafe content

§ You can also bind data that contains HTML code

− Angular will automatically apply sanitization

− The sanitizer removes dangerous features, but leaves other parts untouched

− Do not directly use DOM APIs to bind this data, but use built-in mechanisms

§ Angular allows you to mark a value as safe to use in a dangerous context

− Only use this for static data, which has been verified to be secure

@PhilippeDeRyck


BUT WHAT ABOUT UNTRUSTED CODE?

Angular

User Data

Ads

@PhilippeDeRyck


KNOW WHAT YOU LOAD WITH SRI

@PhilippeDeRyck


HOW DO YOU KNOW WHAT CODE YOU LOAD?

https://some-cdn.com/angular/2.0.0.js

@PhilippeDeRyck


SUBRESOURCE INTEGRITY

§ Including code from third-party providers requires a lot of trust

− What if the provider gets compromised?

− What if the provider decides to change the code you are including?

§ Subresource Integrity allows you to define what you want to include

− Developer specifies a checksum for a script or stylesheet inclusion

− Browser calculates and verifies the checksum before including the resource



@PhilippeDeRyck


SRI IN ACTION



Verify

checksum

https://…/2.0.0.js

@PhilippeDeRyck


ON A POSITIVE NOTE, MANY CDNS MAKE SRI REALLY EASY

@PhilippeDeRyck

https://cdnjs.com/libraries/angular.js/


BUT DOING IT YOURSELF IS NOT VERY HARD

@PhilippeDeRyck

https://www.srihash.org/


INTEGRATING SRI INTO YOUR BUILD PROCESS

@PhilippeDeRyck

https://www.npmjs.com/package/webpack-subresource-integrity


WIDESPREAD BROWSER SUPPORT IS COMING

@PhilippeDeRyck

http://caniuse.com/#search=sri


TAKEAWAY #2

SUBRESOURCE INTEGRITY GIVES YOU ASSURANCES ABOUT WHAT YOU LOAD

§ SRI tells the browser to verify the integrity of scripts and styles

− Should be enabled for all your external resources

− Can be used to prevent unauthorized updates by third parties

§ Add a fallback to load the resources from your own server if needed

− Detect whether a library is loaded or not, and load the fallback in case of emergency

§ Trivial to enable for your own resources in your build process

@PhilippeDeRyck


GETTING BACK CONTROL WITH CSP

@PhilippeDeRyck


1-UPPING YOUR XSS DEFENSES WITH CSP

§ Content Security Policy (CSP) is a new browser security policy

− Gives a developer a lot of control over what is allowed to happen in a page

− Delivered by the server in a response header or meta tag

Content-Security-Policy: script-src ‘self’

External scripts are only loaded if they are explicitly whitelisted

Welcome pwned

Inline scripts are blocked and will not execute

Welcome alert(“XSS”);

@PhilippeDeRyck


CSP SOUNDS HARD, WILL IT WORK WITH ANGULAR?

Content-Security-Policy:

script-src ‘self’

@PhilippeDeRyck


WHITELISTING REMOTE SCRIPTS SEEMS EASY …

Content-Security-Policy:

script-src ‘self’

https://cdnjs.cloudflare.com

@PhilippeDeRyck


HOST-BASED WHITELISTING IS A BAD IDEA

@PhilippeDeRyck

https://speakerdeck.com/mikispag/acm-ccs-2016-csp-is-dead-long-live-csp

29


NONCES TO THE RESCUE

Content-Security-Policy:

script-src ‘self’

‘nonce-SuperRandom’

Nonces should fresh and random

@PhilippeDeRyck


NONCES WORK FOR INLINE SCRIPTS AS WELL

Content-Security-Policy:

script-src ‘self’

‘nonce-SuperRandom’

Nonces should fresh and random

@PhilippeDeRyck


BUT INCLUDING REMOTE COMPONENTS REMAINS TRICKY

Content-Security-Policy:

script-src ‘self’

‘nonce-SuperRandom’

https://platform.twitter.com/

https://cdn.syndication.twimg.com

https://syndication.twitter.com

@PhilippeDeRyck


’STRICT-DYNAMIC’ ENABLES TRUST PROPAGATION

Content-Security-Policy:

script-src ‘self’

‘nonce-SuperRandom’

’strict-dynamic’

@PhilippeDeRyck


BACKWARDS COMPATIBILITY WITH ‘STRICT-DYNAMIC’

Content-Security-Policy:

object-src 'none';

script-src ’nonce-{random}' 'strict-dynamic' 'unsafe-inline' 'unsafe-eval' https: http:;

report-uri https://your-report-collector.example.com/

Remote

Inline

Remote

Inline

Remote

Inline

Content-Security-Policy:

object-src 'none';

script-src ’nonce-{random}’ 'strict-dynamic’ 'unsafe-eval';

report-uri https://your-report-collector.example.com/

Content-Security-Policy:

object-src 'none';

script-src ’nonce-{random}’ 'unsafe-eval' https: http:;

report-uri https://your-report-collector.example.com/

Content-Security-Policy:

object-src 'none';

script-src 'unsafe-inline' 'unsafe-eval' https: http:;

report-uri https://your-report-collector.example.com/

@PhilippeDeRyck


TAKEAWAY #3

CSP ALLOWS YOU TO LOCK YOUR APPLICATION DOWN

§ CSP allows you to prevent injected scripts from being executed

− Straightforward if you do not depend on third-party resources

− Stick with strict whitelisting if possible

− Use ‘strict-dynamic’ to enable trust propagation if needed

§ CSPs reporting mode gives you insights into violations

− Awesome to dry-run a policy before actually deploying it

§ CSP can be used to restrict other types of resources and actions

− New features keep being added, making CSP an important policy towards the future

@PhilippeDeRyck


SANDBOXING UNTRUSTED CODE

@PhilippeDeRyck


@PhilippeDeRyck

BUT WHAT IF YOU LIKE LIVING ON THE EDGE?


THE SANDBOX ATTRIBUTE

§ Sandboxed iframe’s are restricted by default

− Separate, unique origin

− No script execution

− No form submission

− No external navigations or popups

− No plugin content

− No fullscreen

− No autoplay

− …


@PhilippeDeRyck


RELAXING THE SANDBOX

§ Restrictions can be lifted by adding specific keywords

− E.g. allow-scripts, allow-same-origin, …

§ Some restrictions cannot be lifted

− Plugin content cannot be re-enabled

− Navigating arbitrary contexts is not allowed (only top-level or auxiliary)

§ Enabling allow-scripts together with allow-same-origin is dangerous

− Allows the sandboxed script to break out of the sandbox


@PhilippeDeRyck


USING THE SANDBOX IN PRACTICE







@PhilippeDeRyck


@PhilippeDeRyck

COMMUNICATING WITH A SANDBOXED IFRAME


COMMUNICATING WITH A SANDBOXED IFRAME

Sending a message to a sandboxed content requires the use of the wildcard origin

Receiving a message requires careful verification of the sender origin

@PhilippeDeRyck


ALL BROWSERS PROVIDE A SANDBOXED IFRAME

@PhilippeDeRyck

http://caniuse.com/#search=sandbox


TAKEAWAY #4

SANDBOXING IS A POWERFUL MECHANISM TO ISOLATE UNTRUSTED CODE

§ Sandboxed iframes give you a strictly controlled environment

− A lot of potentially dangerous features are turned off

− Sandboxed iframes run in a unique origin by default

− Ideally suited to run untrusted code components

§ Behavior can be controlled with a coarse granularity

− Turn features back on when needed

− Be careful about the code escaping the sandbox (same-origin and allow-scripts)

§ Offloading Angular templates / components can be tricky

− Requires to bootstrap a new Angular context in the sandboxed context

@PhilippeDeRyck


TAKEAWAY #1

ANGULAR ALREADY PROTECTS YOU AGAINST XSS, JUST GET OUT OF THE WAY

TAKEAWAY #2

SUBRESOURCE INTEGRITY GIVES YOU ASSURANCES ABOUT WHAT YOU LOAD

TAKEAWAY #3

CSP ALLOWS YOU TO LOCK YOUR APPLICATION DOWN

TAKEAWAY #4

SANDBOXING IS A POWERFUL MECHANISM TO ISOLATE UNTRUSTED CODE

@PhilippeDeRyck 45


NOW IT’S UP TO YOU …

Secure

Follow

Share

Web Security Essentials

April 24 – 25, Leuven, Belgium

https://essentials.websec.be

@PhilippeDeRyck

https://www.websec.be philippe.deryck@cs.kuleuven.be /in/philippederyck

Similar magazines