Introduction to Web Security Defence and Testing

Jeremy Stashewsky, Salesforce

@jstash

Goals of this Talk

You know basically what I mean by "Web Security"

You've seen how I use an open-source testing tool

You get the gist of how to fix the bug we found

I've given you some ideas on where to explore next

"Web Security"?

Web Security

is about...

Designing (Defenders)

Implementing (Builders)

and Testing (Attackers)

for a better WWW

Fully-connected dependency graph

Every website needs Security

and I don't just mean HTTPS

Security is a Quality

I can't give you 100 securities ;)

By analogy...

Pretend this is a website

Can you spot two things wrong?

The drawer is the website, the latch is security, the contents is valuable information. Seems like a good design, right?

Improper Security design

Leads to information disclosure, impersonation, financial loss & more!

Clearly this was a bad design. Often we are so busy thinking about "how to keep the bad guy out" that we fail to design the system securely

Security isn't easy

"please don't hack me"

Good Security takes LOTS of practice!

Important to start learning early

Danger: human mistakes!

Even with the best defenses, humans can mess it all up

"Swiss cheese model of accident causation" by Davidmack - Own work. CC-BY-SA 3.0 via Wikimedia Commons

The analogy here is that the cheese slices are multiple layers of security, but each layer has it's own "holes", so sometimes an attack can get through.

Learn by doing

Security is hard, let's go hacking!

Practice without harm

(In Canada, it's legal to own lock-picks, but illegal to possess "with the intention of committing a crime")

Warning

You should not attack any applications other than your own, and only do that with permission from the appropriate authorities (e.g. your company, your school)

Disclaimer

if you take something from this talk and do something irresponsible, I won't be held liable.

Be awesome and responsible :)

Let's Attack!

App, Tool, and Objective

The App

Gruere Codelab

google-gruyere.appspot.com

The Tool

OWASP ZAP

the Zed Attack Proxy

What does the Gruyere website do?

users create profiles
users share snippets
administrators can manage users

How We'll Work:

The Objective

Find a Cross-Site Scripting (XSS) vulnerability

X-what-now?

XSS = Cross-Site Scripting

(english-idiom: X = cross)

One of the easiest errors to make when building a web site

Roughly, XSS is when you can run JavaScript on someone else's page

... demo ...

(For those reading slides after the talk, be sure to set the Scope to http://localhost:8008 and then enter Protected mode)

Focus: XSS

The page had a template slot the user-controlled value was placed there verbatim we were able to "break out" of HTML context into JavaScript context we were then able to obtain their session cookie (authentication)

Defending against XSS

Fixing Gruyere

(Live coding goes here... or explaining a pre-prepared patch)

(Essentially: add apostrophe to filter in gtl.py, add :text in error.gtl)

The Theory

XSS is caused by "breaking out" of one textual context into another

Parsers for a web page switch modes on certain control characters

Web languages provide syntax to "escape" those control characters

So, we escaped the problematic control characters!

HTML Control Characters

Well known: ", <, >, and &

Often overlooked: =, ' (apostrophe), !, /, and ` (backtick)

HTML Escaping

Character Encoding " " < < > > & & ' ' generally: &#xHHHH; H is a hexadecimal digit, unicode goes from 1 to 0x1F0000

Expanding on Escaping: block-list vs. allow-list

Briefly stated, theory is: escape control characters

This is a "block-list" approach

An "allow-list" approach can be more comprehensive

Block-lists

Start with "everthing's fine"

incrementally subtract; "this is not OK"

Benefits: easier to define

Problems: maintenance cost & missing important items

Allow-lists

Start with "trust nothing"

incrementally add; "this is verified OK"

Benefits: resilient to yet-unknown threats

Problems: sometimes over-matches & breaks functionality

In my opinion...

Be suspicious of block-list approaches

With a good team*, allow-list has less maintainance costs

* one that can consistently catch defects before they reach customers

Allow-listing applied to XSS

Alpha-numeric is usually safe

Escape everything else using &#xHHHH; syntax

Advanced Anti-XSS Techniques

Use a template language with automatic escaping

Use a template language with contextual escaping

Use Content-Security-Policy (a topic worth another talk)

Going Forward

Gruyere has more to offer!

For more challenges, try the Gruyere Codelab on your own!

Web Security Dojo

A free open-source self-contained training environment for Web Application Security penetration testing. Tools + Targets = Dojo https://www.mavensecurity.com/web_security_dojo/

OWASP Top 10

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

highlights:

#1 - Injection (e.g. SQL injection)
#2 - Broken Authentication & Session Management
#3 - XSS
#7 - Cross-Site Request Forgery (CSRF)
... in reality, there's much more than just 10

Mobile Security

Relative to the web, a nascent field!

Secure Development

Development strategies often focus on velocity

Need to stress: importance of threat modeling and secure coding practices

Career Paths

To generalize:

Attacker - paid to break into things

Defender - paid to make things less break-in-able

Builder - paid to ship a product, apply defenses

Introduction to Web Security Defence and Testing – Jeremy Stashewsky, Salesforce – Goals of this Talk

stash