Understanding Client Framework Security Boundaries

Welcome to Part 2 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

Understanding Client Framework Security Boundaries The Composition of AngularJS

Angular JS, like other frameworks, is just a bunch of javascript which runs in the browser.

Overview of the Web Stack

This overview covers the following technology:

Browser: Rendering and DOM

Network: DNS and TCP/IP

Server: Data repository and Back end processing

Typical Security Risks in the Stack

This course talks a lot about insufficient access controls, although this is the responsibility of the server.

SQL injection is still the number 1 risk! Troy’s Hack Yourself First course is an excellent way to learn a bit about this as well as many other security vulnerabilities.

If you want to dive deeper into SQL injection risks, watch Troy’s Ethical Hacking: SQL Injection course

Troy then introduces DNS hijacking and Man in the middle attacks, both of which target the network stack.

Cross site request forgery, and Cross site scripting are both attacks that target the browser.

Defending the Stack

Troy introduces the essential tools and techniques necessary for protecting against these risks:

Browser: native browser defenses, HTTP only cookies

Network: Virtual Private Networks, Transport Layer protection

Server: Parameterization of SQL queries, Authentication and Authorization

Always Assume the Client Is Compromised

We must assume that the attacker controls both the browser and the network, because they are outside of our control.

Troy recommends taking the client out of the picture altogether and testing your requests directly against the server.

Circumventing the Client

We see a basic hack that can be made using Fiddler Web Debugger.