1. June 14, 2007 Web Application Security Workshop James Walden

2. April 12, 2007 About the Speaker Background Ph.D. from Carnegie Mellon University 10 years of secure development experience. Gives workshops in secure programming and software security at a variety of conferences. Assistant Professor at NKU Specialize in software security. 4 years experience teaching security.

3. April 12, 2007 What is web application security? The art and science of developing web applications that function correctly even when under attack.

4. April 12, 2007 Firewalls don’t protect web apps Firewall Port 80 HTTP Traffic Web Client Web Server Application Database Server

5. April 12, 2007 What is web application security? It’s more than just cryptography. SSL won’t solve all your problems. It’s more than securing the web server. Web applications have their own problems. It’s more than application firewalls. Firewall can’t know every safe action at every possible state in your application.

6. April 12, 2007 The source of the problem “Malicious hackers don’t create security holes; they simply exploit them. Security holes and vulnerabilities – the real root cause of the problem – are the result of bad software design and implementation.” John Viega & Gary McGraw

7. April 12, 2007 Penetrate and Patch Discover flaws after deployment. Often by attackers. Users may not deploy patches. Patches may have security flaws (15%?) Patches are maps to vulnerabilities. Attackers reverse engineer to create attacks.

8. April 12, 2007 A Growing Problem

9. April 12, 2007 Vulnerability Trends for 2006

10. April 12, 2007 Web Application Vulnerabilities Input-based Security Problems Injection Flaws Insecure Remote File Inclusion Unvalidated Input Authentication and Authorization Cross-Site Scripting Authentication Access Control Other Bugs Error Handling and Information Leakage Insecure Storage Insecure Communications

11. April 12, 2007 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.

12. April 12, 2007 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--

13. April 12, 2007 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);

14. April 12, 2007 SQL Injection Attack Example 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.

15. April 12, 2007 Impact of SQL Injection SELECT SSN FROM USERS WHERE UID=‘$UID’ INPUTRESULT 5Returns info for user with UID 5. ‘ OR 1=1--Returns info for all users. ‘ UNION SELECT Field FROM Table WHERE 1=1-- Returns all rows from another table. ‘;DROP TABLE USERS-- Deletes the users table. ‘;master.dbo.xp_c mdshell ‘cmd.exe format c: /q /yes’ -- Formats C: drive of database server if you’re running MS SQL Server and extended procedures aren’t disabled.

16. April 12, 2007 SQL Injection Demo

17. April 12, 2007 Impact of SQL Injection 1. Leakage of sensitive information. 2. Legal consequences of losing PII. 3. PR consequences of losing PII. 4. Modification of sensitive information. 5. Loss of sensitive information. 6. Denial of service against db server.

18. April 12, 2007 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.

19. April 12, 2007 Mitigating SQL Injection Ineffective Mitigations Blacklists Stored Procedures Effective Mitigations Whitelists Prepared Queries

20. April 12, 2007 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? 5. 2 nd Order SQL Injection.

21. April 12, 2007 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

22. April 12, 2007 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.

23. April 12, 2007 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);

24. April 12, 2007 Insecure Remote File Inclusion Insecure remote file inclusion vulnerabilities allow an attack to trick the application into executing code provided by the attacker on another site. Dynamic code Includes in PHP, Java,.NET DTDs for XML documents Key Idea Attacker controls pathname for inclusion.

25. April 12, 2007 Impact of Remote File Inclusion 1. Loss of control of web application. 2. Installation of malware. 3. Attacks launched against other sites. 4. Denial of service.

26. April 12, 2007 Mitigating Remote File Inclusion 1. Turn off remote file inclusion. 2. Do not run code from uploaded files. 3. Do not use user-supplied paths. 4. Validate all paths before loading code.

27. April 12, 2007 Unvalidated Input Unvalidated input is an architecture flaw. Individual input-related bugs are easy to fix. How do you defend against the general problem of input-based attacks? Key Ideas Application needs to validate all input. Input validation needs to be part of design.

