top 10 web security vulnerabilities (owasp top 10)
Post on 27-Jan-2015
Embed Size (px)
DESCRIPTIONA presentation on the top 10 security vulnerability in web applications, according to OWASP.org
- 1. The Top 10 Security Vulnerabilities in Web Applications
- Brian Bex Huff
- Chief Software Architect
- Open Web Application Security Project (OWASP)
- Top 10 Security Vulnerabilities
- 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
- 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
- http://example.com/products?id= 123
- Hacker could instead supply this: http://example.com/products?id= ';+DROP+TABLE+'products';
- Dont: name your child
- Robert); DROP TABLE Students;--
- Do: expect SQL Injection
- "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:
- http://example.com/buy?item=' >
- Then, try to trick somebody to go to that URL
- Stolen cookies are frequently as good as stole passwords
- Never, ever, ever trust user-submitted content!
- URLs, comments threads, web forms
- Properly "escape" any data before displaying it on web pages
- 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
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
- 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:
- 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
- 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:
- 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
- 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"
- 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?