angularjs security: defend your single page application

@carlobonamico#angularconf15

ANGULARJS SECURITY: defend your Single Page Application

Carlo Bonamico @carlobonamico [email protected]

http://www.nispro.it

Turin, 22/10/2015

mailto:[email protected]

http://www.nispro.it/


About meSpeaker Bio

– passionate software developer since the C128 era– PhD and research at the University of Genova / CNIT National TLC

Research Consortium – exciting time at startup Eptamedia– now a Solution Architect and Senior Trainer at NIS s.r.l.

between Italy and new London office

Current projects & interests – training/mentoring teams on AngularJS, Web Security, Continuous

Integration & Delivery– creating component-based Angular applications– security reviews and assessments


AbstractSecuring an html5 Single Page Application is not the same as protecting a typical JEE/Rails/PHP/.NET webapp.

The industry-wide move towards HTML5 and Single Page Applications, motivated by the opportunity for more sophisticated interaction and UX, is again upsetting the balance between Hackers and Developers. A wave of new-generation front-end technologies, including Angularjs, is attracting Developers with their combination of productivity and innovative UX, but at the same time opens the door to new vulnerabilities and security challenges.

This talk will summarize the main principles of Secure Coding, and will discuss their application to a typical angular HTML5 application with REST backend to prevent major risks (including OWASP Top Ten).

A concrete example will demonstrate the use of tools and libraries, from RBAC to JWT, from Spring Security to AngularJS directives for implementing secure HTML5/JS apps.


Evolution of Application SecurityWhen I taught my first Web Application Security training

– most participants had never heard of SQL Injection and XSS

Thanks to many industry and community players (especially OWASP),– not to mention many high-profile incidents,

things have started to change... Application Security

Ensuring Application guarantees

•Confidentiality•Integrity•Availability•Accountability

of the Information it processes


Are we doing better? It's 2015... we were promised flying cars... and what we got is...

See also– http://www.cvedetails.com/vulnerabilities-by-types.php – https://www.whitehatsec.com/resource/stats.html

http://www.cvedetails.com/vulnerabilities-by-types.php

https://www.whitehatsec.com/resource/stats.html


HTML5 Single Page ApplicationsSomewhat ill-defined term, but you know what I mean

– HTML templates, statically served– client retrieves data from REST services / websockets– views dynamically rendered on the client side

Definitely more powerful, interactive and mobile-friendly that traditional request-response webapps

also more secure?


First problemSpiderman's Uncle Ben version:With great power comes great responsibility...

The Web Application Security version:With great power come more holes and greater risks!

– increased Surface of Attack Websockets, storage, apis...

– https://html5sec.org/ – http://html5security.org/

– and once you penetrate the browser, you can do basically everything

and I mean it: calling APIs, install keyloggers, redirect user behaviour, capture private data

–http://xenotix.in/

“most attack were already possible... but they are more powerful now”

http://w3af.org/understanding-html5-security

https://html5sec.org/

http://html5security.org/

http://xenotix.in/

http://w3af.org/understanding-html5-security


Second problemWe are undergoing a wide architectural shift from

To

So many security assumptions do not hold true anymore!

ServerPOST params

HTML

Browser

Form-based input

HTML rendering

HTML templating

Controllers,Interaction

LogicBusiness Logic

ServerPOST JSON

JSON

Browser

HTML rendering

HTML templating

Business Logic

Interaction Logic

REST endpoints


The good sideThe typical modern HTML5 application architecture has a single/main advantage:

it forces at the very least a basic degree of separation between UI and business logic

– even more so with Angular, Ember, React

In our consulting/project/problem solving experience, the single biggest cause of

– quality – performance– security

problems is....


The good sideThe typical modern HTML5 application architecture has a single/main advantage:

it forces at the very least a basic degree of separation between UI and business logic

– even more so with Angular, Ember, React

In our consulting/project/problem solving experience, the single biggest cause of

– quality – performance– security

problems is.... the mixing & coupling of UI and business logic


There's hope...If we properly understand the new architectural paradigm, we can turn it into an advantage

Follow the principles of secure coding

– Do not trust inputs– Minimize attack surface area

(and window of opportunity)– Establish secure defaults– Principle of Least privilege– Principle of Defense in depth– Fail securely– Don’t trust services– Separation of duties (vs

configuration)– Avoid security by obscurity– Keep security simple– Fix security issues correctly


Top Ten Web Application Risks

