OWASP & YOU

Make your apps better and safer! Take a point-by-point trek through the Open Web Application Security Project's top 10 web application vulnerabilities and learn how to defend against each.

Transcript

1. OWASP & YOU Web application security or your money back.™ Fred Alger // @_phred
2. my goals • Not to overwhelm. • Security thinking! • For you to kick ass at security
3. overview • Your security team. • Application Security (AppSec) • Why it matters. • background: PCI, OWASP, O MY • top 10 vulnerabilities • being a good developer
4. about me • been building webapps since PHP 4 • Rails, Django, Kohana, Symfony, Flask, … • “knew” web app security • 2012 Stripe CTF • Turns out I don’t.
5. Who is your security guy (or gal)?
6. No one?
7. Do you code?
8. Do you test?
9. It’s you.
10. Congrats!
11. Application Security
12. Application Security • Protecting secrets • Your customer’s • Credit cards, passwords, sensitive data • Your company’s • Source code, sensitive data • Reputation & business
13. Application Security • Limiting what people can do. • “Who can do what” • Knowing where the bodies are buried.
14. • It’s hard. • It’s important! • Team effort. :) • Keep your head on a swivel and always be asking questions • ABAQ? Application Security
15. Why does it matter?
16. • $$$$$ • Your customers’ • Your own • Trust — one event is all it takes • Because PCI says it does :) Application Security Why does it matter?
17. PCI • Payment Card Industry Data Security Standard (PCI-DSS) • Huge & nasty document. • Annual compliance audits. • Common sense: “follow best practices” • For programming, this means OWASP
18. PCI • Get an auditor who will work with you. :-)
19. OWASP?
20. O, WASP! http://www.flickr.com/photos/sidm/6997616532/
21. OWASP • Open Web Application Security Project • owasp.org • List of common programming and security errors. • Best practices and libraries for many languages.
22. OWASP • Level up your app security skillz. • +1 programming • +1 security • +1 charisma, more attractive! • +1 charisma :-(
23. OWASP • FREE papers, tutorials, books. • Go check it out. • But later, please. :)
24. OWASP TOP 10 • Most common security problems • Caught “in the wild”
25. OWASP TOP 10 • Injection • XSS • Broken Authentication • IDs in URLs • Cross-Site Request Forgery (CSRF) • Security Misconfiguration • Bad Crypto • “Secret” pages • SSL oopses • Redirects to bad places
26. OWASP TOP 10 • +1 BONUS VULNERABILITY • We like to go one higher.
27. OWASP Top 10
28. #1: Injection in ur dataz, droppin’ ur database
29. little bobby tables (thanks, xkcd!)
30. #1 Injection • Exploitability: EASY • Impact: SEVERE
31. #1 Injection • At best: waste CPU cycles. • At worst: goodbye, data.
32. #1 Injection • Most commonly: SQL injection • Also file paths: ../../../etc/passwd • And commands: `rm -rf /` • More exotic: XPATH, LDAP • Rails guys? • YAML
33. #1 Injection ### The many faces of SQLi ### # Destroy data Bobby”; DROP TABLE students; -- # “Comment to end of line” ^^^
34. #1 Injection ### The many faces of SQLi ### # Log in as anyone with any password ‘ UNION SELECT (“mynewpassword”) -- # ^ break quoting, modify WHERE clause
35. #1 Injection ### The many faces of SQLi ### # Make WHERE return all rows “ OR 1=1 OR “” == “ # ^ Make WHERE return all rows
36. #1 Injection • Never trust user input. • Never EVER trust user input. • User input will murder your app. • DON’T TRUST IT OK GUYS
37. #1 Injection • YAML • YAML Ain’t Markup Language • “human friendly data serialization”
38. #1 Injection ### YAML injection, oh my ### # Looks safe, right? YAML.load(GET[:param])
39. #1 Injection
40. #1 Injection • YAML • Serialization format • Create any objects. • Oops.
41. #1 Injection • Defending against injection. • “Lean not on your own understanding” • Use a library (see owasp.org) • Use a template language. • Filter user inputs at the start. • DATA DOESN’T RUN.
42. #1 Injection • Where can you inject things into an app? • Any GET/POST parameter • User profiles • Request headers • (Cookie data) • Uploaded data, remote-fetched data.
43. #1 Injection • Escape ALL THE THINGS • Use safe data formats (text, JSON, XML) • Trust no one.
44. #1 Injection • Impact: SEVERE • Exploitability: EASY • It’s not just SQLi • Don’t trust user input. Ever. • User input: not even once.
45. #2: Cross Site Scripting as known as XSS the angriest site scripting
46. #2 XSS • Exploitability: AVERAGE • Prevalence: VERY WIDESPREAD • Detectability: EASY • Impact: MODERATE
47. #2 XSS • Tricking the browser. • Can I get a logged in user to do something for me?
48. #2 XSS • Most commonly: “Stored,” can I put <script> somewhere you didn’t expect it? • Reflected — Using an error page • DOM-based: can I trick your JS?
49. #2 XSS • FREE PRIZE INSIDE • Give my user admin rights • Send me your password / CC# • Delete your own data • If done well, totally undetectable.
50. #2 XSS ### <script>, how do I love thee? ### ### Let me count the ways... ### “<script>...” “<scr” + “ipt>…” <a href=”/users/fred” onclick=”…”> <a href=‘javascript:…’>
51. #2 XSS ### <script>, how do I love thee? ### ### Let me count the ways... ### <script type=”text/javascript”> var data = <?php echo json_encode($obj); ?>; // ... </script>
52. #2 XSS ### <script>, how do I love thee? ### ### Let me count the ways... ### <script type=”text/javascript”> var data = {“users”: [{“id”: 1, “name”: “fred</script> <script>browser.pwn()</script> ”}]; // ... </script>
53. #2 XSS ### <script>, how do I love thee? ### ### Let me count the ways... ### <script type=”text/javascript”> var data = {“users”: [{“id”: 1, “name”: “fred</script> <!-- wtf? ok, keep parsing tag soup --> <script>browser.pwn()</script><!-- sweet! let’s run this --> ”}]; // ... </script> <!-- yeah, whatever -->
54. #2 XSS ### filter bypass ### # http://www.wocares.com/noquote.php // “browser.pwn()” -> String.fromCharCode(98,114,111,119,115,101,1 14,46,112,119,110,40,41) // “browser.pwn()” -> unescape(/%62%72%6f%77%73%65%72%2e %70%77%6e%28%29/.source)
55. #2 XSS ### reflected xss ### $(“#data”).get(“/users/fred/<script>…”) // GET /users/fred/<script> 404 Not found The page <script>… could not be located
56. #2 XSS • General Defense • Never trust user input. • Escape output URLs, Javascript data, error pages • Rely on program data, not user data.
57. #3: Broken Auth partner in crime: broken session management
58. #3 Broken Auth • Exploitability: AVERAGE • Prevalence: COMMON • Detectability: AVERAGE • Impact: SEVERE
59. #3 Broken Auth • Steal account information • Pretend to be someone else
60. #3 Broken Auth • Password resets • Session hijacking • Accounts that stay logged in “forever” • Private data in cookie
61. http://mysite.com/?sessionID=abc12345… #3 Broken Auth
62. #3 Broken Auth ### tcpdump / wireshark ### 12:09:17.433916 IP mysite.com.59661 > mysite.com.http-alt: Flags [P.], seq 1:164, ack 1, win 9186, options [nop,nop,TS val 563000202 ecr 563000202], length 163 ......a..G..#........ !...!...GET /?sessionID=abc1234… HTTP/1.1 User-Agent: curl/7.24.0 (x86_64-apple- darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8r zlib/ 1.2.5 Host: mysite.com:80 Accept: */*
63. #3 Broken Auth • O, LOL! Only hackers use that • Firesheep
64. #3 Broken Auth • Time out idle sessions. • Re-authenticate before destructive actions or accessing sensitive data. • Encrypt session cookies • (SSL or HMAC) • Multiple factors — something you know + something you have.
65. #3 Broken Auth • What should you worry about? • Your app. • Any other webapps you install. • phpMyAdmin, RoundCube, CMSes, etc. • Use SSL at the very least.
66. #4: Insecure Direct Object References it’s like a map to your secret data
67. #4 Insecure URLs • Exploitability: EASY • Prevalence: COMMON • Detectability: EASY • Impact: MODERATE
68. #4 Insecure URLs • Here’s my order: • https://myapp/orders/5 • What happens when I go to: • https://myapp/orders/6 ?
69. #4 Insecure URLs • Check permissions before accessing the item. • Use a “slug” (“opaque ID”) to protect URLs • http://myapp/orders/acefdaf912348 • Encrypt object references
70. #5: Cross-Site Request Forgery also known as XSRF or CSRF the angriest site request forgery
71. #5 CSRF • Exploitability: EASY • Prevalence: COMMON • Detectability: EASY • Impact: MODERATE
72. #5 CSRF • Similar to XSS • Try to get user to perform an action without their knowledge.
73. #5 CSRF • hidden <form action=”http://yourapp/delete/everything“> on a page on my site • your browser’s already logged in • <img src=”http://yourapp/delete/everything”/> • <iframe src=”http://yourapp/delete/everything”/>
74. #5 CSRF • Browser same-origin policies. • domain1 can’t read or change cookies sent by domain2 • Scripts from domain1 can’t make AJAX requests to domain2 • Doesn’t prevent DOM changes, like JSONP or injecting <img src=””>
75. #5 CSRF • No destructive actions over GET • Form authentication token. • Referrer checks are not enough (easy to forge) • #4 (re-authenticate after idle or before destructive actions)
76. #5 CSRF ### Form authenticity token ### # - Prevents <form> attacks # - Token is stored server-side and changes for each page request. # - Tokens expire after a few minutes <form> … <input type=”hidden” name=”csrftoken” value=”ab19acdefccabe”/> … </form>
77. #5 CSRF • Don’t rely on sessions to protect sensitive data. • Don’t roll your own, there’s a library for it.
78. #6: Security Misconfiguration I accidentally all your data
79. #6 Security Oops • Exploitability: EASY • Prevalence: COMMON • Detectability: EASY • Impact: MODERATE
80. #6 Security Oops • Running old software. • All the AppSec in the world don’t matter if underlying server is wide open. • Or if you use broken Open Source apps. • Failure to understand & use platform security limits. • (firewalls, file permissions, etc.)
81. #6 Security Oops • Subscribe to your framework’s security mailing list. •SEND THEM TO YOUR INBOX • Port-scan your server at least once. • Use intrusion detection software like OSSEC.
82. #6 Security Oops • PHP-specific • Suhosin patches • safe_mode (restricts file access & disables dangerous commands) • Run PHP under its own user account.
83. #6 Security Oops • Generally • Don’t run your app as root • Don’t run your web server as root • Expose only what you need (SSH, HTTP, and HTTPS should be enough) • Protect all public services.
84. #6 Security Oops • Generally • Think about a VPN.
85. 2-minute break http://www.flickr.com/photos/barmans/1122845192/
86. OWASP TOP 10 • Injection • XSS • Broken Authentication • IDs in URLs • Cross-Site Request Forgery (CSRF) • Security Misconfiguration • Bad Crypto • “Secret” pages • SSL oopses • Redirects to bad places
87. OWASP TOP 10 • Mystery BONUS ROUND • how you can kick ass at security http://www.flickr.com/photos/bagsgroove/5722251013/
88. #7: Crypto Mistakes no more secrets.
89. #7 Crypto Mistakes • Exploitability: DIFFICULT • Prevalence: UNCOMMON • Detectability: DIFFICULT • Impact: SEVERE
90. #7 Crypto Mistakes • Failure to protect data “at rest.” • Backups, too. • Failure to protect data “in flight.” • Misuse of crypto, wrong parameters.
91. #7 Crypto Mistakes • Misuse of crypto, wrong parameters. • Example: Hash padding attack
92. #7 Crypto Mistakes • Hash-extension or hash-padding attack • http://yourapp/api/request?sig=abcd • sig = sha1(secret + url) • If I known url and sig… • I don’t need secret!
93. #7 Crypto Mistakes • http://yourapp/api/request%80%00%00%00%00… &my_bad_parameters&sig=ccddeeff • I can derive a new sig for my bad URL • Not just SHA-1! • MD5, SHA-256, SHA-512, ...
94. #7 Crypto Mistakes HMAC (K,m) = H ((K ⊕ opad) ∥ H ((K ⊕ ipad) ∥ m)) K — secret key m — message H — hash algorithm (MD5, etc.) ⊕ — bitwise XOR ∥ — concatenate ipad/opad — tamper-resistant padding factors
95. #7 Crypto Mistakes • HMAC exists to defend against that attack. • Hash-based Message Authentication Code • Used in SSL
96. #7 Crypto Mistakes • The problems are subtle. • The math is complex. • Other common problems: • Use of weak crypto algorithms • Password hashing. • Small or non-random keys • Chosen plaintext attacks
97. #7 Crypto Mistakes • Passwords! • Yeah, MD5 those! • Rainbow tables? • Google “5f4dcc3b5aa765d61d8327deb882cf99” • = md5(“password”)
98. #7 Crypto Mistakes • Passwords! • Salted hash • Very common • DON’T DO THAT. • Hash algorithms are designed for speed • How ‘bout 5,000,000 hashes/second?
99. #7 Crypto Mistakes • Passwords! • Use a password hashing algorithm! • Passwords — low entropy. • “key stretching” • N rounds md5 • bcrypt, scrypt, PBKDF2
100. #7 Crypto Mistakes • Passwords! • Computers will only get faster. • Make your password algorithms configurable. • Don’t roll your own. • (phpass)
101. #7 Crypto Mistakes • Don’t half-ass crypto. Problems are hard and subtle. • Don’t roll your own. • Rely on common libraries and best practices. Don’t roll your own.
102. #8: “secret” URLs No one will think to look here!
103. #8 “secret” URLs • Exploitability: EASY • Prevalence: UNCOMMON • Detectability: AVERAGE • Impact: MODERATE
104. #8 “secret” URLs • http://yourapp/secret_page.php • No one knows but you! • Security through obscurity. • Don’t do it.
105. #8 “secret” URLs • Restrict access by IP. • Require authentication. • VPNs are nice.
106. #9: SSL leaks “secure socket layer”, not “swingin’ super leopard”. I know, right?
107. #9 SSL Leaks • Exploitability: DIFFICULT • Prevalence: COMMON • Detectability: EASY • Impact: MODERATE
108. #9 SSL Leaks • Leaking “secure” cookies over HTTP • (broken auth / XSRF)
109. #9 SSL Leaks • Mostly web server stuff • Weak crypto algorithms (BEAST and CRIME), bad certificate setups. • Also browser-related: secure cookies need to stay secure. • Use whynopadlock.com and Firebug to make sure all sensitive requests go over HTTPS
110. #7 Crypto Mistakes • “SSL is broken!!” • Not really. • “Broken” == “some orders of magnitude sooner than the heat-death of the universe” • BEAST? CRIME? Follow best practices.
111. #10: Bad Redirects “Buddy, you just 302’d into the wrong part of town.”
112. #10 Bad Redirects • Exploitability: AVERAGE • Prevalence: UNCOMMON • Detectability: EASY • Impact: MODERATE
113. #10 Bad Redirects • Let’s go phishing! • http://yourapp/login.php?redirect_to=http:// myfakeapp.com • Also redirects based on referrer, easy to fool.
114. #10 Bad Redirects • Redirect to known locations. • (maybe) Confirm before redirecting. • “You are being redirected to …”
115. BONUS ROUND!!!!!1
116. #11 BONUS: Run Uploaded Files hey, that’s a nice EVERYTHING
117. Run Uploaded Files • Mostly a PHP problem • What if I upload test.php? • … and your upload script puts it in / uploads/test.php • … and then I visit: http://yoursite/uploads/ test.php
118. doofus security, inc.
119. pwned!
120. Run Uploaded Files • Lots of tricks to safely handling uploads. • Files are DATA • DATA doesn’t run.
121. Run Uploaded Files • /data/store_123/upload.php • Store OUTSIDE of PHP docroot • Explicitly disable scripting engine, or write an access-control script that reads the file byte-by-byte. • Better yet, use S3.
122. OWASP TOP 10 • Injection • XSS • Broken Authentication • IDs in URLs • Cross-Site Request Forgery (CSRF) • Security Misconfiguration • Bad Crypto • “Secret” pages • SSL oopses • Redirects to bad places
123. we made it! http://www.flickr.com/photos/jayneandd/4450623309/
124. bacon break http://www.flickr.com/photos/cookbookman/6175755733
125. my goal • For you to kick ass at security
126. dev.awesome
127. dev.awesome • Every web app worries about security. • Good devs build security up front. • Keep your eyes open. • Keep learning and be ready to teach.
128. Who is responsible?
129. It’s you.
130. Learn from others • It’s an open source world! • See how other apps, frameworks, and libraries handle their security. • Spot vulns in someone else’s code • ASK QUESTIONS
131. Earn some XP! • Actually exploit a vulnerability (Capture the Flag!) • Don’t break the law :) • Write vulnerable code and write tests to demonstrate the problem. • Help with code reviews • Phone a friend! (Or a consultant)
132. fin.
133. Questions