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 Markus.eisele@msg-systems.com

Java EE 7 EG,

architect, husband, father of two, photographer, speaker, writer

Masoud Kalali http://kalali.me http://twitter.com/MasoudKalali Masoud.Kalali@oracle.com 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/