Slide 1

Slide 1 text

Dealing with User Input Securely Kim Carter – OWASP Day 2013-09-12

Slide 2

Slide 2 text

Demonstrate vulnerabilities Increase knowledge, awareness and desire to test Discuss practical techniques and approaches that increase our defences Agenda

Slide 3

Slide 3 text

Why the hacker always has the advantage Learn to enjoy breaking your own software. It'll make you a better developer. Our builders must think like breakers Developers Day Job Write Code Hackers Day Job Break Code

Slide 4

Slide 4 text

What does Poor Sanitisation look like?

Slide 5

Slide 5 text

OWASP ZAP also has a REST API. Useful for regression test suites If we have time at the end, we'll go over some AJAX XSS

Slide 6

Slide 6 text

Quality What is Quality? Do we as builders care? Why we should care

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

Quality But increasing quality is expensive right?

Slide 9

Slide 9 text

Quality Not necessarily

Slide 10

Slide 10 text

My Philosophy on Quality Everyone on the team needs to be thinking about it. Not just the testers. Reducing faults much earlier in the cycle.

Slide 11

Slide 11 text

User Input Sanitisation Strategies All code should be driven by executable specifications. Especially sanitisation logic Based around my following two blog posts http://blog.binarymist.net/2012/11/04/sanitising-user-input-from-browser-part-1/ http://blog.binarymist.net/2012/11/16/sanitising-user-input-from-browser-part-2/ Main components were a WCF service which dished up XSL'd XML as HTML to an existing web app

Slide 12

Slide 12 text

User Input Sanitisation Strategies Threat modelling Defence in depth Minimising attack surface Field length validation, incl structured data Parametrised Queries / Prepared Statements Least privilege White lists How to escape untrusted data for the different execution contexts File uploads not covered Why bother with client side Leveraging existing libraries

Slide 13

Slide 13 text

Threat modelling Ideally performed at design time Identify the real risks. How? Decomposition Determine entry points, assets, trust levels of users Analyse dependencies Determine & rank threats Determine security controls to prevent threats

Slide 14

Slide 14 text

Defence in depth Multiple layers may seem redundant Think of each layer as the only layer Attempt to stop the attack as soon as possible User Interface (Mark-up, JavaScript, CSS) Client – Server Comms Server side (internet facing) Back end code Data store

Slide 15

Slide 15 text

Minimising attack surface Field length validation (client side)

Slide 16

Slide 16 text

Minimising attack surface Field length validation (server side)

Slide 17

Slide 17 text

Minimising attack surface Constrain fields to well structured data. Dates, post codes, e-mail addresses, check boxes, radio buttons Minimise free-form text input Hard to create small white lists with free-form

Slide 18

Slide 18 text

Parametrised Queries / Prepared Statements Least privilege

Slide 19

Slide 19 text

White lists Decide which characters are essential for each input Can now use the HTML5 pattern attribute on input tag. Doesn't cover textareas

Slide 20

Slide 20 text

Client Side 1.type the characters in 2.[ctrl]+[v] characters in clipboard 3.right click -> Paste

Slide 21

Slide 21 text

Server Side

Slide 22

Slide 22 text

Escaping Escape all characters depending on potential execution contexts they may end up in. Even if they are not in your white lists Get away with the following escaping example only if you deal with untrusted data in HTML elements and you're sure your attributes are all quoted Escaping details for additional contexts here: https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet

Slide 23

Slide 23 text

Client Side

Slide 24

Slide 24 text

Server Side

Slide 25

Slide 25 text

Why bother with client side User Experience Server side sanitisation can be a lot slower When an honest user submits their data, they're not going to get server side exceptions due to validation

Slide 26

Slide 26 text

Leveraging existing libraries Useful ● OWASP Encoding Project (Reform library) Supports Perl, Python, PHP, JavaScript, ASP, Java, .NET ● OWASP Enterprise Security API Not so Useful ● Microsoft Anti-Cross Site Scripting Library A lot more detail on my blog blog.binarymist.net

Slide 27

Slide 27 text

Using: http://google-gruyere.appspot.com/ Stored XSS via AJAX

Slide 28

Slide 28 text

When the user clicks refresh button, response looks like In the mark-up the snippet looks like:

Slide 29

Slide 29 text

Resources Threat Modelling ● https://www.owasp.org/index.php/Application_Threat_Modeling ● https://www.owasp.org/index.php/Threat_Risk_Modeling Cheat Sheets and Check Lists I found helpful ● https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet ● https://www.owasp.org/index.php/OWASP_Validation_Regex_Repository ● https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat _Sheet ● https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet ● https://www.owasp.org/index.php/OWASP_AJAX_Security_Guidelines

Slide 30

Slide 30 text

No content