© 2003 School of Computing, University of Leeds SY32 Secure Computing, Lecture 14 Implementation Flaws Part 2: Malicious Input and Data Validation Issues

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

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

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

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

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

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

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

9 SY32 Secure Computing, Lecture 14 URI Obfuscation in Mozilla URI can be formatted with a null byte between user part symbol URI can be formatted with a null byte between user part symbol Mozilla status bar displays only user part when cursor hovers over link Mozilla status bar displays only user part when cursor hovers over link See See

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

11 SY32 Secure Computing, Lecture 14 Example: Case Sensitivity Version of Apache web server shipping with first release of Mac OS X was case-sensitive 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 Hierarchical File System of Mac OS X is not Apache configuration might deny access to /private directory of Apache configuration might deny access to /private directory of … but would work! … but would work!

12 SY32 Secure Computing, Lecture 14 Example: ‘Dot-free’ IP Addresses Bug in Internet Explorer, version 4 Bug in Internet Explorer, version 4 Website domain names containing >= 1 dot were assumed to be in Internet zone 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 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 Problem: IP address can be represented as a dot-free, 32-bit integer = =

13 SY32 Secure Computing, Lecture 14 Example: Homographs Obvious: micr0s0ft.com != microsoft.com Obvious: micr0s0ft.com != microsoft.com Subtle: MICR0S0FT.COM != MICROSOFT.COM Subtle: MICR0S0FT.COM != MICROSOFT.COM Very subtle: miсrоsоft.com != microsoft.com Very subtle: miсrоsоft.com != microsoft.com For further details, see Comm. ACM 45(2), page 128, or visit For further details, see Comm. ACM 45(2), page 128, or visit

14 SY32 Secure Computing, Lecture 14 SQL Injection Contents of name come from a web form… Contents of name come from a web form… …but no validation is done to ensure that name actually contains employee’s name! …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);

15 SY32 Secure Computing, Lecture 14 Demo

16 SY32 Secure Computing, Lecture 14 SQL Injection Really bad guy might do this: Really bad guy might do this: Downright evil guy might do this (on Windows): 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') -- '

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

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

19 SY32 Secure Computing, Lecture 14 What Happens When You Click? idForm.cookie.value=document.cookie; idForm.submit(); > Click here to win £10,000! Cookie for this domain… …is sent here!

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