what's our software doing with all that user input

Download What's Our Software Doing With All That User Input

If you can't read please download the document

Upload: kim-carter

Post on 16-Apr-2017

886 views

Category:

Technology


0 download

TRANSCRIPT

Dealing with User InputSecurely

Kim Carter OWASP Day 2013-09-12

Demonstrate vulnerabilities

Increase knowledge, awareness and desire to test

Discuss practical techniques and approaches that increase our defences

Agenda

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 JobWrite Code

Hackers Day JobBreak Code

What does Poor Sanitisation look like?

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

Quality

What is Quality?

Do we as builders care?

Why we should care

Quality

But increasing qualityis expensive right?

Quality

Not necessarily

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.

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

User Input Sanitisation Strategies

Threat modellingDefence in depthMinimising attack surfaceField length validation, incl structured dataParametrised Queries / Prepared StatementsLeast privilegeWhite listsHow to escape untrusted data for the different execution contextsFile uploads not coveredWhy bother with client sideLeveraging existing libraries

Threat modelling

Ideally performed at design timeIdentify the real risks. How?DecompositionDetermine entry points, assets, trust levels of usersAnalyse dependencies

Determine & rankthreatsDetermine security controls to prevent threats

Defence in depth

Multiple layers may seem redundantThink of each layer as the only layerAttempt to stop the attack as soon as possibleUser Interface (Mark-up, JavaScript, CSS)Client Server CommsServer side (internet facing)Back end codeData store

Minimising attack surface

Field length validation (client side)

Minimising attack surface

Field length validation (server side)

Minimising attack surface

Constrain fields to well structured data. Dates, post codes, e-mail addresses, check boxes, radio buttons

Minimise free-form text inputHard to create small white lists with free-form

Parametrised Queries / Prepared Statements

Least privilege

White lists

Decide which characters are essential for each input

Can now use the HTML5 pattern attribute on input tag. Doesn't cover textareas

Client Side

type the characters in

[ctrl]+[v] characters in clipboard

right click -> Paste

Server Side

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

Client Side

ServerSide

Why bother with client side

User ExperienceServer 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

Leveraging existing libraries

UsefulOWASP Encoding Project (Reform library) Supports Perl, Python, PHP, JavaScript, ASP, Java, .NET

OWASP Enterprise Security API

Not so UsefulMicrosoft Anti-Cross Site Scripting Library

A lot more detail on my blog blog.binarymist.net

Using: http://google-gruyere.appspot.com/

Stored XSS via AJAX

When the user clicks refresh button,response looks like

In the mark-up the snippet looks like:

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