top 10 web security vulnerabilities (owasp top 10)

Download Top 10 Web Security Vulnerabilities (OWASP Top 10)

Post on 27-Jan-2015




1 download

Embed Size (px)


A presentation on the top 10 security vulnerability in web applications, according to


  • 1. The Top 10 Security Vulnerabilities in Web Applications
    • Brian Bex Huff
  • Chief Software Architect

2. Agenda

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

3. Intro

  • What is OWASP?
    • 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 anassurance of security

4. 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

5. 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
  • 123
    • Hacker could instead supply this: ';+DROP+TABLE+'products';
  • ';+DROP+TABLE+'products';
    • ';+DROP+TABLE+'products';

6. Example

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

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

8. 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 = "";
  • Code expects a nice URL:
  • But a hacker could supply this:
    •' >
  • Then, try to trick somebody to go to that URL
    • Stolen cookies are frequently as good as stole passwords

9. 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
    • Preventsdocument.cookiefrom working in JavaScript

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

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

12. 4) Insecure Direct Object References

  • Assume my project id is123
  • I see a link on My Projects page that goes here:
    • 123
  • If I alter the URL, can I see other peoples 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

13. 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

14. 5) Cross Site Request Forgery (CSRF)

  • Evil sites can hijack your browser, and run secure request:
    • User logs into secure application behind the firewall
    • User goes to "evil" website, or loads up "evil" HTML email
    • HTML contains this image:
  • 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

15. 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"
    • avoidreusabletokens
  • 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?