Top 10 Web Security Vulnerabilities (OWASP Top 10)


Published on

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

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Top 10 Web Security Vulnerabilities (OWASP Top 10)

  1. 1. The Top 10 Security Vulnerabilities in Web Applications <ul><li>Brian “Bex” Huff </li></ul><ul><li>Chief Software Architect </li></ul>
  2. 2. Agenda <ul><li>Intro </li></ul><ul><li>Open Web Application Security Project (OWASP) </li></ul><ul><li>Top 10 Security Vulnerabilities </li></ul><ul><li>Countermeasures </li></ul>
  3. 3. Intro <ul><li>What is OWASP? </li></ul><ul><ul><li> </li></ul></ul><ul><ul><li>Worldwide non-profit focused on improving software security </li></ul></ul><ul><ul><li>Reaches out to ALL developers: not just security professionals </li></ul></ul><ul><li>Who am I? </li></ul><ul><ul><li>Oracle ACE Director </li></ul></ul><ul><ul><li>Author of 2 books on Oracle Technology </li></ul></ul><ul><ul><li>Twitter: @bex -- used to be @OWASP </li></ul></ul><ul><ul><li>Here to help all developers </li></ul></ul><ul><li>What will you learn? </li></ul><ul><ul><li>The top 10 security mistakes that developers make </li></ul></ul><ul><ul><li>How to design software with an assurance of security </li></ul></ul>
  4. 4. OWASP Top Ten <ul><li>Injection </li></ul><ul><li>Cross Site Scripting </li></ul><ul><li>Broken Authentication and Session Management </li></ul><ul><li>Insecure Direct Object References </li></ul><ul><li>Cross Site Request Forgery (CSRF) </li></ul><ul><li>Security Misconfiguration </li></ul><ul><li>Insecure Cryptographic Storage </li></ul><ul><li>Failure to Restrict URL Access </li></ul><ul><li>Insufficient Transport Layer Protection </li></ul><ul><li>Unvalidated Redirects and Forwards </li></ul>
  5. 5. 1) Injection <ul><li>Used when your app sends user-supplied data to other apps </li></ul><ul><ul><li>Database, Operating System, LDAP, Web Services </li></ul></ul><ul><li>Hackers &quot;inject&quot; their code to run instead of yours </li></ul><ul><ul><li>To access unauthorized data, or completely take over remote application </li></ul></ul><ul><li>Example: SQL injection attack String query = &quot;SELECT * FROM products WHERE name='&quot; + request.getParameter(&quot;id&quot;) +&quot;'&quot;; </li></ul><ul><ul><li>Code expects a nice parameter in the URL </li></ul></ul><ul><li> 123 </li></ul><ul><ul><li>Hacker could instead supply this: ';+DROP+TABLE+'products'; </li></ul></ul><ul><li>';+DROP+TABLE+'products'; </li></ul><ul><ul><li>';+DROP+TABLE+'products'; </li></ul></ul>
  6. 6. Example <ul><li>Don’t: name your child </li></ul><ul><li>Robert’); DROP TABLE Students;-- </li></ul><ul><li>Do: expect SQL Injection </li></ul>
  7. 7. Countermeasures <ul><li>&quot;Connections&quot; between systems are highly vulnerable </li></ul><ul><li>Always assume data coming in could be &quot;evil&quot; </li></ul><ul><ul><li>be sure to include &quot;evil&quot; use cases and user stories in your design </li></ul></ul><ul><li>Ideally, only allow the user to select among &quot;safe&quot; options </li></ul><ul><ul><li>no generic text allowed </li></ul></ul><ul><li>If user-input text is needed, use parameterized queries </li></ul><ul><ul><li>clean up quotes, parenthesis, and SQL comments </li></ul></ul><ul><li>Use a battle-tested library for protecting your database </li></ul><ul><ul><li>Java PreparedStatement, OWASP's ESAPI codecs </li></ul></ul>
  8. 8. 2) Cross Site Scripting <ul><li>Sites must &quot;cleanse&quot; user input before displaying it </li></ul><ul><li>Hackers can create URLs to inject their own HTML onto the page </li></ul><ul><ul><li>can be used to do almost any kind of attack!!! </li></ul></ul><ul><li>Example: JSP to draw HTML based on user input </li></ul><ul><ul><li>String html = &quot;<input name='item' type='TEXT' value='&quot; + request.getParameter(&quot;item&quot;) + &quot;'>&quot;; </li></ul></ul><ul><li>Code expects a nice URL: </li></ul><ul><ul><li> </li></ul></ul><ul><li>But a hacker could supply this: </li></ul><ul><ul><li>' ><script>document.location=''+document.cookie </script> </li></ul></ul><ul><li>Then, try to trick somebody to go to that URL </li></ul><ul><ul><li>Stolen cookies are frequently as good as stole passwords </li></ul></ul>
  9. 9. Countermeasures <ul><li>Never, ever, ever trust user-submitted content! </li></ul><ul><ul><li>URLs, comments threads, web forms </li></ul></ul><ul><li>Properly &quot;escape&quot; any data before displaying it on web pages </li></ul><ul><ul><li>JavaScript parameters, URL parameters, STYLE elements </li></ul></ul><ul><ul><li>Remove script tags, and possibly anything with a SRC attribute </li></ul></ul><ul><ul><li>Use ESAPI to &quot;cleanse&quot; your HTML </li></ul></ul><ul><li>Do not allow state-change from HTTP GET requests </li></ul><ul><ul><li>Otherwise, an IMG tag could cause you to lose all your data </li></ul></ul><ul><li>Set the HttpOnly flag in your response headers </li></ul><ul><ul><li>Prevents document.cookie from working in JavaScript </li></ul></ul>
  10. 10. 3) Broken Authentication and Session Management <ul><li>HTTP is a &quot;stateless&quot; protocol </li></ul><ul><ul><li>Nice and simple: HTTP request, HTTP response </li></ul></ul><ul><ul><li>All data must be passed in the request every time </li></ul></ul><ul><li>How do we store state? </li></ul><ul><ul><li>Client side with cookies </li></ul></ul><ul><ul><li>Server side with sessions </li></ul></ul><ul><li>Most apps place a &quot;sessionId&quot; in cookies, or in the URL </li></ul><ul><ul><li>Problem: now stealing sessionIds is just as good as stealing passwords! </li></ul></ul><ul><li>Multiple ways to determine a session ID </li></ul><ul><ul><li>packet sniffing -- especially on an open WiFi access point </li></ul></ul><ul><ul><li>HttpReferrer logs, if sessionId is in the URL </li></ul></ul>
  11. 11. Countermeasures <ul><li>Assume that a user stole a session ID </li></ul><ul><ul><li>Determine how bad this would be in your application </li></ul></ul><ul><li>Use SSL everywhere! </li></ul><ul><ul><li>Makes it harder for people to “sniff” your session ID </li></ul></ul><ul><li>If you cannot use SSL everywhere, use it for logins </li></ul><ul><ul><li>Have a cryptographically strong session ID </li></ul></ul><ul><li>Good sessionIds should be very difficult to re-use </li></ul><ul><ul><li>Embed user IP address, user name, timestamp, and a secret </li></ul></ul><ul><ul><li>Forces an attacker to spoof IP addresses to take over </li></ul></ul><ul><ul><li>Prompt for re-login if IP changes during a session </li></ul></ul>
  12. 12. 4) Insecure Direct Object References <ul><li>Assume my project id is 123 </li></ul><ul><li>I see a link on “My Projects” page that goes here: </li></ul><ul><ul><li> 123 </li></ul></ul><ul><li>If I alter the URL, can I see other people’s projects? </li></ul><ul><ul><li> 124 </li></ul></ul><ul><li>Do you only restrict access in the web form? </li></ul><ul><li>What if I could &quot;guess&quot; the URL? Could I see the page? </li></ul><ul><ul><li>Don't trick yourself into thinking complex URLs are any more secure </li></ul></ul><ul><ul><li>Security != Obscurity </li></ul></ul>
  13. 13. Countermeasures <ul><li>Every resource needs a security level </li></ul><ul><ul><li>What roles do you need to access certain items? </li></ul></ul><ul><ul><li>Access Control Lists are easy to implement, but don’t always scale </li></ul></ul><ul><li>All access to that resource should go through the same check </li></ul><ul><ul><li>What action are you taking, with what resource? </li></ul></ul><ul><ul><li>Put it all in one common codebase for simplicity </li></ul></ul><ul><ul><li>May need to run check multiple times, for sub-actions and sub-resources </li></ul></ul><ul><ul><li>Unusual behavior? Have additional authentication questions/layers! </li></ul></ul><ul><li>Front-end restriction is nice for usability, but not security </li></ul><ul><li>Back-end application must double-check access rights </li></ul>
  14. 14. 5) Cross Site Request Forgery (CSRF) <ul><li>Evil sites can hijack your browser, and run secure request: </li></ul><ul><ul><li>User logs into secure application behind the firewall </li></ul></ul><ul><ul><ul><ul><li> </li></ul></ul></ul></ul><ul><ul><li>User goes to &quot;evil&quot; website, or loads up &quot;evil&quot; HTML email </li></ul></ul><ul><ul><li>HTML contains this image: </li></ul></ul><ul><ul><ul><ul><li><img src=&quot; deleteEverything &quot;></img> </li></ul></ul></ul></ul><ul><li>With JavaScript and XSS, evil sites can completely take over your browser </li></ul><ul><ul><li>Can browse around your intranet, log into bank accounts </li></ul></ul><ul><ul><li>Anything you are currently logged into </li></ul></ul><ul><ul><li>Complete control , as long as you stay on the evil site </li></ul></ul><ul><li>Unfortunate side-effect of Single-Sign-On </li></ul>
  15. 15. Countermeasures <ul><li>All state change should require a unique token in the request </li></ul><ul><li>But if its in the URL, it's vulnerable! </li></ul><ul><ul><li>URLs are frequently logged, and can be &quot;sniffed&quot; </li></ul></ul><ul><ul><li>avoid reusable tokens </li></ul></ul><ul><li>General solution: </li></ul><ul><ul><li>All state change requires HTTP POST, not a GET </li></ul></ul><ul><ul><li>Put one-time token in a hidden field on the web form </li></ul></ul><ul><ul><li>After POST, do a GET redirect to a confirmation page </li></ul></ul><ul><li>What kind of token? </li></ul><ul><ul><li>Single-request tokens: safest, but a pain </li></ul></ul><ul><ul><li>Session-based tokens hashed with session ID and action </li></ul></ul><ul><li>Require multiple-level authentication </li></ul><ul><ul><li>If an action looks fishy, re-prompt user for login </li></ul></ul>
  16. 16. 6) Security Misconfiguration <ul><li>Most web applications depend on some kind of framework </li></ul><ul><ul><li>Weblogic, Spring, ADF, Ruby on Rails, Open Source Libraries </li></ul></ul><ul><ul><li>JARs and JARs and JARs of fun... </li></ul></ul><ul><li>What if your framework issued a security patch? </li></ul><ul><ul><li>Do you have a centralized policy for keeping dependencies up-to-date? </li></ul></ul><ul><ul><li>How long would it take you to discover new code? </li></ul></ul><ul><ul><li>How long would it take to recompile/test/redeploy? </li></ul></ul><ul><li>Do you know all security configurations in the framework? </li></ul><ul><ul><li>Odds are no... documentation is usually obtuse </li></ul></ul><ul><ul><li>“Being helpful is a security hole” </li></ul></ul><ul><li>Have you properly &quot;hardened&quot; your framework? </li></ul><ul><ul><li>Delete default users, disable unused services and ports </li></ul></ul>
  17. 17. Countermeasures <ul><li>Subscribe to newsletters and blog feeds to get patches </li></ul><ul><ul><li>Install the patches as quickly as possible </li></ul></ul><ul><li>Do periodic scans to detect misconfiguration / missing patches </li></ul><ul><li>Disable features that are &quot;nice&quot; for developers, but &quot;nasty&quot; for security </li></ul><ul><li>Use automation to ensure patches are up-to-date </li></ul><ul><ul><li>If you can't verify it, it's not secure </li></ul></ul><ul><ul><li>Can you prove glass is bulletproof without firing bullets at it? </li></ul></ul><ul><li>Taking over websites shouldn't be this easy: </li></ul><ul><ul><li> </li></ul></ul>
  18. 18. 7) Insecure Cryptographic Storage <ul><li>All applications store sensitive data </li></ul><ul><ul><li>Credit cards, passwords, secure documents </li></ul></ul><ul><li>How much &quot;sensitive&quot; data is in your log files? </li></ul><ul><ul><li>In general, or for exotic errors? </li></ul></ul><ul><li>How are you preventing unauthorized access to these resources? </li></ul><ul><li>If somebody stole your backup tapes, how bad would it be? </li></ul>
  19. 19. Countermeasures <ul><li>If you store secrets, encrypt them! </li></ul><ul><ul><li>Use only battle-tested standard encryption algorithms </li></ul></ul><ul><li>Analyze possible threats: inside attack, external user </li></ul><ul><ul><li>Make sure encryption policy is appropriate for the threats </li></ul></ul><ul><li>Encrypt data anywhere it's stored long term </li></ul><ul><ul><li>Especially backups! </li></ul></ul><ul><ul><li>Store backups of decryption keys separately from data </li></ul></ul><ul><li>Restrict access to decrypted data to only authorized users </li></ul><ul><li>Hash all passwords with a standard algorithm, and a &quot;salt&quot; </li></ul><ul><li>Use strong keys to access the information </li></ul><ul><li>Create a password management policy, and stick with it! </li></ul>
  20. 20. 8) Failure to Restrict URL Access <ul><li>Similar to #4: Insecure Direct Object Reference </li></ul><ul><ul><li>Need to block specific actions , even if no resource is identified </li></ul></ul><ul><li>Example: my project is 123 </li></ul><ul><li>I will see these URLs on my home page: </li></ul><ul><ul><li> </li></ul></ul><ul><ul><li> </li></ul></ul><ul><li>I could fish around and try other URLs as well: </li></ul><ul><ul><li> manager/getProjects/ </li></ul></ul><ul><ul><li> admin/getProjects/ </li></ul></ul><ul><li>Would your application prevent this? </li></ul><ul><li>Same general issue: </li></ul><ul><ul><li>you have front-end security, but not back-end security </li></ul></ul>
  21. 21. Countermeasures <ul><li>Do authentication checks at least twice </li></ul><ul><ul><li>Front end UI, and back end Controller </li></ul></ul><ul><li>Don't draw URLs to the page if the user cannot access them </li></ul><ul><ul><li>Bad usability </li></ul></ul><ul><ul><li>Hackers might be tempted to fish around for vulnerabilities </li></ul></ul><ul><li>Never assume a URL is allowed </li></ul><ul><ul><li>Do back-end checks for access, and state change </li></ul></ul><ul><li>Add even more layers as needed: </li></ul><ul><ul><li>Does all security information exist in the URL? </li></ul></ul><ul><ul><ul><li>Can you authenticate right away? </li></ul></ul></ul><ul><ul><ul><li>Might you need to get half way through the request before you know what rights are needed? </li></ul></ul></ul><ul><ul><li>What if the user has access, but their behavior is unusual </li></ul></ul><ul><ul><ul><li>should you prompt for password again, or perhaps for additional authorization? </li></ul></ul></ul>
  22. 22. 9) Insufficient Transport Layer Protection <ul><li>How is sensitive information sent from the user to your server? </li></ul><ul><ul><li>When they log in, or view sensitive data? </li></ul></ul><ul><li>How do you send that information to other systems? </li></ul><ul><ul><li>JDBC call, Web Services, JMS, emails </li></ul></ul><ul><li>It is shockingly easy to eavesdrop on web traffic </li></ul><ul><ul><li>Probably no surprise to this crowd ;-) </li></ul></ul><ul><li>Wireless access points make it even easier </li></ul><ul><ul><li>Need password encryption at the WEP/WAP layer </li></ul></ul>
  23. 23. Countermeasures <ul><li>Use strong, standards compliant network security protocols </li></ul><ul><li>Use TLS (SSL) on all connections with sensitive data </li></ul><ul><li>Encrypt messages before transmission </li></ul><ul><ul><li>XML-Encryption </li></ul></ul><ul><li>Sign messages before transmission </li></ul><ul><ul><li>XML-Signature </li></ul></ul><ul><li>Disable old, flawed encryption algorithms (ie, SSL 2.0) </li></ul><ul><li>If HTTPS is impractical, at the very least secure the login process </li></ul>
  24. 24. 10) Unvalidated Redirects and Forwards <ul><li>Most sites allow redirects to other sites, or pages within the site: </li></ul><ul><ul><li> </li></ul></ul><ul><li>But, open redirect pages can be used by &quot;phishers&quot; to create links to their site: </li></ul><ul><ul><li> </li></ul></ul><ul><li>Link looks like it goes to &quot;;, but it goes to &quot;; </li></ul><ul><li>Or, can trick a site user into harming their own site: </li></ul><ul><ul><li> /admin.jsp?deleteEverything=true </li></ul></ul><ul><li>Sometimes called &quot;phishing holes&quot; </li></ul>
  25. 25. Countermeasures <ul><li>Restrict redirects to a limited number of &quot;trusted&quot; sites </li></ul><ul><li>Keep a list of all redirect URLs, and pass the ID in the request, instead of the URL </li></ul><ul><ul><li> </li></ul></ul><ul><li>Hash the URL with a secret, and pass the hash in the URL </li></ul><ul><ul><li> </li></ul></ul><ul><li>Question: are URL shorteners inherently unsafe? </li></ul><ul><ul><li>TinyUrl offers a &quot;preview&quot; feature: others should as well </li></ul></ul><ul><li>Question: does this URL look like a Google Invoice to you? </li></ul><ul><ul><li> </li></ul></ul>
  26. 26. Further Recommendations <ul><li>Read the entire OWASP Top 10 </li></ul><ul><ul><li> </li></ul></ul><ul><li>Read through the ESAPI documentation, and use it! </li></ul><ul><ul><li> </li></ul></ul><ul><li>Quiz your developers about what security is needed and why </li></ul><ul><li>Audit to find threats with biggest business impact </li></ul><ul><li>Reminder: security is everybody's responsibility! </li></ul>
  27. 27. <ul><li>My Company: </li></ul><ul><li>My Blog: </li></ul><ul><li>My Tweets: @bex </li></ul><ul><li>My Self: [email_address] </li></ul>Questions?