Web Application Security Workshop

1. Web Application Security Workshop James Walden

2. 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. What is web application security? The art and science of developing web applications that function correctly even when under attack.

4. Firewall Application DatabaseServer WebClient WebServer Application HTTP Traffic Port 80 Firewalls don’t protect web apps

5. 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. 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. 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. A Growing Problem

9. Vulnerability Trends for 2006

10. 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. 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. SQL Injection Attacker • App sends form to user. • Attacker submits form with SQL exploit data. • Application builds string with exploit data. • Application sends SQL query to DB. • DB executes query, including exploit, sends data back to application. • Application returns data to user. ‘ or 1=1-- User Pass Firewall DB Server Web Server

13. 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. 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. Impact of SQL Injection SELECT SSN FROM USERS WHERE UID=‘$UID’

16. SQL Injection Demo

17. Impact of SQL Injection • Leakage of sensitive information. • Legal consequences of losing PII. • PR consequences of losing PII. • Modification of sensitive information. • Loss of sensitive information. • Denial of service against db server.

18. 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. Mitigating SQL Injection Ineffective Mitigations Blacklists Stored Procedures Effective Mitigations Whitelists Prepared Queries

20. Ineffective Mitigation: Blacklist Filter out known bad SQL metacharacters, such as single quotes. Problems: • Numeric parameters don’t use quotes. • URL escaped metacharacters. • Unicode encoded metacharacters. • Did you miss any metacharacters? • 2nd Order SQL Injection.

21. 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. 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. 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. 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. Impact of Remote File Inclusion • Loss of control of web application. • Installation of malware. • Attacks launched against other sites. • Denial of service.

26. Mitigating Remote File Inclusion • Turn off remote file inclusion. • Do not run code from uploaded files. • Do not use user-supplied paths. • Validate all paths before loading code.

27. 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. 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. Input Validation Architecture Model Model-specific validation. State Query State Change Change Notice Validation Rules Controller General input validation. View Output encoding. View Selection User Input

30. 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. Impact of Unvalidated Input • More input-related vulnerabilities. • Loss of application integrity. • Loss of sensitive information. • Effort required to patch individual input-related bugs.

32. 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. 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. Anatomy of an XSS Attack Web Server 8. Attacker hijacks user session. 1. Login Attacker User 2. Cookie 5. XSS URL 3. XSS Attack 6. Page with injected code. 7. Browser runs injected code. 4. User clicks on XSS link. Evil site saves ID.

35. XSS URL Examples http://www.microsoft.com/education/?ID=MCTN&target=http://www.microsoft.com/education/?ID=MCTN&target="><script>alert(document.cookie)</script> http://hotwired.lycos.com/webmonkey/00/18/index3a_page2.html?tw=<script>alert(‘Test’);</script> http://www.shopnbc.com/listing.asp?qu=<script>alert(document.cookie)</script>&frompage=4&page=1&ct=VVTV&mh=0&sh=0&RN=1 http://www.oracle.co.jp/mts_sem_owa/MTS_SEM/im_search_exe?search_text=_%22%3E%3Cscript%3Ealert%28document.cookie%29%3C%2Fscript%3E

36. 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. Impact of XSS • Attackers can hijack user accounts. • Attackers can hijack admin accounts too. • Attacker can do anything a user can do. • Difficult to track down source of attack.

38. Mitigating XSS • Disallow HTML input • Allow only safe HTML tags • Filter output Replace HTML special characters in output ex: replace < with &lt; and > with &gt; also replace (, ), #, & • Tagged cookies Include IP address in cookie and only allow access to original IP address that cookie was created for.

39. 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. Authentication Attacks • Sniffing passwords • Guessing passwords • Identity management attacks • Replay attacks • Session ID fixation • Session ID guessing

41. Impact of Authentication Attacks • Attackers can hijack user accounts. • Attackers can hijack admin accounts too. • Attacker can do anything a user can do. • Difficult to track down source of attack.

42. 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. Access Control • Access control determines which users have access to which system resources. • Levels of access control • Site • URL • Function • Function(parameters) • Data

44. Impact of Broken Access Control • Access to other customer’s accounts. • Execute code as other users. • Execute administrative code. • Leakage of sensitive information. • Legal consequences of losing PII. • PR consequences of losing PII.

45. Mitigating Broken Access Control • Check every access. • Use whitelist model at every layer. • Do not rely on client-level access control. • Do not rely on security through obscurity.

46. 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. Impact of Improper Error Handling • Returning user input can create a cross-site vulnerability. • Information leakage can increase the probability of a successful attack against the application. • Leakage of sensitive information. • Legal consequences of losing PII. • PR consequences of losing PII.

48. Mitigating Improper Error Handling • Catch all exceptions. • Check all error codes. • Wrap application with catch-all handler. • Send user-friendly message to user. • Store details for debugging in log files. • Don’t log passwords or other sensitive data.

49. 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. Impact of Insecure Storage • Leakage of sensitive information. • Legal consequences of losing PII. • PR consequences of losing PII.