– A1-Injection– A2-Broken Authentication and Session Management– A3-Cross-Site Scripting (XSS)– A4-Insecure Direct Object References– A5-Security Misconfiguration– A6-Sensitive Data Exposure– A7-Missing Function Level Access Control– A8-Cross-Site Request Forgery (CSRF)– A9-Using Components with Known Vulnerabilities– A10-Unvalidated Redirects and Forwards

What's different between Request/Response apps and HTML5/SPAs?


What changes with HTML5/SPAs? RED → more critical ORANGE → different solution GREEN → easier

– A1-Injection → same problem, same solution– A2-Broken Authentication and Session Management– A3-Cross-Site Scripting (XSS)– A4-Insecure Direct Object References– A5-Security Misconfiguration– A6-Sensitive Data Exposure– A7-Missing Function Level Access Control– A8-Cross-Site Request Forgery (CSRF)– A9-Using Components with Known Vulnerabilities – A10-Unvalidated Redirects and Forwards


What changes with HTML5/SPAs? RED → more critical ORANGE → different solution GREEN → easier

– A1-Injection → same problem, same solution– A2-Broken Authentication and Session Management– A3-Cross-Site Scripting (XSS)– A4-Insecure Direct Object References– A5-Security Misconfiguration– A6-Sensitive Data Exposure– A7-Missing Function Level Access Control– A8-Cross-Site Request Forgery (CSRF)– A9-Using Components with Known Vulnerabilities – A10-Unvalidated Redirects and Forwards

Today, we will focus on those!


A3-Cross-Site Scripting (XSS)


A3 - XSSCross-Site-Scripting means that attacker can insert custom js code which is then displayed in the user browser

– stored (input js in a field → DB → sent back to the page)– reflected (input js in the url, send the url to a user, js executed)– DOM-based (input triggers js logic that manipulates the DOM and

insert custom js)

Remember: any external input is UNTRUSTED! – so we must avoid mixing user input with js code


A3 – Preventing XSSLooks easy: but HTML allows for multiple mixed execution contexts:

– JS within CSS within HTML within a frame of another HTML …

The proper solution is ESCAPING: encoding the data so that the browser properly interprets it as plain text (and not js)

– https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

In a well designed SPA, – clear inputs paths

REST service responses, user inputs, url bar, ...– HTML generation through the framework templating engine – so it is easier to intercept and escape outputs

https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet


A3 – Preventing XSS with AngularSince 1.3, the HTML compiler will escape all {{}} & ngbind by default

– https://www.ng-book.com/p/Security – http://java.dzone.com/articles/angularjs-how-handle-xss

Be careful if you must include user-generated HTML (e.g. in rich text editors)– take advantage of the services and directives– ngbindhtml (from angular-sanitize)

print as is removing “script” tags (beware of img tags) fully customizable with

–$sceProvider & $SanitizeProvider– https://docs.angularjs.org/guide/security

Please note: – escaping in the REST services is not always feasible/useful– they can be consumed by mobile Apps and other clients

https://www.ng-book.com/p/Security

http://java.dzone.com/articles/angularjs-how-handle-xss

https://docs.angularjs.org/guide/security


RememberMost vulnerabilities are not so serious by themselves

– but became terrible if mixed think Pepsi + Mentos

XSS is an enabler for – phishing– browser-based MITM– session / auth token stealing– sensitive data extraction

– img courtesy of http://www.delawaretoday.com/

http://www.delawaretoday.com/


A5-Security Misconfiguration


A5 – Security misconfigurationA single MITM (Man in the Middle) and your “done”

– as the attacker can put arbitrary code in your browser– so,

https://www.eff.org/Https-everywhere

Be careful with CORS– Avoid AllowOrigin “*” unless you have very strong authentication

and authorization

Remember to tell the browser to enable stronger protection– typically through headers such as CSP– https://www.owasp.org/index.php/List_of_useful_HTTP_headers

https://www.eff.org/Https-everywhere

https://www.owasp.org/index.php/List_of_useful_HTTP_headers


Securing HeadersNode

– https://www.npmjs.com/package/helmet

Java (Spring Security)– http://docs.spring.io/autorepo/docs/spring-security/current/reference/html/headers.

html

Test tools– security headers online

https://securityheaders.com/

– OWASP ZAP https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

https://www.npmjs.com/package/helmet

http://docs.spring.io/autorepo/docs/spring-security/current/reference/html/headers.html

http://docs.spring.io/autorepo/docs/spring-security/current/reference/html/headers.html

https://securityheaders.com/

https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project


