Dealing with User Input
Securely
Kim Carter – OWASP Day 2013-09-12
Demonstrate vulnerabilities
Increase knowledge, awareness and
desire to test
Discuss practical techniques and
approaches t...
Why the hacker always has the advantage
Learn to enjoy breaking your own software.
It'll make you a better developer.
Our ...
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 quality
is 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 ea...
User Input Sanitisation Strategies
All code should be driven by executable
specifications. Especially sanitisation logic
B...
User Input Sanitisation Strategies
Threat modelling
Defence in depth
Minimising attack surface
Field length validation, in...
Threat modelling
Ideally performed at design time
Identify the real risks. How?
Decomposition
Determine entry points, asse...
Defence in depth
Multiple layers may seem redundant
Think of each layer as the only layer
Attempt to stop the attack as so...
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, radi...
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. Doe...
Client Side
1.type the characters in
2.[ctrl]+[v] characters in clipboard
3.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 ...
Client Side
Server
Side
Why bother with client side
User Experience
Server side sanitisation can be a lot slower
When an honest user submits their...
Leveraging existing libraries
Useful
●
OWASP Encoding Project (Reform library)
Supports Perl, Python, PHP, JavaScript, ASP...
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...
What's Our Software Doing With All That User Input
What's Our Software Doing With All That User Input
Upcoming SlideShare
Loading in …5
×

What's Our Software Doing With All That User Input

820 views

Published on

Demonstrate vulnerabilities due to insufficient input sanitisation.
Increase knowledge, awareness and desire to test.
Discuss practical techniques and approaches that increase our defences

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
820
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
16
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

What's Our Software Doing With All That User Input

  1. 1. Dealing with User Input Securely Kim Carter – OWASP Day 2013-09-12
  2. 2. Demonstrate vulnerabilities Increase knowledge, awareness and desire to test Discuss practical techniques and approaches that increase our defences Agenda
  3. 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. 4. What does Poor Sanitisation look like?
  5. 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. 6. Quality What is Quality? Do we as builders care? Why we should care
  7. 7. Quality But increasing quality is expensive right?
  8. 8. Quality Not necessarily
  9. 9. 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.
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. Minimising attack surface Field length validation (client side)
  15. 15. Minimising attack surface Field length validation (server side)
  16. 16. 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
  17. 17. Parametrised Queries / Prepared Statements Least privilege
  18. 18. White lists Decide which characters are essential for each input Can now use the HTML5 pattern attribute on input tag. Doesn't cover textareas
  19. 19. Client Side 1.type the characters in 2.[ctrl]+[v] characters in clipboard 3.right click -> Paste
  20. 20. Server Side
  21. 21. 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
  22. 22. Client Side
  23. 23. Server Side
  24. 24. 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
  25. 25. 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
  26. 26. Using: http://google-gruyere.appspot.com/ Stored XSS via AJAX
  27. 27. When the user clicks refresh button, response looks like In the mark-up the snippet looks like:
  28. 28. 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 ● https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet ● https://www.owasp.org/index.php/OWASP_AJAX_Security_Guidelines

×