Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Java EE 6 Security in practice with GlassFish


Published on

Slides for the #JavaOne Session ID: CON11881

Published in: Technology
  • Be the first to comment

Java EE 6 Security in practice with GlassFish

  1. 1. Java EE 6 Security in practice with GlassFish Markus Eisele & Masoud Kalali
  2. 2. Agenda• Introduction• The Top 10 Most Critical Web Application Security Risks• Take Away
  3. 3. Masoud Kalali Markus Eisele http://blog.eisele.net Markus.eisele@msg-systems.comsoftware engineer, Java EE 7 EG,author, blogger, architect, husband, father of two,climber and flute enthusiast photographer, speaker, writer
  4. 4. Java EE 6 & GlassFish
  5. 5. Galleria Project
  6. 6. Galleria Project ?
  7. 7. Galleria and Security• Form based authentication• JDBCRealm• request.login(userId, new String(password));• @RolesAllowed({ "RegisteredUsers" })Enough? State-of-the-Art? Feeling-good-with-it™?
  8. 8. Motivation for this talk• Seen a lot• Providing a starting point• Sharing something• Making you aware• Plus: Finding out about “the security state of Galleria”
  9. 9. The Top 10 Most Critical Web Application Security Risks Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0)Aka OWASP Top-10* Source:
  10. 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
  11. 11. A1 - Injection
  12. 12. 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)
  13. 13. How to spot itString id = "x; DROP TABLE members; --"; // user-inputQuery query = em.createNativeQuery("SELECT * FROM PHOTOWHERE ID =" + id, Photo.class);Query query2 = em.createNativeQuery("SELECT * FROM MAGWHERE ID ?1", Magazine.class);query2.setParameter(1, id);
  14. 14. 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
  15. 15. A2 - Cross-Site Scripting (XSS)
  16. 16. 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 or parts• Redirect user to phishing or malware site• Java EE 6 affected: – UI technology of choice (e.g. JSF, JSP)
  17. 17. How to spot it• Problems with sanitizing<h:outputText value="#{user.content}" escape="false"/>• Weird Input<ahref="data:text/html;base64,PHNjcmlwdD5hbGVydCgvWFNTLyk8L3NjcmlwdD4=">Test</a>
  18. 18. Prevent• Sanitize the input• Escape/Quotesafe the input• Use Cookie flags: – httpOnly (prevents XSS access)
  19. 19. A3 - Broken Authentication andSession Management
  20. 20. What is it?• Container Security vs. own solution• Session Binding / Session Renewal• Passwords – Strength (length/complexity) – Plain text passwords (http/https) – Recovery mechanisms• Number of factors used for authentication• Java EE 6 affected: – JAAS / JASPIC – Filter / PhaseListener – Container and Web-App configuration
  21. 21. How to spot it• Authentication over http• Custom security filter• Not using Container Functionality• No password strength requirements• No HttpSession binding• Way of saving Passwords• Not testing security
  22. 22. Best Practices• Go with provided Standard Realms and LoginModules whenever possible• If you need custom ones: Test them extremely carefully!• Use transport layer encryption (TLS/SSL)• Use Cookie flags: – secure (avoid clear text transmission)
  23. 23. A4 – Insecure Direct Object References
  24. 24. What is it?• Accessing domain objects with their PK =>• Opening opportunities for intruders• Information hiding on the client• Parameter value tampering• Java EE 6 affected: – All layers – Especially data access
  25. 25. How to spot it• Data separation for users (tenants)• Request mode access for data (RUD)• Query constraints
  26. 26. Best Practices• Use AccessReferenceMaps http://app?file=Report123.xls http://app?file=1 http://app?id=9182374 http://app?id=7d3J93• Validate object references• Use data-driven security• Always Perform additional data authorization on the view
  27. 27. A5 - Cross Site Request Forgery (CSRF)
  28. 28. 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)
  29. 29. How to spot it• A “secret Cookie”• Only POST requests• Wizard like transactions• Simple URL rewriting
  30. 30. Best Practices• Add Unpredictability (tokens) – Hidden Field, Single-Use URLs – Request or Session Scope• CSRFPreventionForm (JSF 1.2 & 2)• Use OWASP ESAPI site-request-forgery-csrf/
  31. 31. A6 - Security Misconfiguration
  32. 32. What is it?• Applies to – Operating System – Application Server – Databases – Additional Services• Includes (beside _many_ others) – All security relevant configuration – Missing Patches – Default accounts
  33. 33. Worst Practices• Not restricting GlassFish user nor enabling security manager• Network interfaces/sockets access control• Relaxed File system access control• Using any defaults like: – Passwords: Admin, master password – Network interface binding: Listening on – Certificates: Self signed certificate• Using a not hardened OS!
  34. 34. Policy Files location• Global Policy File: java.home/jre/lib/security/java.policy• User Policy File: user.home/.java.policy• Domain Policy File: domain.home/config/server.policy• Application Policy File: domain.home/generated/policy/<>/ <>/granted.policy
  35. 35. Running GlassFish in aSecure Environment• Use the latest version (• Enable secure admin (TLS/https)• Use password aliasing• Enable security manager and put forth a proper security policy file• Set correct file system permissions
  36. 36. Review the *.policy files• Policy files precedence order• 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!
  37. 37. A7 - Failure to Restrict URL Access
  38. 38. What is it?• Presentation layer access control• Related to A4 – Insecure Direct Object References
  39. 39. 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 misuse the extra permission and access they have
  40. 40. Java EE 6• What you do to prevent, A4 plus: – Use Container security (security-constraint) – Use programmatic 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
  41. 41. Best Practices• Any none 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
  42. 42. A8 - Insecure Cryptographic Storage
  43. 43. What is it?• Sensitive data kept unprotected• Sensitive data exposed to wrong persons• Could be: – Passwords – Financial/Health care data – Credit cards
  44. 44. Worst Practices• Storing sensitive data unencrypted• Storing comparative data unhashed (passwords/security question answer…)• Keeping clear text copies of encrypted data• Not keeping the keys/passwords well guarded
  45. 45. GlassFish• Protect the keystore• Protect GlassFish accounts – Use aliasing to protect the password and keep the master password safe to protect the aliases• Ignoring digest authentication/hashed password storage
  46. 46. 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• To decrypt and view clear text should be restricted to authorized personnel• Keep the keys as protected as possible (HSM)• Keep offsite encrypted backups in addition to on-site copies
  47. 47. A9- Insufficient Transport Layer Protection
  48. 48. What is it?
  49. 49. 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 securely transmitted Cookie.setSecure(true)• Forgetting about the rest of the infrastructure
  50. 50. 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 access log under HTTP Service
  51. 51. 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>
  52. 52. 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
  53. 53. A10 - Unvalidated Redirects and Forwards
  54. 54. What is it?• Redirecting to another URL computed by user provided parameters• Forward to another URL computed by user provided parameters
  55. 55. 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
  56. 56. 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• Forwards happen without authentication and thus requires triple check to prevent unauthorized access.
  57. 57. WRAP-UP
  58. 58. Galleria Wrap Up
  59. 59. Security isn‘t all candy.. … but you will love it in the end!
  60. 60. CC picture reference••••••••••