A2-Broken Authentication & Session Management


What is AuthenticationVerifying the user identity

– independently from his profile / authorizations

Several elements: – where valid users are listed (Realm)

internal, file, DB, LDAP, Active Directory, SSO Server– what info is used to establish user identity

one or more “factors”: username, password, OTP, certificate...– how identity is checked the first time

login → credentials validation– how identity is checked on subsequent requests

validation


Traditional Request-Response Applications

e.g. JSP / ASP / PHP– login page– successful login creates a session– protected pages accessed within the session– data and access control filtered on the server side

often within views or controllers

Browser

Server

POST Login Data

GET secured page

SESSIONID = 5

SESSIONID = 5 auth =

true?

credentials valid?

Realm

filteredHTMLpage

SID AUTH DATA

5 true carlo,admin


Issues with Cookie + Session Authentication

Authentication requires – checking credentials against a realm– keeping auth in session state on the server– sessionid sent in a cookie

Issues– state replication in clustered servers vs sticky sessions

Single-Sign-On across servers?– More complex scenarios are possible

e.g. SSO Server, like CAS– typically cookie based →

all server must be in same domain

Remember:

Cookies are sent with ANY request

to the same domain(including images)


Cookie-based authentication in Single Page Applications

Can't SPA just do the same?– login form POSTs to login service– successful login creates a session and sets a cookie– protected Pages & REST services accessed within the session

data and access control filtered … where ?

Browser

Server

POST Login Data

GET secured JSON

SESSIONID = 5

SID AUTH DATA

5 true carlo,adminSESSIONID = 5 auth

= true? {

...}

credentials valid?

Realm


Authentication vs Session Management

Cookie-based sessions are simple to implementBut

– not suited to stateless nature of REST services

Authentication vs Sessions– They are two different things, although often used together– REST services

tend to be stateless

Unauthenticated Authenticated

Stateless Plain HTTPe.g. Wikipedia

REST e.g. Google APIs

With Session Session cookiese.g. Amazon

JSP/ASP/PHPe.g. Intranet Apps


How to do stateless authentication?


Token-based Authentication Login establishes a valid token

– each request must be presented with the token– the server can check token validity at each request– https://auth0.com/blog/2014/01/07/angularjs-authentication-with-

cookies-vs-token/

Browser

Server

POST Login Data

GET secured JSON

TOKEN = 5

TOKEN = 5 token valid?

credentials valid?

Realm

no session!


IssuesGiven a token

– how do you know which is the current user?

On the server– how expensive it is to check the token at each request?

Can you share a token across services? – can you validate it without connecting to a DB / SSO Server?


How do you create & validate Tokens?


Creating and Validating TokensSimplest way: checking them against a list of valid tokens

– in memory → similar to session-based auth replication problems

– on a DB easier clustering, must consider performance

– on an external server SSO for free, must evaluate performance & complexity


JWT - http://jwt.io JWT = encoded & signed Json object containing

– Access token– Claims (custom: session, domain, username...)– Expiration– and Digital Signature! → verifiable with just the public key

Returned by login REST serviceSent as header at each request

–Authentication: bearer eyJhbGciO .eyJzdWIiOWV9.eoaDV

Checked by REST backed at each request– can also be used with websockets

{“user”:”carlo”,“domain”:”NIS”,“expiry”: ..}

http://jwt.io/


JWT in angularAngular Library

– https://github.com/auth0/angular-jwt

Extensible hooks for – storing and retrieving tokens on the client

Interceptors for– retrieving tokens from server Response Headers– optionally refresh tokens– automatically sending tokens at each request

Robust and simple to usebower install angularjwt

https://github.com/auth0/angular-jwt


Token-based Auth in AngularJsIngredientsREST endpoints

– /auth/login Input parameters: credentials Response: token

– /auth/logout Input parameters: token

$http or $resource based Client Service AuthenticationService

– login() logout() methods wrapping the above– plus isAuthenticated() and possibly currentUser()


Token-based Auth in AngularJsIngredients

– Controller(s)– LoginController

bound to Login form, calls service– LogoutController– AuthenticationController

IsAuthenticated, currentUser

Possibly, Directives <authenticateduser> showWhenAuthenticated<menu showWhenAuthenticated=”true”>


Saving the tokenIn both cases, register a then() on the promise