28. April 12, 2007 Input Validation Principles All input must be validated. Input must be validated on the server. Use a standard set of validation rules. Reject all input that isn’t in your whitelist. Blacklists can miss bad inputs. Input repairs can produce bad input.

29. April 12, 2007 Input Validation Architecture View Output encoding. Controller General input validation. Model Model-specific validation. Validation Rules View Selection State Change User Input State Query Change Notice

30. April 12, 2007 Validating Input Check that input matches specified: Data type Character set Input length NULLs or empty strings allowed? Numeric range List of legal values List of patterns

31. April 12, 2007 Impact of Unvalidated Input 1. More input-related vulnerabilities. 2. Loss of application integrity. 3. Loss of sensitive information. 4. Effort required to patch individual input- related bugs.

32. April 12, 2007 Mitigating Unvalidated Input Design for input validation. Architect app so all input is checked. Create a standard library of validation rules. Use a whitelist approach. Educate developers about validation. Verify that all input is validated.

33. April 12, 2007 Cross-Site Scripting (XSS) Attacker causes a legitimate web server to send user executable content (Javascript, Flash ActiveScript) of attacker’s choosing. XSS used to obtain session ID for Bank site (transfer money to attacker) Shopping site (buy goods for attacker) Key ideas Attacker sends malicious code to server. Victim’s browser loads code from server and runs it.

34. April 12, 2007 Anatomy of an XSS Attack 1. Login 2. Cookie Web Server 3. XSS Attack Attacker User 4. User clicks on XSS link. 5. XSS URL 7. Browser runs injected code. Evil site saves ID. 8. Attacker hijacks user session. 6. Page with injected code.

35. April 12, 2007 XSS URL Examples http://www.microsoft.com/education/?ID=MCTN&target =http://www.microsoft.com/education/?ID=MCTN&tar get="> alert(document.cookie) http://hotwired.lycos.com/webmonkey/00/18/index3a_ page2.html?tw= alert(‘Test’); http://www.shopnbc.com/listing.asp?qu= aler t(document.cookie) &frompage=4&page=1&ct =VVTV&mh=0&sh=0&RN=1 http://www.oracle.co.jp/mts_sem_owa/MTS_SEM/im_sea rch_exe?search_text=_%22%3E%3Cscript%3Ealert%28d ocument.cookie%29%3C%2Fscript%3E

36. April 12, 2007 Why does XSS Work? Same-Origin Policy Browser only allows Javascript from site X to access cookies and other data from site X. Attacker needs to make attack come from site X. Vulnerable Server Program Any program that returns user input without filtering out dangerous code.

37. April 12, 2007 Impact of XSS 1. Attackers can hijack user accounts. 2. Attackers can hijack admin accounts too. 3. Attacker can do anything a user can do. 4. Difficult to track down source of attack.

38. April 12, 2007 Mitigating XSS 1. Disallow HTML input 2. Allow only safe HTML tags 3. Filter output Replace HTML special characters in output ex: replace with > also replace (, ), #, & 4. Tagged cookies Include IP address in cookie and only allow access to original IP address that cookie was created for.

39. April 12, 2007 Authentication Authentication is the process of determining a user’s identity. Key Ideas HTTP is a stateless protocol. Every request must be authenticated. Use username/password on first request. Use session IDs on subsequent queries.

40. April 12, 2007 Authentication Attacks Sniffing passwords Guessing passwords Identity management attacks Replay attacks Session ID fixation Session ID guessing

41. April 12, 2007 Impact of Authentication Attacks 1. Attackers can hijack user accounts. 2. Attackers can hijack admin accounts too. 3. Attacker can do anything a user can do. 4. Difficult to track down source of attack.

42. April 12, 2007 Mitigating Authentication Attacks Use SSL to prevent sniffing attacks. Require strong passwords. Use secure identity management. Use a secure session ID mechanism. IDs chosen at random from large space. Regenerate session IDs with each request. Expire session IDs in short time.

43. April 12, 2007 Access Control Access control determines which users have access to which system resources. Levels of access control Site URL Function Function(parameters) Data

