Security in practice with Java EE 6 and GlassFish
-
Upload
markus-eisele -
Category
Technology
-
view
7.453 -
download
4
Transcript of Security in practice with Java EE 6 and GlassFish
Markus Eisele & Masoud Kalali
Java EE 6 Security in practice with
GlassFish
Agenda
• Introduction
• The Top 10 Most Critical Web Application Security Risks
• Take Away
Markus Eisele http://blog.eisele.net
http://twitter.com/myfear [email protected]
Java EE 7 EG,
architect, husband, father of two, photographer, speaker, writer
Masoud Kalali http://kalali.me http://twitter.com/MasoudKalali [email protected] software engineer, author, blogger, climber and flute enthusiast
Java EE 6 & GlassFish
glassfish.org
Galleria Project
https://bitbucket.org/VineetReynolds/java-ee-6-galleria/
Galleria Project
http://blog.eisele.net/2012/03/java-ee-6-galleria-example-part-1.html
?
Galleria and Security
• Form based authentication
• JDBCRealm
• request.login(userId, new String(password));
• @RolesAllowed({ "RegisteredUsers" })
Enough? State-of-the-Art? Feeling-good-with-it™?
Motivation for this talk
• Seen a lot of Java EE out there with no or not enough security.
• Providing you a starting point
• Having seen a lot – sharing something
• Making you aware about security
• Finding out about “the security state of Galleria”
The Top 10 Most Critical Web Application Security Risks
Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0) Source: http://owasptop10.googlecode.com Aka OWASP Top-10*
What is OWASP?
• Open Web Application Security Project • Improving the security of (web) application software
– Not-for-profit organization since 2001 – Raise interest in secure development
• Documents – Top 10 – Cheat Sheets – Development Guides
• Solutions – Enterprise Security API (ESAPI) – WebScarab – WebGoat
A1 - Injection
What is it?
• Sending unintended data to applications
• Manipulating and reading Data stores (e.g. DB, LDAP)
• Java EE 6 affected:
– UI technology of choice (e.g. JSF, JSP)
– Database access (JPA, JDBC)
Worst-Practice Injection
String id = "x'; DROP TABLE members; --"; // user-input
Query query = em.createNativeQuery("SELECT * FROM PHOTO
WHERE ID =" + id, Photo.class);
Query query2 = em.createNativeQuery("SELECT * FROM MAG
WHERE ID ?1", Magazine.class);
query2.setParameter(1, id);
Prevent Injection
• Sanitize the input
• Escape/Quotesafe the input
• Use bound parameters (the PREPARE statement)
• Limit database permissions and segregate users
• Use stored procedures for database access (might work)
• Isolate the webserver
• Configure error reporting
A2 - Cross-Site Scripting (XSS)
What is it?
• Inject malicious code into user interfaces
• Get access to browser information – E.g. javascript:alert(document.cookie)
• Steal user’s session, steal sensitive data
• rewrite web page
• redirect user to phishing or malware site
• Java EE 6 affected: – UI technology of choice (e.g. JSF, JSP)
Worst Practices
<h:outputText value="#{user.content}" escape="false"/>
• Don’t sanitize at all
• Sanitize on your own <a href="data:text/html;base64,PHNjcmlwdD5hbGVydCgvWFNTLyk8L3NjcmlwdD4=">Test</a>
Prevent
• Sanitize the input
• Escape/Quotesafe the input
• Use Cookie flags:
– httpOnly (prevents XSS access)
https://code.google.com/p/owasp-esapi-java/
A3 - Broken Authentication and Session Management
What is it?
• Container Security vs. own solution • Session Binding / Session Renewal • Password Strength (length/complexity) • Plain text passwords (http/https) • Password recovery • Number of factors used for authentication
• Java EE 6 affected:
– JAAS / JASPIC – Filter / PhaseListener – Container and Web-App configuration
Worst Practice
• Authentication over http
• Custom security filter
• Not using Container Functionality
• No password strength requirements
• No HttpSession binding
• Saving Passwords
• Not testing security
Best Practices
• Go with provided Standard Realms and LoginModules whenever possible
• Use transport layer encryption (TLS/SSL)
• Use Cookie flags:
– secure (avoid clear text transmission)
A4 – Insecure Direct Object References
What is it?
• Accessing domain objects with their PK https://you.com/user/1 => https://you.com/user/21
• Opening opportunities for intruders
• Information hiding on the client
• Parameter value tampering
• Java EE 6 affected:
– All layers
– Especially data access
Worst Practice
• No data separation for users (tenants)
• No request mode access for data (RUD)
• No query constraints
Best Practices
• Use AccessReferenceMaps
• Use data-driven security
• Perform data authorization on the view
A5 - Cross Site Request Forgery (CSRF)
What is it?
• Basically a capture-replay attack
• Malicious code executes functions on your behalf while being authenticated
• Deep links make this easier
• JavaEE 6 affected:
– UI technology of choice (e.g. JSF, JSP)
Worst Practice
• Using a “secret Cookie”
• Only POST requests
• Wizard like transactions
• URL rewriting
Best Practices
• Add Unpredictability (tokens)
• CSRFPreventionForm http://blog.eisele.net/2011/02/preventing-csrf-with-jsf-20.html
• Use OWASP ESAPI http://www.jtmelton.com/2010/05/16/the-owasp-top-ten-and-esapi-part-6-cross-site-request-forgery-csrf/
A6 - Security Misconfiguration
What is it?
• Applies to – Operating System
– Application Server
– Databases
– Additional Services
• Includes (beside _many_ others) – Missing Patches
– All security relevant configuration
– Default accounts
Running GlassFish in a Secure Environment
• Use the latest version (3.1.2.2)
• Enable secure admin (TLS/https)
• Use password aliasing
• Enable security manager and put forth a proper security policy file
• Set correct file system permissions
http://blog.eisele.net/2011/05/securing-your-glassfish-hardening-guide.html http://docs.oracle.com/cd/E18930_01/html/821-2435/gkscr.html
Review the *.policy files
// Following grant block is only required by Connectors. If Connectors// are not in use the recommendation is to remove this
grant.grant {
permission
javax.security.auth.PrivateCredentialPermission "javax.resource.spi.security.PasswordCredential * \"*\"","read";};
• server.policy and granted.policy • Remove unused grants • Add extra permissions only to applications or
modules that require them, not to all applications deployed to a domain.
• Document your changes!
Worst Practices
• Not to redirect the default pages
• Using any defaults like: – Passwords: Admin, master password
– Network interface binding: Listening on 0.0.0.0
– Certificates: Self signed certificate
• Not restricting GlassFish user nor enabling security manager.
• Same security config for all environments
• Using a not hardened OS!
A7 - Failure to Restrict URL Access
What is it?
• Presentation layer access control
• Related to A4 – Insecure Direct Object References
Worst Practice
• Using home-grown security features instead of container provided ones
• Assuming people wont know some URLs to try them
• Assuming no one would miss use the extra permission and access they have
Java EE 6
• What you do to prevent A4 plus:
– Use Container security (security-constraint)
– Use programatic login of Java EE 6 if needed.
– Properly configure security realms
– Accurately map roles to principal/groups (auth-constraint / security-role-mapping)
– Only allow supported/required HTTP methods
– Accurately Categorize the URL patterns and permit the relevant roles for each
Best Practices
• Any no public URL should be protected
• Use container authentication/authorization features or extend on top of them
• If not enough use proven frameworks/ products to protect the resources
• If user can get /getpic?id=1x118uf it does not mean you should show /getpic?id=1x22ug
A8 - Insecure Cryptographic Storage
What is it?
• Sensitive data exposed to wrong persons
• Could be:
– Passwords
– Financial/Health care data
– Credit cards
GlassFish
• Protect the keystore
• Protect sensitive data – Use salted hashing or double hashing for
authentication realms (Custom realm development)
– Evaluate logging output
• Protect GlassFish accounts – Use aliasing to protect the password and keep the
master password safe to protect the aliases
Worst Practices
• Storing passwords in clear text without aliasing or the proper store
• Using file authentication realm
• Ignoring digest authentication/hashed password storage
• Keeping clear text copies of encrypted data
• Not keeping the keys/passwords well guarded
Prevention
• Identify sensitive data • Wisely encrypt sensitive data
– On every level (application, appserver, db) – with the right algorithm and – with the right mechanism
• Don’t keep clear text copies • Only authorized personnel have access to clear text
data • Keep the keys as protected as possible (HSM) • Keep offsite encrypted backups in addition to on-site
copies
A9- Insufficient Transport Layer Protection
What is it?
Worst Practice
• Using basic/form authentication without SSL
• Not using HTTPS for pages with private information
• Using default self signed certificate
• Storing unencrypted cookies
• Not setting cookies to be transmitted Cookie.setSecure(true)
• Forgetting about the rest of the infrastructure
GlassFish
• Properly configure HTTPS listener/s (set the right keystore)
• Install the right server certificates to be used by SSL listeners
• Properly configure the ORB over SSL listeners if needed (set the right keystore)
• Enable auditing under Security and and access log under HTTP Service
Java EE
• Group the resources in regard to transport sensitivity using web-resource-collection
• Use user-data-constraint as widely as you need for data integrity and encryption needs
• Ensure that login/logout pages (in case of form auth-type) are protected by <transport-guarantee>CONFIDENTIAL</transport-guarantee>
Best Practice
• Use TLS on all connections with sensitive data
• Individually encrypt messages
• Sign messages before transmission
• Use standard strong algorithms
• Use proven mechanisms when sufficient
A10 - Unvalidated Redirects and Forwards
What is it?
• Redirecting to another URL computed by user provided parameters
• Forward to another URL computed by user provided parameters
http://www.java.net/external?url=http://www.adam-
bien.com/roller/abien/entry/conveniently_transactionally_a
nd_legally_starting
Java EE 6
• Don’t use redirect or forward as much as possible
• Accurately verify/validate the target URL before forwarding or redirecting
• Redirects are safe when using container managed authentication/authorization properly
• Redirects happen without authentication and thus requires triple check to prevent unauthorized access.
Worst Practices
• Not using a proper access control mechanism (e.g container managed and proper security-constraint )
• Redirecting to a user provided parameter, e.g to an external website
• Not to validate/verify the target with user’s access level before doing the forward
WRAP-UP
Galleria Wrap Up
Security isn‘t all candy..
… but you will love it in the end!
CC picture reference
• http://www.flickr.com/photos/wallyg/2439494447/sizes/l/in/photostream/
• http://www.flickr.com/photos/62983199@N04/7188112487/sizes/l/in/photostream/
• http://www.flickr.com/photos/stuckincustoms/3466470709/sizes/l/in/photostream/
• http://www.flickr.com/photos/lukemontague/187987292/sizes/l/in/photostream/
• http://www.flickr.com/photos/082007/7108942911/sizes/l/in/photostream/
• http://www.flickr.com/photos/ndrwfgg/140411433/sizes/l/in/photostream/
• http://www.flickr.com/photos/gingerblokey/4130969725/sizes/l/in/photostream/
• http://www.flickr.com/photos/bpc009/3328427457/sizes/l/in/photostream/
• http://www.flickr.com/photos/marine_corps/6950409157/sizes/l/in/photostream/
• http://www.flickr.com/photos/cindy47452/2898015652/sizes/l/in/photostream/