This is an alpha

Lots of us are new to GDS and we don’t all know each other yet...

Timings

RailsGoat is a deliberately vulnerable Rails app, with tests

https://github.com/alphagov/railsgoat/tree/virtualbox

What do we mean by web security?

What are the risks and possible consequences?

We aren’t security experts

Web security is a huge topic

...but understanding some general principles really helps

These are ours:

• Don’t trust user input, ever
• Browsers are a special environment
• Your frameworks and tools can help, but understand how to use them properly and their limitations
• Don’t do it yourself - use standard well-understood things instead

There is one thing you need to know before we begin:

Computer Misuse Act 1990

Unauthorised access to computer material is punishable by 12 months imprisonment

Putting some code on the server and getting it to run

The code can come from any user input

It can damage anything running on the server

SQL injection

'SELECT * FROM data WHERE foo=' + '1; DROP TABLE users' + ';'

Remote code execution

ImageTragick (CVE-2016-3714)

Practical stuff:

• SQL injection in analytics in Railsgoat
• ImageTragick

“We had thousands of hits in the first 15 minutes. We were at the top of hacker news, which a lot of people see. We were getting the word out on something tragickally simple to exploit. We'd do it again.”

imagetragick.com

Don’t build it yourself

(but the alternatives aren’t perfect either)

Hash passwords before storing them in your database

MD5, SHA-512, bcrypt

Demo: use hashcat to crack some passwords

echo -n "taylorswift" | md5sum | cut -f1 -d" " > /tmp/hash.txt

tar xvzf rockyou.tar.gz

chmod +x hashcat-cli64.app

./hashcat-cli64.app /tmp/hash.txt rockyou.txt

Devise session bug

HTTP is stateless

Changing params

Hiding a button isn’t enough

Demo: authorisation to publish manuals in Specialist Publisher

Don’t trust user input - check every time!

Make sure your application is configured correctly in production

For example, Rails has a development mode that shows stack traces

Don’t show stack traces to people

Applications should be served over a secure connection

We’re going to login to a demo app over HTTP and watch the traffic

http://dodgy-login.herokuapp.com/

Cookies (this is why you need to do authentication properly)

People don’t pay attention (this is why phishing attacks work)

From the server’s point of view, the browser is the user

It’s useful to think of this as JavaScript injection

Two types of XSS:

• stored
• reflected

This happens when you take user input and render it without escaping it correctly

This has happened on GOV.UK

alphagov/finder-frontend #91

https://www-origin.integration.publishing.service.gov.uk/aaib-reports

A user on another website is tricked into making a request against your website

The malicious request has access to your site’s cookies so it’s “authenticated”

Practical: be the victim of a CSRF attack in Railsgoat (and fix it)

Rails doesn’t check authenticity tokens for GET requests because you shouldn’t be using GET requests for dangerous things

ActionController::RequestForgeryProtection docs

Same-origin policy

The browser won’t let a site make an HTTP request to another origin unless the site has cross-origin resource sharing (CORS) configured

Practical: write some JavaScript to try and get the CSRF token from a Signon form

Then do the same thing with the GitHub API. See the difference?

Man-in-the-middle attacks

Somebody is intercepting your web traffic

HTTP strict transport security (HSTS)

HTTP public key pinning (HPKP)

People are fallible

https://www.youtube.com/watch?v=bjYhmX_OUQQ

Session fixation

<script>

document.cookie ="_session_id=16d5b78a2a03c8d9";

</script>

What other examples can we come up with?

Timing attacks

Draft RFC on same-site cookies

Twitter credit card thing

Najaf Ali’s LRUG talk

OWASP Top 10

Rails security guide

netstat, ngrep, tcpdump, wireshark

Julia Evans’ blog

www.hacksplaining.com