1. CSC 482/582: Computer Security
Input Validation
CSC 482/582: Computer Security

2. Topics The Nature of Trust Validating Input Entry Points
Web Application Input
CSC 482/582: Computer Security

3. Trust Relationships Relationship between multiple entities.
Assumptions that certain properties are true.
example: input has a certain format
Assumptions that other properties are false.
example: input never longer than X bytes
Trustworthy entities satisfy assumptions.
CSC 482/582: Computer Security

4. Who do you trust? Client users Operating system Calling program Vendor
example: encryption key embedded in client
Operating system
example: dynamically loaded libraries
Calling program
example: environment variables
Vendor
example: Borland Interbase backdoor ; only discovered when program made open source
CSC 482/582: Computer Security

5. Trust is Transitive
If you call another program, you are trusting the entities that it trusts:
Processes you spawn run with your privileges.
Did you run the program you think you did?
PATH and IFS environment variables
What input format does it use?
Shell escapes in editors and mailers
What output does it send you?
CSC 482/582: Computer Security

6. Validate All Input 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
CSC 482/582: Computer Security

7. Validation Techniques
Indirect Selection
Allow user to supply index into a list of legitimate values.
Application never directly uses user input.
Whitelist
List of valid patterns or strings.
Input rejected unless it matches list.
Blacklist
List of invalid patterns or strings.
Input reject if it matches list.
CSC 482/582: Computer Security

8. Validation Actions Sanitize Reject Reject with Explanation Log Alert
Attempt to fix input by removing dangerous parts.
Reject
Refuse to use invalid input.
Reject with Explanation
Explain problems with input to user.
Log
Record invalid input in log file.
Alert
Send an alert to an administrator about input.
CSC 482/582: Computer Security

9. Trust Boundaries Safe Syntax App Logic Syntax Validation
Semantic Validation
Raw
Input
Trust Boundaries
CSC 482/582: Computer Security

10. Wrap Dangerous Functions
Custom Enterprise Web Application
Enterprise Security API
Authenticator
User
AccessController
AccessReferenceMap
Validator
Encoder
HTTPUtilities
Encryptor
EncryptedProperties
Randomizer
Exception Handling
Logger
IntrusionDetector
SecurityConfiguration
Input is context sensitive.
Need more context than is available at front end.
Solution: create secure API
Apply context-sensitive input validation to all input.
Maintain input validation login in one place.
Ensure validation always applied.
Use static analysis to check for use of dangerous functions replaced by API.
Existing Enterprise Security Services/Libraries
OWASP ESAPI
Images from owasp.org.
CSC 482/582: Computer Security

11. Usability Validation ≠ Security Validation
Usability Validation helps legitimate users
Catch common errors.
Provide easy to understand feedback.
Client-side feedback is helpful for speed.
Security Validation mitigates vulnerabilities
Catches potential attacks, including unusual, unfriendly types of input.
Provide little to no feedback on reasons for blocking input.
Cannot trust client. Always server side.
CSC 482/582: Computer Security

12. 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 .
CSC 482/582: Computer Security

13. Entry Points Command line arguments Environment variables
File descriptors
Signal handlers
Format strings
Paths
Shell input
Web application input
Database input
Other input types
CSC 482/582: Computer Security

14. Command Line Arguments
Available to program as **argv.
execve() allows user to specify arguments.
May be of any length
even program name, argv[0]
argv[0] may even be NULL
CSC 482/582: Computer Security

15. Environment Variables
Default: inherit parent’s environment.
execve() allows you to specify environment variables for exec’d process.
environment variables can be of any length.
Telnet environment propagation to server
Server receives client shell’s environment.
Server runs setuid program login.
ssh may use user’s ~/.ssh/environment file.
Telnet Environment Advisory:
CSC 482/582: Computer Security

16. Dangerous Environment Variables
LD_PRELOAD
Programs loads functions from library specified in LD_PRELOAD before searching for system libraries.
Can replace any library function.
setuid root programs don’t honor this variable.
LD_LIBRARY_PATH
Specify list of paths to search for shared libs.
Store hacked version of library in first directory.
Modern libc implementation disallow for setuid/setgid.
Similar problems exist with Windows DLLs. If start a program by clicking on document, directory containing document is searched first for DLLs.
CSC 482/582: Computer Security

17. Dangerous Environment Variables
PATH
Search path for binaries
Attacker puts directory with hacked binary first in PATH so his ls used instead of system ls
Avoid “.” as attacker may place hacked binaries in directory program sets CWD to
IFS
Internal field separator for shell
Used to separate command line into arguments
Attacker sets to “/”: /bin/ls becomes “bin” and “ls”
LC_ALL, NLSPATH, and other locale vars may also be dangerous.
This is not an exhaustive list of dangerous environment variables by any means
CSC 482/582: Computer Security

18. Environment Storage Format
Access Functions
setenv(), getenv()
Internal Storage Format
array of character pointers, NULL terminated
string format: “NAME=value”, NULL term
Multiple environment variables can have same name.
Did you check the same variable that you fetched? First or last variable that matches?
CSC 482/582: Computer Security

