broadening expertise in critical infrastructure protection defensive programming module funded...
TRANSCRIPT
Broadening Expertise in Critical Infrastructure Protection
Defensive Programming ModuleFunded through NSF Grant Award # DUE-1303269
Any opinions, findings, conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the
views of the National Science Foundation
Overview
• Defensive Programming Defined• The Need• Common Misconceptions and Errors• Best Practices• Lab: You Try!
DEFENSIVE PROGRAMMING DEFINED
What is Defensive Programming?
• Writing code that should behave in a consistent and predictable manner even when presented with unexpected conditions, such as unexpected user input
• Programming with Murphy’s Law mind, and therefore defensive techniques put in place
• Often called “Secure Programming”
THE NEED
“The whole point of defensive programming is guarding against errors you don’t expect.”Steve McConnell, Code Complete
Costly Mistakes
• Ariane 5 rocket's ill-fated first launch, 1996– http://www.youtube.com/watch?v=gp_D8r-2hwk
• Four European Space Agency spacecraft which were launched on the maiden flight of the Ariane 5 rocket, Flight 501
• Causes by assertions having been turned off, which in turn caused inadequate protection from integer overflow
• The failure has become known as one of the most infamous and expensive software bugs in history ($370 Million)
• Also: Google the Mars Climate Orbiter ($327.6M)6
Loss/Harm of Human of Life
• THERAC – 25: a computer controlled radiation-therapy machine
• Two cancer patients received fatal overdoses of radiation
• Software mishandled race condition – behavior of software system where the output is
dependent on the sequence or timing of other uncontrollable events.
Loss of Privacy
• In 2011 hackers were able to steal details of hundreds of thousands of bank accounts
• Hackers leapfrogged between accounts once signed in by changing the account information that was present in fields in the URL
• Proper security controls were missing
Loss of Revenue
• SQL injections used against retailers by their in-store price-check kiosks
• Converted SQL commands into bar codes, printed them out, and scanned them
• Could dump the entire contents of their database, and could execute commands on the database
• Able to change prices of high-ticket items so that they'd ring up at bargain prices at the register
Malicious Attacks
• Office 365 suffered from a serious Cross Site Scripting (XSS) vulnerability– Gave access to email and SharePoint content of
every employee in the company• Fixed by Microsoft in December 2013
COMMON MISCONCEPTIONS AND ERRORS
“To err is human;”Alexander Pope, Essay on Criticism
Common Misconceptions
• Assuming the user will interact with a program/site a certain way
• Trusting the user and other code– Assuming the best
• Complexity leads to better code• Assuming defensive programming is very
difficult
CWE/SANS Top 25 Most Dangerous Software Errors
Common Programming Error #1
• Lack of input validation and sanitization– #1 security issue– Resulting in several vulnerabilities buffer
overflows, SQL and command injections, Cross-Site Scripting (XSS), to name a few
Simple XSS Attack
Vulnerability: Cross Site Scripting (XSS)
Image Source: http://www.digitalnewsasia.com/sites/default/files/images/digital%20economy/HP%20XSS.jpg
Vulnerability: SQL Injection
• Common application layer attack techniques used today
• Takes advantage of improper coding that allows hacker to inject SQL commands
• Provides ability to view, modify, add, and delete data
SELECT *FROM loginsWHERE username = ‘$username’AND password = ‘$password’
Instead becomes
SELECT *FROM loginsWHERE username = ‘` OR 1=1; /*’AND password = ‘*/--’
Vulnerability: OS Command Injection
This example code intends to take the name of a user and list the contents of that user's home directory.
// Example Language: PHP $userName = $_POST["user"];$command = 'ls -l /home/' . $userName;system($command);
If $userName variable is not checked for malicious input an arbitrary OS command could be entered.
;rm -rf /
Which would result in $command being:
ls -l /home/;rm -rf /
/* the OS would first execute the ls command, then the rm command, deleting the entire file system */
Vulnerability: Buffer Overflow Example
strcpy writes entire string, overwriting whatever is after the destination string
strncpy truncates to the correct length, but with a terminating null character (next character might be read as part of the string)
strlcpy truncates and adds terminating null character
X
X
Vulnerability: Buffer Overflow Example (cont’d)
strcpy writes entire string, overwriting whatever is after the destination string
strncpy truncates to the correct length, but without a terminating null character (next character might be read as part of the string)
strlcpy truncates and adds terminating null character
X
X
Vulnerability: Buffer Overflow Example (cont’d)
strcpy writes entire string, overwriting whatever is after the destination string
strncpy truncates to the correct length, but without a terminating null character (next character might be read as part of the string)
strlcpy truncates and adds terminating null character
X
X
About Input Validation
• Critical to application security• Process of validating all input to an application
before using the input– Two common approaches
1. Blacklist validation: detect unauthorized input like attack characters and patterns
2. Whitelist validation (best way!): compare input against list of all authorized input often using regular expressions (specify type, length, and range of values)
Poor Input Validation Example
• See http://jsfiddle.net/HWba4/1/• Note common issues:
– Users can enter nothing, negative values, error values, and inject scripts
• (Note: jsfiddle has defenses in place against XSS so a simple <script> alert(“hello”) </script> will not get injected here)
Poor Input Validation Example
• See http://ideone.com/xH9n1r• Note common issues:
– User can exceed value for data type, cause memory overflow
About Sanitization
• Changes the user input into an acceptable format– Two common approaches
1. Blacklist sanitization: characters not part of approved list can be removed, encoded, or replaced
2. Whitelist sanitization (best way!): eliminate or translate characters in an effort to make input safe
Good Sanitization Example
• See http://jsfiddle.net/HNQvd/– Note that the HTML characters and treated as text
by the browser, not HTML tags
Buffer Overflow Errors
• Another problem is unchecked use of constant-size structures for dynamic-size data – Use safe function calls
• For example, in C instead of using gets() use fgets() to read characters and instead of using strcpy() use strnlcpy() to copy the content of the buffer
Common Programming Error #2
• Not testing early and often– Automate testing; build test cases– Use unit testing and integration testing– Bugs become more costly in later development
phases
Common Programming Error #3
• Unnecessarily complicated code– “Complexity breeds bugs.”
<?php
if($userLoggedIn) { /* Hundreds of lines of code */ }else{ exit(); }
?>
<?php
if(!$userLoggedIn) { exit(); }
/* Hundreds of lines of code */
VS
Common Programming Error #4
• Not reusing code
VS
Common Programming Error #5
• Not heeding compiler warning– Can be indicative of coding errors
Common Programming Error #6
• Not considering canonicalization– Canonicalization (often abbreviated as c14n, where
14 represents the number of letters between the C and the N) is a process for converting data that has more than one possible representation into a "standard", "normal", or canonical form.
• Example: all the following are the same:– www.somesite.com/Hello+World.doc– www.somesite.com/hello+world.doc– www.somesite.com/Hello%20World.doc
Other Common Programming Errors
• Not handling known errors– Handle even if probability is small
• Not consistently handling errors– Use a clear and consistent strategy
• Not documenting assumptions• Don’t document in lieu of coding• Trusting outside code
– Test error handling around external APIs and libraries
Errors Common to Threaded Environments
• Deadlocks– a situation where two or more threads are blocked
forever, waiting for each other
Errors Common to Threaded Environments
• Race condition– occurs when two threads access a shared variable
at the same time
BEST PRACTICES
Best Practices
• Perform code reviews or audits– Have someone else perform the review
• Write with other programmers in mind– Comment what you did and why
• Automate testing• Keep it simple• Follow standards• Use assertions
Standards• No magic numbers
– Use constants (e.g. KILOGRAMS_PER_POUND = 0.454 instead of hardcoding 0.454 in a formula)
• Use proper indenting• Always write {} around compound statements• Standardize error handling• Add proper parenthesis for better understanding• Follow coding standards (e.g. Hungarian
Notation, Indian Hill C Style)
Assertions
• Assert statements provide a way of specifying that something should be true at a certain point in a program. Code will stop execution if assertion is false.
• Helpful in debugging and testing, but not in production code
Example Assertion
• Will fail showing possibility of invalid triangle
…5 int a = -1; int b = 4; int c = 4;6 assert(a > 0 && b > 0 && c > 0);7 if (a + b > c || a + c > b || b + c > a) {8 System.out.println("We have a triangle!");9 } else {10 System.out.println("We do not have a
triangle!");11 }…
Result: Exception in thread "main" java.lang.AssertionError at AssertExample.main(AssertExample.java:6)
Lab Exercises
• You try!• During these exercises, ask yourself:
• What are the known errors?• What are the assumptions?
Helpful Resources
• CWE/SANS Top 25 Most Dangerous Software Errors– http://cwe.mitre.org/top25/
• Open Web Application Security Project– https://www.owasp.org
Resources• Defensive programming. (2014, August 7). In Wikipedia, The
Free Encyclopedia. Retrieved 16:59, August 19, 2014, from http://en.wikipedia.org/w/index.php?title=Defensive_programming&oldid=620243055
• Bird, J. (2012, March 14). Defensive Programming: Being Just-Enough Paranoid. Retrieved March 12, 2014, from Building Real Software: http://swreflections.blogspot.com/2012/03/defensive-programming-being-just-enough.html
• Shaw, Z. A. (2010). Learn C The Hard Way. Retrieved March 3, 2014, from Exercise 27: Creative And Defensive Programming: http://c.learncodethehardway.org/book/ex27.html