input validation

56
Input Validation James Walden Northern Kentucky University

Upload: reba

Post on 24-Feb-2016

35 views

Category:

Documents


0 download

DESCRIPTION

Input Validation. James Walden Northern Kentucky University. CWE: Input Validation. Topics. The Nature of Trust Validating Input Entry Points Web Application Input. Trust Relationships. Relationship between multiple entities. Assumptions that certain properties are true. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Input Validation

Input Validation

James WaldenNorthern Kentucky University

Page 2: Input Validation

CSC 666: Secure Software Engineering

CWE: Input Validation

Page 3: Input Validation

CSC 666: Secure Software Engineering

Topics

1. The Nature of Trust2. Validating Input3. Entry Points4. Web Application Input

Page 4: Input Validation

CSC 666: Secure Software Engineering

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.

Page 5: Input Validation

CSC 666: Secure Software Engineering

Who do you trust?Client users

example: encryption key embedded in clientOperating system

example: dynamicly loaded librariesCalling program

example: environment variablesVendor

example: Borland Interbase backdoor 1994-2001, only discovered when program made open source

Page 6: Input Validation

CSC 666: Secure Software Engineering

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?

Page 7: Input Validation

CSC 666: Secure Software Engineering

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

Page 8: Input Validation

CSC 666: Secure Software Engineering

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.

Page 9: Input Validation

CSC 666: Secure Software Engineering

Trust Boundaries

Safe SyntaxApp

Logic

Syntax Validation Semantic Validation

RawInput

RawInput

RawInput

Trust Boundaries

Page 10: Input Validation

CSC 666: Secure Software Engineering

Wrap Dangerous FunctionsInput is context sensitive.

Need more context than is available at front end.

Soln: 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.

Custom Enterprise Web ApplicationEnterprise Security

API

Auth

enti

cato

r

Use

r

Acce

ssCo

ntro

ller

Acce

ssRe

fere

nceM

ap

Valid

ator

Enco

der

HTT

PUti

litie

s

Encr

ypto

r

Encr

ypte

dPro

pert

ies

Rand

omiz

er

Exce

ptio

n H

andl

ing

Logg

er

Intr

usio

nDet

ecto

r

Secu

rity

Confi

gura

tio

n

Existing Enterprise Security

Services/LibrariesOWASP ESAPI

Page 11: Input Validation

CSC 666: Secure Software Engineering

Usability Validation ≠ Security Validation

Usability Validation helps legimitate 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.

Page 12: Input Validation

CSC 666: Secure Software Engineering

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.

Page 13: Input Validation

CSC 666: Secure Software Engineering

Entry Points1. Command line arguments2. Environment variables3. File descriptors4. Signal handlers5. Format strings6. Paths7. Shell input8. Web application input9. Database input10. Other input types

Page 14: Input Validation

CSC 666: Secure Software Engineering

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

Page 15: Input Validation

CSC 666: Secure Software Engineering

Environment VariablesDefault: 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.

Page 16: Input Validation

CSC 666: Secure Software Engineering

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.

Page 17: Input Validation

CSC 666: Secure Software Engineering

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 toIFS

Internal field separator for shell Used to separate command line into arguments Attacker sets to “/”: /bin/ls becomes “bin” and “ls”

Page 18: Input Validation

CSC 666: Secure Software Engineering

Environment Storage FormatAccess Functions

setenv(), getenv()Internal Storage Format

array of character pointers, NULL terminated string format: “NAME=value”, NULL term Multiple env variables can have same name. Did you check the same variable that you

fetched? First or last variable that matches?

Page 19: Input Validation

CSC 666: Secure Software Engineering

Securing Your Environment/* BSS, pp. 318-319 */extern char **environ;static char *def_env[] = {“PATH=/bin:/usr/bin”,“IFS= \t\n”,0

};static void clean_environment() {int i = -1;while( environ[++i] != 0 );while(i--)

environ[i] = 0;while(def_env[i])

putenv(def_env[i++]);}

Page 20: Input Validation

