1. CIT 485: Advanced Cybersecurity
Input Validation

2. Topics Attack Surface Validation Methodology
Path Traversal Vulnerabilities
Canonicalization
Application Logic Vulnerabilities

3. Attack Surface Attacks System surface Entry/Exit Points 2. Channels
1. Methods
3. Data
The attack surface of a system consists of the ways in which a threat can enter the system.
Methods are code components that receive input.
Channels are avenues of communication (sockets, environment, keyboard, files, etc.)
Data are the actual input strings.

4. Defending Attack Surface
Minimize the attack surface
Design application so that the smallest number of required entry points exist.
Limit access to required entry points to designated networks (firewall) and personnel (authentication).
Design application so that entry points accept well-defined input types that are not more complex languages than needed.
Verify attack surface
Verify that no unexpected entry points exist.
Verify that all entry points that should require authentication do require it.
Securely validate input at all entry points.

5. Input Validation Principles
Never trust input.
Assume dangerous until proven safe.
Prefer rejecting data to filtering data.
Difficult to filter out all dangerous input
Every component should validate data.
Trust is transitive.
Don’t trust calling component.
Don’t trust called component: shell, SQL

6. Trust Boundaries

7. Validation Techniques
Indirect Selection
Allow user to supply index into a list of legitimate values.
Application never directly uses user input.
Most secure but cannot be applied to all inputs.
Whitelist
List of valid patterns or strings.
Input rejected unless it matches list.
Secure and can be applied to all inputs.
Blacklist
List of invalid patterns or strings.
Input reject if it matches list.
Least secure.

8. Check Input Length Long input can result in buffer overflows.
Can also cause DoS due to low memory.
Truncation vulnerabilities
8-character long username column in DB.
User tries to enter ‘admin x’ as username.
DB returns no match since name is 9 chars.
App inserts data into DB, which truncates.
Later SQL queries will return both names, since MySQL ignores trailing spaces on string comparisons.
Wordpress had a SQL column truncation vulnerability. See .

9. Check Input Type Is input the type you expect?
Integer
Temperature (integer within specified range)
Money value (fixed point)
Name (alphabetic string allowing ‘, -, spaces)
Compiler type checking doesn’t solve this for you:
Simple input types (integers and the like) are checked.
But strings that represent complex types like HTML, XML, JSON, SQL, etc. are not.

10. Check Input Syntax Is input in correct format?
Phone number (xxx-xxx-xxxx format)
International phone number (more options)
Credit card number (format, Luhn checksum)
URL
address
Libraries may do this, but check that they actually work:
Many web frameworks have validator classes.
Parsers for XML, JSON, etc. can do checking themselves.

11. Minimal Computational Power
Input languages should be at the lowest level of the Chomsky hierarchy possible.
The higher the language level, the more attackers can do.
Input validation techniques must be capable of handling the full input language.
Example: Regular expressions cannot validate a context-free input language, which includes any language that supports nested matching braces.

12. Regular Expressions

13. Regular Expression Variants
Common Types
POSIX BRE: POSIX standard basic regular expressions. Can use with grep -b.
POSIX ERE: POSIX extended regular expressions add +, ?, |. Can use with grep -E.
PCRE: Perl-Compatible regular expressions, supported by many languages and tools, can recognize languages beyond regular expressions and therefore can match braces. etc. Use with grep -P.
Character Types
Some regular expression libraries support Unicode and/or multiple character sets; other do not.

14. Input Validation with REs
Write regular expression describing valid input.
Be strict. Avoid accepting input that is not valid.
Use anchors: ^ at the beginning and $ at the end, to avoid mistakes like attempting to match file suffixes with /.zip/, which accepts bzip2.exe, instead of /\.zip$/
Test if input matches regular expression.
Reject input if it does not match.
Process input if it does match.

15. Function-Specific Input Validation
Certain input types require special validation or other security techniques to prevent vulnerabilities, including but not limited to:
Filesystem paths (path traversal, below)
Data used to construct an HTML page (cross-site scripting)
Data used in an OS command (command injection)
Data used in a SQL query (SQL injection)
Data used in an XML document (XML injection)
Many of these input types are covered in the Cross-Site and Injection lessons later in the course.

16. Canonicalization Canonical Name: standard form of a name
Generally simplest form.
Canonicalize name then apply access control
UTF-8 canonicalization in Java
String s = "\uFE64" + "script" + "\uFE65";
s = Normalizer.normalize(s, Form.NFKC);
APIs to canonicalize pathnames
C: realpath()
Java: getCanonicalPath()

17. Win/Apache Directory Traversal
Found in Apache and earlier.
To view the file winnt\win.ini, use:
which is the URL-encoded form of
Note that both Apache security flaws in this lecture were on platforms to which Apache was ported after the original writings. These other platforms’ filesystems invalidate some of the naming assumptions based on Apache’s native UNIX platform.
Apache fixed this bug.

18. Common Naming Issues . represents current directory
.. represents previous directory
Case sensitivity
Windows allows both / and \ in URLs.
Windows 8.3 representation of long names
Two names for each file for backwards compat.
Trailing dot in DNS names ==
URL encoding

19. Path Traversal Encodings
URL Encodings
%2e%2e%2f translates to ../
%2e%2e/ translates to ../
..%2f translates to ../
%2e%2e%5c translates to ..\
Unicode Encodings
%c1%1c translates to /
%c0%af translates to \

20. Separate Usability and Security Validation
Usability Validation helps legitimate users
Provide easy to understand feedback.
Client-side feedback is helpful for speed,
But client-side controls are easy to bypass with proxy.
Security Validation mitigates vulnerabilities
Whitelist to only accept valid inputs.
Provide little feedback on reasons for blocking input.
Server-side controls cannot be bypassed with proxy.

21. Application Logic Flaws
Flaws specific to the business logic in application.
Often found in state transitions, i.e. from anonymous user to authenticated user.
Often found in multi-stage processes, such as purchasing on an e-commerce site.
Example: Shopping Cart Checkout
Expected process:
Add items to cart.
Enter payment information.
Enter shipping information.
If application does not verify payment is made in step 3, then attacker can avoid payment by going directly to step 3.

22. Key Points Attack surface. Use the strongest possible technique.
Indirect Selection
Whitelist
Blacklist
Validate length, type, syntax, and semantics.
Input validation strategies.
Path traversal and canonicalization.
Application logic vulnerabilities.

23. References
Brian Chess and Jacob West, Secure Programming with Static Analysis, Addison-Wesley, 2007.
Stuttart and Pinto, The Web Application Hacker’s Handbook 2nd Edition, Wiley, 2011.
David Wheeler, Secure Programming for UNIX and Linux HOWTO,

24. Released under CC BY-SA 3.0
All slides in this presentation unless otherwise noted are released under the Creative Commons Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0) license
You are free:
to Share — to copy and redistribute the material in any medium
to Adapt— to remix, build, and transform upon the material
to use part or all of this presentation in your own classes
Under the following conditions:
Attribution — You must attribute the work to James Walden, but cannot do so in a way that suggests that he endorses you or your use of these materials.
Share Alike — If you remix, transform, or build upon this material, you must distribute the resulting work under this or a similar open license.
Details and full text of the license can be found at
CIT 485: Advanced Cybersecurity