Working with Security Controls on the Server

Welcome to Part 3 of this review of the Pluralsight course AngularJS Security Fundamentals by Troy Hunt.

Troy is a Microsoft Regional Director and MVP for Developer Security. He’s has been building software for browsers since the very early days of the web and has become an industry thought leader in the security space.

Troy is well known for creating “Have I been pwned?” the free service that aggregating data breaches and helping people establish potential impacts from malicious web activity. He’s created 27 courses (and counting) with Pluralsight.

Also in this series:

Part 1 Introduction

Part 2 Understanding Client Framework Security Boundaries

Working with Security Controls on the Server Understanding Page Lifecycles

Troy explains the page lifecycles, both for traditional website requests, and request in an AngularJS app.

The important point is we can’t do what we did in the traditional website model, when building a single page app.

Troy warns about the risk of issues becoming “out of sight, out of mind”. And that is covered more in his “Hack Your API first” course.

Authentication and Identity Persistence

This shows the awesomeplaces implementation for authentication.

We see the Form Data that is entered on login, and the response message, which is an access token.

How do these differ from cookies?

Cookies Versus Tokens

Many differences are explained by Troy here. Cookies are implicit, but this means they pose a CSRF risk.

Tokens are explicit, making them immune to this risk. They also have the potential advantage of being sent to other domains.

Disadvantages of tokens are also discussed.

Sending the Bearer Token

We see what happens when we request a resource requiring authentication.

It works, and we see how it’s been implemented. The code is pretty simple.

We also see there’s a Cookie called awesomePlacesAppToken which has the same value as the bearer token.

Persisting the Bearer Token When the DOM Is Unloaded

The implementation here persists the bearer token value to the Cookie, but this is not used for Authorization.

Because of this, it does not post a Cross Site Request Forgery risk.

We can implement everything with a cookie, and no bearer token, and we’ll see this later.

Troy says the most challenging part sometimes is emitting the token value from the server in a secure way.

Storing the value in a cookie can pose an XSS risk if the cookie is not HTTP only.

An alternative to consider is html5 session storage.

Exploiting Insufficient Authorization

Here we see that we can quite easily hack awesomeplaces using Fiddler Web debugger, due to insufficient authorization on the server.

Troy says this is a common vulnerability for web apps built with AngularJS and similar frameworks.

The Risk Behind Client Side Security Trimming

Some of the edit buttons in the app are “security trimmed out” when a regular user is logged in.

In this lesson we see an admin login, and the extra functionality they see in the web app: viewing users in the system.

We also see that we can access the same resource without any credentials: this link gives access everyone’s data:frowning:

We must not forget that the services behind AngularJS must be protected.

Securing Templates Versus Securing Services

We start at the URL of our template. Troy recommends protecting any templates that may be of any value to an attacker.

This means adding access controls on the server. Securing services is even more important!

Continue to Part 3 Working with Security Controls on the Server