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

Part 3 – Working with Security Controls on the Server

Part 4 – Common Security Flaws on the Client Side

Security Constructs Within AngularJS

Protecting Against Cross Site Request Forgery

For more in depth knowledge of CRSF you can watch the Cross-Site Kacks module of Troy’s Hack Yourself First course.

In this lesson we see a couple of the response headers on awesomeplaces.html: __RequestVerificationToken is the default name returned by ASP.NET MVC/Web API. XSRF-Token was manually set by Troy.

For details on how this tokens are paired see Troy’s ASP.NET Security Secrets course.

We learn that Angular’s $http service automatically looks for an XSRF-TOKEN cookie and sends it as a custom request header. This is so that the server will be able to validate this credential.
Troy says this is a neat out-of-the-box implementation from Google.

Using the ngSanitize Module

Sanitization is parsing user input and serializing back input with the proper encodings.

Angular’s ngSanitize performs this role, using a whitelist of safe tokens. We see an example of ngSanitize working against an attackers onmouseover XSS attempt.

Working with Unsanitized HTML

There are some occasions where we might actually want to be running JavaScript events on HTML tags.

In this lesson we learn about Strict Contextual Escaping and the effect of disabling it. Troy also explains the difference between persisted and reflected XSS attacks here.

The Danger of Server Side Templates Rendering User Input

Troy emphasises some of the expression sandboxing points that the Angular team made at https://docs.angularjs.org/guide/security

In Angular JS 1.6 the team removed this sandbox.
This is because developers kept relied on it as a security feature, not taking account of the fact that its possible to access arbitrary JavaScript code with control the Angular templates or expressions of applications.

Troy shows an example of exploiting the Angular expressions and reflecting results in the query string. An attacker can also use this to log a user out, for example.

You can try this for yourself at http://awesomeplaces.troyhunt.com/Search