44. April 12, 2007 Impact of Broken Access Control 1. Access to other customer’s accounts. 2. Execute code as other users. 3. Execute administrative code. 4. Leakage of sensitive information. 5. Legal consequences of losing PII. 6. PR consequences of losing PII.

45. April 12, 2007 Mitigating Broken Access Control 1. Check every access. 2. Use whitelist model at every layer. 3. Do not rely on client-level access control. 4. Do not rely on security through obscurity.

46. April 12, 2007 Improper Error Handling Applications can unintentionally leak information about configuration, architecture, or sensitive data when handling errors improperly. Errors can provide too much data Stack traces SQL statements Subsystem errors User typos, such as passwords.

47. April 12, 2007 Impact of Improper Error Handling 1. Returning user input can create a cross-site vulnerability. 2. Information leakage can increase the probability of a successful attack against the application. 3. Leakage of sensitive information. 4. Legal consequences of losing PII. 5. PR consequences of losing PII.

48. April 12, 2007 Mitigating Improper Error Handling 1. Catch all exceptions. 2. Check all error codes. 3. Wrap application with catch-all handler. 4. Send user-friendly message to user. 5. Store details for debugging in log files. 6. Don’t log passwords or other sensitive data.

49. April 12, 2007 Insecure Storage Storing sensitive data without encrypting it, or using a weak encryption algorithm, or using a strong encryption system improperly. Problems Not encrypting sensitive data. Using home grown cryptography. Insecure use of weak algorithms. Storing keys in code or unprotected files.

50. April 12, 2007 Impact of Insecure Storage 1. Leakage of sensitive information. 2. Legal consequences of losing PII. 3. PR consequences of losing PII.

51. April 12, 2007 Storage Recommendations Hash algorithms MD5 and SHA1 look insecure. Use SHA256. Encrypting data Use AES with 128-bit keys. Key generation Generate random keys. Use secure random source.

52. April 12, 2007 Mitigating Insecure Storage 1. Use well studied public algorithms. 2. Use truly random keys. 3. Store keys in protected files. 4. Review code to ensure that all sensitive data is being encrypted. 5. Check database to ensure that all sensitive data is being encrypted.

53. April 12, 2007 Insecure Communication Applications fail to encrypt sensitive data in transit from client to server and vice- versa. Need to protect User authentication and session data. Sensitive data (CC numbers, SSNs) Key Idea Use SSL for all authentication connections.

54. April 12, 2007 Impact of Insecure Communication 1. Attackers can hijack user accounts. 2. Attacker can do anything a user can do. 3. Leakage of sensitive information. 4. Legal consequences of losing PII. 5. PR consequences of losing PII.

55. April 12, 2007 Mitigating Insecure Communication 1. Use SSL for all authenticated sessions. 2. Use SSL for all sensitive data. 3. Verify that SSL is used with automated vulnerability scanning tools.

56. April 12, 2007 Going Further

57. April 12, 2007 References 1. Mark Dowd, John McDonald, Justin Schuh, The Art of Software Security Assessment, Addison-Wesley, 2007. 2. “Java Gotchas,” http://mindprod.com/jgloss/gotchas.html, 2007.http://mindprod.com/jgloss/gotchas.html 3. Mitre, Common Weaknesses – Vulnerability Trends, http://cwe.mitre.org/documents/vuln-trends.html, 2007. http://cwe.mitre.org/documents/vuln-trends.html 4. Gary McGraw, Software Security, Addison-Wesley, 2006. 5. J.D. Meier, et. al., Improving Web Application Security: Threats and Countermeasures, Microsoft, http://msdn2.microsoft.com/en- us/library/aa302418.aspx, 2006. 6. OWASP Top 10, http://www.owasp.org/index.php/OWASP_Top_Ten_Project, 2007. http://www.owasp.org/index.php/OWASP_Top_Ten_Project 7. Ivan Ristic, Web Application Firewalls: When Are They Useful?, OWASP AppSec EU 2006. 8. Joel Scambray, Mike Shema, and Caleb Sima, Hacking Exposed: Web Applications, 2 nd edition, Addison-Wesley, 2006.