$http(...).then(function(response) { currentToken.jwt = response.data.access_token; }

Store the token locallyIf you need, parse it

tokenPayload = jwtHelper.decodeToken(jwt);date = jwtHelper.getTokenExpirationDate(jwt);bool = jwtHelper.isTokenExpired(jwt);


Sending the token at each request

Specify Token retrieval functionangular.module('myApp') .config( function Config($httpProvider,jwtInterceptorProvider) { jwtInterceptorProvider.tokenGetter = ['currentToken', function(currentToken) {return currentToken.jwt; //or return localStorage.getItem('id_token');}];

Register interceptor $httpProvider.interceptors.push('jwtInterceptor');});


Back-endLogin endpoint

– validates credentials– generates JWT

REST Service endpoints (or better interceptor)– extract Token from Authentication: header– validate it– proceed with request processing

or return error 401

Full example– http://thejackalofjavascript.com/architecting-a-restful-node-js-app/


JWT in...Plain Node: Auth0 library

– https://github.com/auth0/node-jsonwebtokenExpress: Express JWT

– https://github.com/auth0/express-jwtPassport - Modular Auth Framework for node.js

– http://passportjs.org/.NET - OWIN.Identity

– http://bitoftech.net/2014/10/27/json-web-token-asp-net-web-api-2-jwt-owin-authorization-server/

Java - Spring Security – https://spring.io/guides/tutorials/spring-security-and-angular-

js/Integrating OAUTH with JWT


Were can we store / send the token?

in a cookie?in a header?


Sending Tokens - Cookies vs Headers

CookiesPros

– sent automatically– no code required on the client

Cons– sent automatically– even when do not want

e.g. <IMG src= in email– less control on validity– stored on client disk

HeadersPros

– sent only explicitely– not stored on disk– unless you want to– more control– also prevents CSRF

Cons

– require code on the client side– but this is normal in SPAs

https://auth0.com/blog/2014/01/27/ten-things-you-should-know-about-tokens-and-cookies/


Token Storage vs Session DurationIn memory or sessionStorage

– works only on current tab– automatically closed

In localStorage– persistent– work across multiple tabs– requires explicit expiration

https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/


What else would we need?what happens when the user is not logged in?

how to improve usability?


Routing support for Authentication & Authorization

Need to configure Routing for– redirect to login if not authenticated– redirect to login if token expired– optionally, redirect back to original URL– redirect to error page if route not authorized in the current profile

Difficult to do in the default ngRoute– Possible in ui-router

Way easier in angular-new-router– https://medium.com/angularjs-meetup-south-london/angular-ng-

conf-2015-media-25dbe6250154


A7-Missing Function Level Access Control


Typical Server side application Authorization is verified

– in controllersif (user.hasRole(“admin”) == true)

– through filters / interceptors– in views

<hasRole role=”admin”> or <if (...)>confidential info

</hasRole>

Client Browser only receives content it has rights to– (roughly) works even if security checks are “spaghetti code” in the

JSP/ASP/PHP templates


And in a SPA?Would this be secure?In users-view.html

<button ngif=”authCtrl.isAdmin” ngclick=”userCtrl.deleteUser()”>

or this?

<section ngif=”authCtrl.isAdmin” >{{userCtrl.user.confidentialData}}</section>


No!

Just press F12

and modify the HTML / JS

or even the DOM in the developer toolsor just send HTTP requests directly to the backend


Security is up to the serverEven in SPAs, Authorization is still up to the server:

Security controls– checking authentication state– checking profile and inferring permissions– enabling privileged actions– filtering confidential data

MUST be performed on the server– in the REST / websocket endpoints– locally in each service, or via filters/interceptors

Also, the same rule applies to input validation


Usability is up to the clientBut letting the user click on the button, invoking the service, and only then displaying an error is not user friendly

UX is up to the client– Front-End should have enough info to disable/hide the button

if the user is not authorized to click it retrieve the permissions list from a REST service at logon

E.g. Permission check directives for Angular<button ngclick=”postCtrl.delete()” haspermission=”deletePost”>

permissions for Role-Based Access Control


Server-side authorization checksSo, in each server endpoint, you should check

– valid authentication– valid authorization profile which includes privileges for the

currently requested action / dataExample Blog application

if (subject.hasRole(“admin”))//enable delete postif (subject.hasRole(“editor”))//enable modification of postelse//only read data

What are the problems

with this code?


What if the rules change?

What if an auditor asks about what an “editor” can do?

Real-world cases tend to be more complex!


Role Based Access ControlSeparating Role definition from Permission check

– In each service / action, code checks that the user has the relevant permission

if (subject.hasPermission(“deletePost”))– Role Definition lists all the permissions

e.g. –Admin detelePost, updatePost, readPost→–anonymous readPost→

Authorization system maps user/groups to list of roles– and computes the “merged” set of permissions active for the valid user

user is both Admin & Editor Permissions are

–changeSettings, deleteUser, addUser, deletePost, modifyPost


Hierarchical permission system 2-level: User → Role → Permissions3-level: User → Groups → Roles → Permissions

Wildcard Permissions– blog:deletePost– blog:readPost– blog:* means both

blog:readPost:12 → entity level permission blog:readPost:* on all entities

see Apache Shiro


AdvantagesPermission check is

– focused, readable – easy to implement– easy to test– rarely changes

Role definition is – centralized– easy to review– easy to change– as it tends to change often

Secure Design Principle

all parts of the system need to perform security

checks

but

security check implementation

should be centralized and not “spread” in the system


RBAC in a Single Page Application Server-side Ingredients:

– Profile definition mapping Roles to Permissions static file db table possibly cached Identity server (e.g. OpenAM)

– API for checking permissions

Normally, some of this information is cached to ensure minimal performance penalty


Usable Secure UI in AngularJSIngredients:

– /authorization/profile/current REST endpoint returns a Json current user roles merged list of all active permissions

On the Client– Client Service wrapping the above– Authorization/ProfileService storing the permission list

hasPermission(p) methodCall the service from

– Controller methods– Routing callbacks


A9-Using Components with Known Vulnerabilities


Component SecurityThe code we write

The code which actually runs in our application – libraries and components


Checking dependecies for vulnsOn the client side

– http://retirejs.github.io/retire.js/npm install g retire ; retire –path src

– also available as ZAP & mvn pluginmvn com.h3xstream.retirejs:retirejsmavenplugin:scan

On the server side– OWASP Dependency Check

https://github.com/jeremylong/DependencyCheck dependencycheck.sh app Testing out . scan [path to jar files to be scanned]mvn org.owasp:dependencycheckmaven

http://retirejs.github.io/retire.js/

https://github.com/jeremylong/DependencyCheck

@YourTwitterHandle#DVXFR14{session hashtag} @carlobonamico#angularconf15

A fna

l

wor

d...

But isn't all that unnecessary complexityslowing down development of my critical project?


A final wordPeople tend to view Security as “overhead”, not adding value to the project

The reality: – if you know what to pay attention to, minimal additional costs– also, in most cases, adding security just means following good design principles

if you separate well concerns, adding security is easy – favor clarity of intent and code readability– favor composition over inheritance– test, test, test!

incorporate security checks in your tests

This lets software adapt more easily to both requirements & security changes – easier to evolve incrementally & validating each step → see Continuous

Delivery


References


ReferencesOwasp Secure Coding Principles

– https://www.owasp.org/index.php/Secure_Coding_Principles

OWASP Testing Guide– https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_

of_Contents

SOLID Design Principles– http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

https://www.owasp.org/index.php/Secure_Coding_Principles

https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents

https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents

http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod


HTML5 SecurityAttack Vectors & Vulnerabilities

– https://media.blackhat.com/bh-eu-12/shah/bh-eu-12-Shah_HTML5_Top_10-WP.pdf

OWASP Guidelines– https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet

JS Frameworks Security– http://www.slideshare.net/x00mario/jsmvcomfg-to-sternly-look-at-

javascript-mvc-and-templating-frameworks

https://media.blackhat.com/bh-eu-12/shah/bh-eu-12-Shah_HTML5_Top_10-WP.pdf

https://media.blackhat.com/bh-eu-12/shah/bh-eu-12-Shah_HTML5_Top_10-WP.pdf

https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet

http://www.slideshare.net/x00mario/jsmvcomfg-to-sternly-look-at-javascript-mvc-and-templating-frameworks

http://www.slideshare.net/x00mario/jsmvcomfg-to-sternly-look-at-javascript-mvc-and-templating-frameworks


Thank You for your attention Interested?

– attend our Web Application Security / Angular trainings– engage us for Design/Code Reviews, Vulnerability Assessments &

team mentoring

Read more on – http://www.nispro.it– http://www.slideshare.net/carlo.bonamico

Follow us on twitter– @nis_srl @carlobonamico

updates on Security, AngularJS, Continuous DeliveryContact me

– [email protected] / [email protected]

http://www.nispro.it/

http://www.slideshare.net/carlo.bonamico

angularjs security: defend your single page application

Software