19. Securing Your Environment
/* BSS, pp */
extern char **environ;
static char *def_env[] = {
“PATH=/bin:/usr/bin”,
“IFS= \t\n”, };
static void clean_environment() {
int i = -1;
while( environ[++i] != 0 );
while(i--)
environ[i] = 0;
while(def_env[i])
putenv(def_env[i++]); }
Some UNIX versions require TZ be set as well.
CSC 482/582: Computer Security

20. Securing Your Environment
Secure Environment in Shell
/usr/bin/env – PATH=/bin:/usr/bin IFS=“ \t\n” cmd
Secure Environment in Perl
%ENV = (
PATH => “/bin:/usr/bin”,
IFS => “ \t\n” );
CSC 482/582: Computer Security

21. File Descriptors Default: inherited from parent process
stdin, stdout, stderr usually fd’s 0, 1, and 2
Parent process may have closed or redirected standard file descriptors
Parent may have left some fd’s open
Cannot assume first file opened will have fd 3
Parent process may not have left enough file descriptors for your program
Check using code from BSS, p. 315
CSC 482/582: Computer Security

22. Signal Handlers Default: inherited from parent process.
/* BSS, p. 316 */
#include <signal.h>
int main( int argc, char **argv ) {
int i;
for(i=0; i<NSIG; i++)
signal(I, SIG_DFL); }
CSC 482/582: Computer Security

23. Format Strings Formatted output functions use format lang.
Percent(%) symbols in string indicate substitutions.
%[flags][width][.precision][length]specifier
Example format specifiers
“%010d”, 2009:
“%4.2f”, : 3.14
Example functions
printf()
scanf()
syslog()
CSC 482/582: Computer Security

24. printf() family dangers
User-specified format strings
userstring = “foo %x”;
printf( userstring );
Where can it find arguments to replace %x?
The Stack: %x reads 4-bytes higher in stack
Solution: Use
printf( “%s”, userstring ) or
fputs( userstring )
CSC 482/582: Computer Security

25. printf() family dangers
Buffer overflows
char buf[256];
sprintf( buf, “The data is %s\n”, userstring );
Specify “precision” of string substitution
sprintf(buf, “The data is .32%s\n”,userstring );
Use snprintf (C99 standard function)
snprintf(buf, 255, “The data is %s\n”, userstring );
CSC 482/582: Computer Security

