Upgrade to Pro — share decks privately, control downloads, hide ads and more …

What’s Our Software Doing With All That User Input

A397cb38965ab9f310e7148b8c3d1105?s=47 Kim Carter
September 12, 2013

What’s Our Software Doing With All That User Input

What are we doing with all the characters that get shoved into our applications? Have we considered every potential execution context?
It’s often interesting and surprising to see what sort of concoction of characters can be executed in different places… and linking multiple attack vectors together which the builders haven’t thought about.
What are we trusting? Why are we trusting it? What, where and how should we be sanitising?

We have a vast collection of libraries, techniques, cheat sheets, tutorials, guides and tools at our disposal.
I often find myself thinking… how can we commoditise the sanitisation of user input and I keep coming up with the same answer.
It’s not easy. Every application has a completely different set of concerns.

In order for our software to be shielded from an attack, the builders must think like attackers.

In this talk I’ll attempt to:

Increase our knowledge and awareness
Discuss practical techniques and approaches that increase our defences
Break some software

A397cb38965ab9f310e7148b8c3d1105?s=128

Kim Carter

September 12, 2013
Tweet

Transcript

  1. Dealing with User Input Securely Kim Carter – OWASP Day

    2013-09-12
  2. Demonstrate vulnerabilities Increase knowledge, awareness and desire to test Discuss

    practical techniques and approaches that increase our defences Agenda
  3. 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
  4. What does Poor Sanitisation look like?

  5. 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
  6. Quality What is Quality? Do we as builders care? Why

    we should care
  7. None
  8. Quality But increasing quality is expensive right?

  9. Quality Not necessarily

  10. 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.
  11. 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
  12. 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
  13. 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
  14. 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
  15. Minimising attack surface Field length validation (client side)

  16. Minimising attack surface Field length validation (server side)

  17. 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
  18. Parametrised Queries / Prepared Statements Least privilege

  19. White lists Decide which characters are essential for each input

    Can now use the HTML5 pattern attribute on input tag. Doesn't cover textareas
  20. Client Side 1.type the characters in 2.[ctrl]+[v] characters in clipboard

    3.right click -> Paste
  21. Server Side

  22. 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
  23. Client Side

  24. Server Side

  25. 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
  26. 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
  27. Using: http://google-gruyere.appspot.com/ Stored XSS via AJAX

  28. When the user clicks refresh button, response looks like In

    the mark-up the snippet looks like:
  29. 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
  30. None