CSC 666: Secure Software Engineering

Securing Your EnvironmentSecure 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”

);

Page 21: Input Validation

CSC 666: Secure Software Engineering

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

Page 22: Input Validation

CSC 666: Secure Software Engineering

Signal HandlersDefault: 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);}

Page 23: Input Validation

CSC 666: Secure Software Engineering

Format StringsFormatted output functions use format lang.

Percent(%) symbols in string indicate substitutions. %[flags][width][.precision][length]specifier

Example format specifiers “%010d”, 2009: 0000002009 “%4.2f”, 3.1415926: 3.14

Example functions printf() scanf() syslog()

Page 24: Input Validation

CSC 666: Secure Software Engineering

printf() family dangersUser-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: Useprintf( “%s”, userstring ) orfputs( userstring )

Page 25: Input Validation

CSC 666: Secure Software Engineering

printf() family dangersBuffer overflows

char buf[256];sprintf( buf, “The data is %s\n”, userstring );

Specify “precision” of string substitutionsprintf(buf,“The data is .32%s\n”,userstring );

Use snprintf (C99 standard function)snprintf(buf, 255, “The data is %s\n”, userstring );

Page 26: Input Validation

CSC 666: Secure Software Engineering

%n format commandNumber of characters written so far is stored into the integer indicated by the int * pointer argument.

char buf[] = "0123456789";int *n;printf(“buf=%s%n\n", buf, n);printf("n=%d\n", *n);

Output: buf=0123456789 n=14

Page 27: Input Validation

CSC 666: Secure Software Engineering

%n format attack

Plan of Attack 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

Page 28: Input Validation

CSC 666: Secure Software Engineering

String Inputs

Aspects of string input Length Character encoding

Encodings describe how bits map to chars ASCII 7-bit encoding for English. ISO-8859-1 (Latin 1) 8-bit encoding

- Compatible with ASCII- New chars for other Latin alphabet languages- Windows-1252 variant common

Unicode family of encodings for all languages

Page 29: Input Validation

CSC 666: Secure Software Engineering

Universal Character Set (UCS)Can represent all chars for all languages.

Represents characters as code points. Planes are groups of 65,536 numerical values that

represent code points. 1,112,064 code points from 17 planes are accessible

with current encodings.Basic Multilingual Plane (BMP)

The first 65,536 UCS characters. UCS-2 was an early 16-bit encoding to represent only

characters from the BMP.Supplementary Ideographic Plane

Contains many CJK ideographs.

Page 30: Input Validation

CSC 666: Secure Software Engineering

Map of the BMP

Page 31: Input Validation

CSC 666: Secure Software Engineering

Unicode EncodingsUTF-8

Variable length 8-, 16-, 24-, or 32-bit encoding Can represent any char on the 17 plans. Backwards compatible: first 128 chars are ASCII. Over half of web pages use UTF-8 encoding.

UTF-16 Variable length 16-bit or 32-bit encoding Can represent any char on the 17 planes. Used in Windows API since W2k. Java added UTF-16 support in Java 5. Special syntax for non-BMP in most languages.

Page 32: Input Validation

CSC 666: Secure Software Engineering

UTF-8

Problems Note that not all bit sequences are valid. Can represent same character using techniques in each

of 6 rows above to bypass input validation. Different characters may look identical on the screen and

can fool users into clicking malicious URLs.

Page 33: Input Validation

CSC 666: Secure Software Engineering

Paths

If attacker controls paths used by program Can read files accessible by program. Can write files accessible by program.

Vuln 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.

Page 34: Input Validation

CSC 666: Secure Software Engineering

Path Traversal Example

Page 35: Input Validation

CSC 666: Secure Software Engineering

The ProblemHow to make correct access control decisions when there are many names for a resource?

config ./config /etc/program/config ../program/config /tmp/../etc/program/config

Page 36: Input Validation

CSC 666: Secure Software Engineering

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()

Page 37: Input Validation

CSC 666: Secure Software Engineering

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

www.nku.edu. == www.nku.edu URL encoding

Page 38: Input Validation

CSC 666: Secure Software Engineering

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 \

Path Traversal Encodings

Page 39: Input Validation

CSC 666: Secure Software Engineering

Win/Apache Directory Traversal

Found in Apache 2.0.39 and earlier.

To view the file winnt\win.ini, use: http://127.0.0.1/error/%5c%2e%2e%5c%2e%2e%5c%2e%2e%5c%2e%2e%5cwinnt%5cwin.ini

which is the URL-encoded form of http://127.0.0.1/error/\..\..\..\..\winnt\win.ini

Page 40: Input Validation

CSC 666: Secure Software Engineering

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.

Page 41: Input Validation

CSC 666: Secure Software Engineering

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

Page 42: Input Validation

CSC 666: Secure Software Engineering

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 );

}