26. %n format command
Number of characters written so far is stored into the integer indicated by the int * pointer argument.
char buf[] = " ";
int *n;
printf(“buf=%s%n\n", buf, n);
printf("n=%d\n", *n);
Output:
buf=
n=14
CSC 482/582: Computer Security

27. %n format attack Plan of Attack Use %n to write anywhere in memory
Find address of variable to overwrite
Place address of variable on stack (as part of format string) so %n will write to that address
Write # of characters equal to value to insert into variable (use precision, e.g., %.64x)
Use %n to write anywhere in memory
Address on stack can point to any location
CSC 482/582: Computer Security

28. Paths If attacker controls paths used by program
Can read files accessible by program.
Can write files accessible by program.
Vulnerability if access is different than attackers
Privileged (SETUID) local programs.
Remote server applications, including web.
Directory traversal
Use “../../..” to climb out of application’s directory and access files.
CSC 482/582: Computer Security

29. Canonicalization
How to make correct access control decisions when there are many names?
config
./config
/etc/program/config
../program/config
/tmp/../etc/program/config
Canonical Name: standard form of a name
Generally simplest form.
Canonicalize name then apply access control.
Use realpath() in C to canonicalize.
CSC 482/582: Computer Security

30. 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
CSC 482/582: Computer Security

31. Win/Apache Directory Traversal
Found in Apache and earlier.
To view the file winnt\win.ini, use:
which is the escaped 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.
CSC 482/582: Computer Security

32. Command Injection
Find program that invokes a subshell command with user input
UNIX C: system(), popen(), …
Windows C: CreateProcess(), ShellExecute()
Java: java.lang.Runtime.exec()
Perl: system(), ``, open()
Use shell meta-characters to insert user-defined code into the command.
CSC 482/582: Computer Security

33. UNIX Shell Metacharacters
`command` will execute command
‘;’ separates commands
‘|’ creates a pipe between two commands
‘&&’ and ‘||’ logical operators which may execute following command
‘!’ logical negation—reverses truth value of test
‘-’ could convert filename into an argument
‘*’ and ‘?’ glob, matching files, which may be interpreted as args: what if “-rf” is file?
‘#’ comments to end of line
CSC 482/582: Computer Security

34. Command Injection in C /* Mail to root with user-defined subject */
int main( int argc, char **argv ) {
char buf[1024];
sprintf( buf, “/bin/mail –s %s root </tmp/message”, argv[1] );
system( buf ); }
CSC 482/582: Computer Security

35. Command Injection in C How to exploit? How to fix?
./mailprog \`/path/to/hacked_bin\`
/path/to/hacked_bin will be run by mailprog
How to fix?
Verify input matches list of safe strings.
Run /bin/mail using fork/exec w/o a subshell.
CSC 482/582: Computer Security

36. Command Injection in Java
String btype = request.getParameter("backuptype");
String cmd = new String("cmd.exe /K \"c:\\util\\rmanDB.bat "+btype+"&&c:\\utl\\cleanup.bat\"");
System.Runtime.getRuntime().exec(cmd);
Example from
CSC 482/582: Computer Security

37. Command Injection in Java
How to exploit?
Edit HTTP parameter via web browser.
Set bype to be “&& del c:\\dbms\\*.*”
How to defend?
Verify input matches list of safe strings.
Run commands separately w/o cmd.exe.
CSC 482/582: Computer Security

38. Web-based Input Sources of Input: Common Types of Input:
URLs, including paths + parameters
POST form parameters
HTTP headers
Cookies
Common Types of Input:
HTML
Javascript
URL-encoded parameters
XML/JSON
CSC 482/582: Computer Security

39. Different Perspectives
Client Dangers
Dangerous code
ActiveX
ActionScript
Javascript
Java
Client-side storage
Cookies
Flash LSOs
DOM storage
Server Dangers
No data sent to client is secret:
Hidden fields
Cookies
User controls client.
Can bypass validation.
Can access URLs in any order.
Can alter client-side storage.
CSC 482/582: Computer Security

40. URL Parameters
Whitespace marks end of URL
separates userinfo from host
“?” marks beginning of query string
“&” separates query parameters
%HH represents character with hex values
ex: %20 represents a space
RFC 1738 for URL definitions
CSC 482/582: Computer Security

41. HTML Special Characters
“<“ begins a tag
“>” ends a tag
some browsers will auto-insert matching “<“
“&” begins a character entity
ex: < represents literal “<“ character
Quotes(‘ and “) used to enclose attribute values, but don’t have to be used.
CSC 482/582: Computer Security

42. Character Set Encoding
Default: ISO (Latin-1)
Char sets dictate which chars are special
UTF-8 allows multiple representations
Force Latin-1 encoding of web page with:
<META http-equiv=“Content-Type” content=“text/html; charset=ISO ”>
CSC 482/582: Computer Security

43. Cookies Parameters Name Value Expiration Date Domain Path
Secure Connections Only
CSC 482/582: Computer Security

44. Cookies Server to Client Client to Server Content-type: text/html
Set-Cookie: foo=bar; path=/; expires Fri, 20-Feb :59:00 GMT
Client to Server
Cookie: foo=bar
RFC 2109
CSC 482/582: Computer Security

45. Secure Cookie Authentication
Encrypt cookie so user cannot read
Include expiration time inside cookie
Include client IP address to avoid hijacking
Use another cookie with MAC of first cookie to detect tampering
Use secret key as part of MAC so client does not have necessary information to forge
CSC 482/582: Computer Security

46. Database Input SQL Injection Don’t trust input from database.
Most common flaw in database input parsing.
Don’t pass unvalidated data to database.
Whitelist for known safe character set.
Alphanumerics
How many symbols do you need to accept?
Don’t trust input from database.
Check that you receive expected # of rows.
Check for safe data to avoid stored XSS and second order SQL injection attacks.
CSC 482/582: Computer Security

47. Other Inputs Default file permissions Resource Limits umask(066);
May suffer DoS if parent imposes strict limits on CPU time, # processes, file size, stack size.
Use setrlimit() to limit core dump size to zero if program ever contains confidential data in memory, e.g., unencrypted passwords.
ulimit –a to list a user’s resource limits
CSC 482/582: Computer Security

48. Secure Programming Books
CSC 482/582: Computer Security

49. Software Security Certifications
SANS GIAC Secure Software Programmer
Secure programming knowledge in C, Java, or .NET
(ISC)2 Certified Secure Software Lifecycle Professional
Security through software engineering processes
CSC 482/582: Computer Security

50. Key Points Validate input from all sources.
CLI args, env vars, config files, database, etc.
Use the strongest possible technique.
Indirect Selection
Whitelist
Blacklist
Reject bad input, don’t attempt to fix it.
Trust is transitive.
Architect for validation: establish trust boundaries, wrap dangerous functions.
CSC 482/582: Computer Security

51. References
Brian Chess and Jacob West, Secure Programming with Static Analysis, Addison-Wesley, 2007.
Steve McConnell, Code Complete, 2/e, Microsoft Press, 2004.
Gary McGraw, Software Security, Addison-Wesley, 2006.
PCI Security Standards Council, PCI DSS Requirements and Security Assessment Procedures, v1.2, 2008.
Mark Graff and Kenneth van Wyk, Secure Coding: Principles & Practices, O’Reilly, 2003.
Michael Howard and David LeBlanc, Writing Secure Code, 2nd edition, Microsoft Press, 2003.
Michael Howard, David LeBlanc, and John Viega, 19 Deadly Sins of Software Security, McGraw-Hill Osborne, 2005.
John Viega, and Gary McGraw, Building Secure Software, Addison-Wesley, 2002.
David Wheeler, Secure Programming for UNIX and Linux HOWTO,
CSC 482/582: Computer Security