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

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

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
●
https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet
●
https://www.owasp.org/index.php/OWASP_AJAX_Security_Guidelines