Page 43: Input Validation

CSC 666: Secure Software Engineering

Command Injection in C

How to exploit?./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.

Page 44: Input Validation

CSC 666: Secure Software Engineering

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);

Page 45: Input Validation

CSC 666: Secure Software Engineering

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.

Page 46: Input Validation

CSC 666: Secure Software Engineering

Web-based InputSources of Input:

URLs, including paths + parameters POST form parameters HTTP headers Cookies

Common Types of Input: HTML Javascript URL-encoded parameters XML/JSON

Page 47: Input Validation

CSC 666: Secure Software Engineering

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.

Page 48: Input Validation

CSC 666: Secure Software Engineering

URL Parameters<proto>://<user>@<host>:<port>/<path>?<qstr>

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

Page 49: Input Validation

CSC 666: Secure Software Engineering

HTML Special Characters

“<“ begins a tag“>” ends a tag

some browsers will auto-insert matching “<““&” begins a character entity

ex: &lt; represents literal “<“ characterQuotes(‘ and “) used to enclose attribute

values, but don’t have to be used.

Page 50: Input Validation

CSC 666: Secure Software Engineering

Cookies

Parameters Name Value Expiration Date Domain Path Secure Connections Only

Page 51: Input Validation

CSC 666: Secure Software Engineering

Cookies

Server to ClientContent-type: text/html Set-Cookie: foo=bar; path=/; expires Fri, 20-

Feb-2004 23:59:00 GMT Client to Server

Content-type: text/html Cookie: foo=bar

Page 52: Input Validation

CSC 666: Secure Software Engineering

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

Page 53: Input Validation

CSC 666: Secure Software Engineering

Database Input

SQL Injection 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.

Page 54: Input Validation

CSC 666: Secure Software Engineering

Other Inputs

Default file permissions umask(066);

Resource Limits 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.

Page 55: Input Validation

CSC 666: Secure Software Engineering

Key Points

1. Validate input from all sources.CLI args, env vars, config files, database, etc.

2. Canonicalize input before validation.3. Use the strongest possible technique.

1. Indirect Selection2. Whitelist3. Blacklist

4. Reject bad input, don’t attempt to fix it.5. Trust is transitive.6. Architect for validation: establish trust

boundaries, wrap dangerous functions.

Page 56: Input Validation

CSC 666: Secure Software Engineering

References1. CERT, CERT Secure Coding Standards,

https://www.securecoding.cert.org/, 2012.2. Brian Chess and Jacob West, Secure Programming with Static

Analysis, Addison-Wesley, 2007.3. PCI Security Standards Council, PCI DSS Requirements and

Security Assessment Procedures, v1.2, 2008.4. Mark Graff and Kenneth van Wyk, Secure Coding: Principles &

Practices, O’Reilly, 2003.5. Michael Howard and David LeBlanc, Writing Secure Code, 2nd

edition, Microsoft Press, 2003.6. Michael Howard, David LeBlanc, and John Viega, 19 Deadly Sins

of Software Security, McGraw-Hill Osborne, 2005.7. John Viega, and Gary McGraw, Building Secure Software,

Addison-Wesley, 2002.8. David Wheeler, Secure Programming for UNIX and Linux

HOWTO, http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/index.html, 2003.