Security Vulnerabilities: How to Defend Against Them
•
1 j'aime•442 vues
In recent years it became the norm to wake up to news about hackers, cyber attacks, ransom campaigns and NSA. Since 2003 the Open Web Application Security Project (OWASP) is the go-to reference to learn more about security vulnerabilities. OWASP published a list of the Top 10 most common security issues for Web. In this talk, we will review the list to learn the details and discuss how to harden and defend our Web applications from those vulnerabilities. If you care about your product and customer's data, want to become a better developer or are simply interested in the kind of cyber attacks delinquents use to compromise websites, this talk is for you.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Security Vulnerabilities: How to Defend Against Them
Similaire à Security Vulnerabilities: How to Defend Against Them (20)
Plus de Martin Vigo
Plus de Martin Vigo (13)
Dernier
Dernier (20)
Security Vulnerabilities: How to Defend Against Them
- 1. UPCOMING COURSES Node.js 101 Nov 16 @ITESO UX Workshop Sessions: Qualitative Research Dec 2 @GDL Portable Stream and Batch: Processing with Apache Beam Dec 2 @GDL - In partnership w/ Google & Apache Software Foundation Vue.js Workshop Dec 9 @CDMX Grow your career: Free courses in Artificial Intelligence, Software Development, User Experience and More @WizelineAcademy /WizelineAcademy academy.wizeline.com Get notified about courses: tinyurl.com/WL-academy
- 2. Common Web Vulnerabilities and how to defend against them Martin Vigo @martin_vigo martinvigo.com
- 3. Martin Vigo Galicia, Spain Senior Product Security Engineer Web, Mobile, Authentication Research, bug bounties & Gin tonics @martin_vigo ⇹ martinvigo.com ⇹ martinvigo@gmail.com
- 5. Web & Mobile
- 6. Web VS Mobile common vulnerabilities
- 7. Injection
- 8. An attacker is able to execute arbitrary code on Flickr servers by just sending POST requests
- 9. SQL Injection Web Application userName=”admin” password=”qwerty” POST request query Database SELECT * FROM users WHERE username = ‘admin‘ AND password = ‘qwerty‘; String query = “SELECT * FROM users WHERE username = ‘“ + userName + “‘ AND password = ‘‘’ + password + ”‘;”
- 10. SQL Injection String query = “SELECT * FROM users WHERE username = ‘“ + userName + “‘ AND password = ‘‘’ + password + ”‘;” Web Application userName=”’ OR ‘1’=’1’ --” password=”” POST request query Database SELECT * FROM users WHERE username = ‘‘ OR ‘1’=’1’ --‘ AND password = ‘‘;
- 11. More advanced attacks ● Checking database version ○ SELECT @@version ● Blind SQLi ○ Trial/Error ■ SELECT * FROM users WHERE id = '5' OR '1'='1'; ■ SELECT * FROM users WHERE id = '5' AND '1'='2'; ○ Timing attacks ■ IF EXISTS (SELECT * FROM creditcards) waitfor delay '0:0:5' ● File upload + Remote Code Execution ○ ‘ UNION SELECT “<? system($_REQUEST[‘cmd’]); ?>”,2,3 INTO OUTFILE ‘/var/www/test/execcmd.php’ ● And more! ○ Check out SQLMap ● Other injection attacks ○ LDAP, OS Commands, etc.
- 12. Recommendations ● Assume all user input is bad ● Parameterized queries ○ Stored procedures ● Escaping ○ Single quotes are specially dangerous ● Pattern checkhitelists ○ Full names, phone numbers, emails ● Whitelists ● Protect the infrastructure ○ DB is run by low privilege user ○ DB sits on a separate environment stmt = “SELECT * FROM users WHERE username = ? AND password = ?; stmt.setString(1, userName); stmt.setString(2, password);
- 14. An attacker is able to execute arbitrary code on Flickr servers by just sending POST requests
- 16. LastPass, a popular, cloud based, password manager encrypts all passwords and claims zero-knowledge. An attacker is able to look at the encrypted data and obtain cleartext passwords
- 17. Crypto ● Cryptography is hard! ● Encoding != Encryption ● Multiple crypto algorithms ○ Many broken ○ Or tricky to implement securely ■ Insufficient Key length ■ Global keys ■ Null IVs ■ Insecure PRNGs Cleartext AES-ECB AES-CBC
- 18. Password storage ● In cleartext ○ Insecure ● Encrypted ○ Unnecessary risk ● Hashed with broken algorithms ○ Crackeable ● Unsalted ○ Rainbow tables ● Without using Key-derivation functions ○ Brute-forceable
- 19. Insecure communication ● HTTP ○ Cleartext protocol ○ No confidentiality, integrity or identification ● HTTPS ○ Weak cipher suites ■ POODLE, BEAST, Lucky 13 ○ Not enforced ■ SSLStrip ○ Mixed content ■ Cookies leak ● Certificates ○ Self signed ○ No host validation
- 20. Recommendations ● Crypto ○ Only use standards ○ 128 minimum key length ○ Non global, random, unique keys ● Password storage ○ Don’t store passwords! ○ Store hashes ■ MD5 broken, SHA1 deprecated ■ Salted per user ■ Use Key derivation functions ● Bcrypt, Script, PBKDF2 ● Communications ○ Only HTTPS ■ TLS 1.1 or above ○ Enforce it! ■ HSTS, CSP ○ Trusted, signed certs only ○ Key pinning
- 21. LastPass, a popular, cloud based, password manager encrypts all passwords and claims zero-knowledge. An attacker is able to look at the encrypted data and obtain cleartext passwords
- 23. An attacker is able to make one single GET request to Facebook and obtain the /etc/passwd file
- 24. XML ● It’s a Markup Language ● DTD defines the structure of the XML document ○ Can be a separate file and stored externally ● Entities are pointers to data ○ Can also point externally
- 25. XXE ● Targets XML parsers ○ Caused mostly by misconfiguration ● Attacker sends specially crafted XML payloads ○ References to external entities ● XML parsers present everywhere ○ Document formats (OOXML, ODF, PDF) ○ Image formats (SVG, EXIF Headers) ○ Configuration files ○ Networking Protocols (SOAP, SAML)
- 26. Remote File Read XXE Threats Remote Code Execution Denial of Service SSRF
- 27. Recommendations ● Know and audit your XML parsers ● DIsable DTDs completely ○ Disallow an inline DTD ○ Do not include external entities ○ Do not include parameter entities ○ Do not include external DTDs ● Validate and sanitize ● Great cheat sheet: www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sheet
- 28. An attacker is able to make one single GET request to Facebook and obtain the /etc/passwd file
- 30. Samy Kamkar, a famous security researcher, was able to shut down the #1 site in the internet at the time, MySpace. He did that by simply updating his profile
- 31. Code VS Data <body> <div id="foo">Hello World!</div> </body> Tag name Attribute name Attribute value Text content Data Code
- 32. What if…? <body> <div id="">Hello World!</div> </body> Data Code We want to set id as foo”>bar
- 35. What if…? <body> <div id="foo”></div> </body> Data Code Attacker reflected input is </div><img src=x onerror=”alert(‘hacked!’)”><div>
- 36. <body> <div id="foo”></div><img src=x onerror=”alert(‘hacked!’)”><div></div> </body> Data Code Javascript handler Interpreted as Javascript code Invalid URI Triggers error Game over!
- 37. XSS Delivering malicious payloads to trick the browser into interpreting it as code instead of data allowing an attacker to execute arbitrary javascript code in the domain context. Martin Vigo @ Wizeline Academy 2017
- 38. XSS Threats ● Session hijacking ○ Steal cookies using document.cookie ● Phishing ○ Modify the UI and display fake login page ● Data leakage ○ Parse DOM and exfiltrate data with XHR requests to attacker’s domain ● Abuse HTML5 APIs ○ Access user’s geolocation, webcam, microphone, etc. ● Mining crypto currencies ○ Coinhive ● All this and much more! ○ Check out the BeEF Project!
- 39. Types ● Non-persistent XSS ○ Malicious payload is reflected off the server to the DOM ○ Usually delivered in URLs parameters ■ SPAM campaigns, Clickbaits, etc. ○ Usually obfuscated ■ https://www.google.com/search?q=%3c%73%63%72%69%70%74%3e%61%6c%65%72%74%28%27 %68%61%63%6b%65%64%21%27%29%3c%2f%73%63%72%69%70%74%3e ■ http://bit.ly/2ihPpjZ ○ DOM-Based XSS is a special non-persistent case ● Persistent XSS ○ Malicious payload is stored server side ○ Payload is rendered everytime victim requests the page ○ Most dangerous one
- 40. How do we fix this?
- 41. Encoding & escaping ● Encode HTML special characters ○ Tells the browser it is data, not code ○ <script>alert('Hacked!')</script> ● Be aware of the different contexts ○ And the different parsers! ■ And the different encodings! ● Use existing libraries that do all this for you!
- 42. Add security layers ● Use Content Security Policy ○ Instruct browser what is allowed and trusted origins ■ Content-Security-Policy: default-src ‘self’; script-src 'self' ● Serve the X-XSS-Protection header ○ Helps prevent reflected XSS ○ Protects old browsers that don’t support CSP ● Protect your sensitive cookies with httponly flag ○ Disables document.cookie
- 43. Samy Kamkar, a famous security researcher, was able to shut down the #1 site in the internet at the time, MySpace. He did that by simply updating his profile
- 45. Millions of routers fully compromised after victims visited the router’s official forum site
- 46. Let’s talk about cookies! ● Key-value pairs that help store client side states ○ Used specially for authentication ● Cookies are assigned to domains ● Cookies are sent on every request ● Based on the domain
- 47. Consider this (fake) request example GET /tranfer?fromAccount=123456789&toAccount=987654321&amount=1000 HTTP/1.1 Host: www.bankofamerica.com Cookie: SID=EB68E4C2C74410C7A2288CE7878803CC
- 48. What if victim visits a malicious site? <img src=”https://www.bankofamerica.com/tranfer?fromAccount=123456789&toAccount=987654321&amount=1000”>
- 49. Cookies are sent along SID=EB68E4C2C74410C7A2288CE7878803CC <img src=”https://www.bankofamerica.com/tranfer? fromAccount=123456789&toAccount=987654321&amount=1000”>
- 50. CSRF ● Forces victims to make unsolicited requests ● Targets state changing requests ○ Because of Same Origin Policy ● Usually POST requests ○ In a RESTful world ● Takes advantage of how cookies work
- 51. How do we fix this?
- 52. CSRF Tokens ● Include a random value in the request ○ Called a “CSRF token” ● Unique per session ● Attacker can’t guess it ● Use it to validate the request POST /transfer HTTP/1.1 Host: www.bankofamerica.com Cookie: SID=EB68E4C2C74410C7A2288CE7878803CC Content-Length: 55 fromAccount=123456789&toAccount=987654321&amount=1000&CSRFToken=s4frwwd4543RFwcdwk
- 53. Millions of routers fully compromised after victims visited the router’s manufacturer forum site
- 54. Referal Leakage
- 55. External parties were receiving secret DropBox links in their servers that allowed full access to DropBox’s customer files
- 56. The Referer Header ● Contains the URL of a previous item which led to this request ○ Click on a link on google.com to martinvigo.com ○ martinvigo.com knows that the person came from Google ● Used for analytics, marketing and tracking and SPAM. No real practical use ● It is misspelled!
- 57. Threat ● Many sites hide sensitive information behind unique, non-bruteforceable URLs ○ Usually when authentication is not possible ○ Security relies on the secrecy of the URL ● Very common when sharing documents, links for flights checking, reset password links, etc. ● If the unique URL site contains a link to a different domain ○ It will send the Referer header containing the secret URL!
- 58. Recommendations ● As a user ○ Install a privacy browser plugin ○ removes the referer header among others ● As a developer ○ Avoid putting secrets in the URL ■ Session ids ■ CSRF tokens ■ Personal data ○ Add <meta name="referrer" content="no-referrer" /> to your pages containing secrets
- 59. External parties were receiving secret DropBox links in their servers that allowed full access to DropBox’s customer files
- 60. There is more, much more...
- 61. Cookie flags missing JSONP injection CORS with wildcard Open redirects TRACE method support Clickjacking Denial of Service Client side checks only URL bruteforcing Response splitting Missing bruteforce protections Username enumeration Caching sensitive data Insufficient entropy SSRF SOME attack File Path Traversal Unrestricted file upload Deserialization vulnerabilities IDOR vulnerabilities
- 62. Takeaways Think like a hacker All user input is malicious Add multiple security layers Follow standards, recommendations and best practices Read, learn, practice and apply Break stuff!
- 63. Resources ● Learn for free ○ SecurityTube megaprimers, Cybrary ○ Online university courses ■ Coursera ● Cryptography I by Dan Boneh ■ Udemy ● Read and practice ○ The Tangled Web, The Web Application Hacker's Handbook ● Vulnerable websites you can legally hack! ○ Webgoat, Google Gruyere, Juice Shop Project ● Join bug bounty programs ○ HackerOne, Bugcrowd, Synack
- 65. Thank You! Survey: bit.ly/salesforce2017 Grow your career: Free courses in Artificial Intelligence, Software Development, User Experience and More @WizelineAcademy /WizelineAcademy academy.wizeline.com Get notified about courses: tinyurl.com/WL-academy