Øredev is just a couple of days away, and I was invited to give two presentations. One of them is about my favorite topic: Security and Java EE. It is designed to fulfill two goals. On the one side to introduce the typical Java EE developer to the overall application security process and main objectives. But also to look at the details about what Java EE has to offer when it comes to typical requirements. Those are two different things and the first has been addressed before in my presentation about “Developer Security Awareness“. This talk is meant to do a match between today’s security requirements and the features available in the platform as of the Java EE 7 release.
Securing Applications Isn’t Just About Secure Code
All the common attacks we’ve known about for a very long time are still out there, and people still regularly make mistakes regarding them. If you want to write secure Java EE code and use the technology securely, you’re on the right track. But there is a lot more to learn and know about securing your applications. There are also people and processes and how they best work together to build a suitable secure system. Derived from practice for use with everyday development such a system can make the Java EE space a little more secure.
Application Security Needs A Holistic Approach
To build a secure Java EE application, a holistic approach to application security is required and security must be applied at all layers and services. Even if everything else beside our own applications typically does not bother developers at all it becomes more important. Last but not least with the advent of DevOps. So, it doesn’t hurt to be at least aware of everything that is going on around us. Let’s start with the layer the farthest away. Secure applications rely on secure networks first of all. This includes everything from routeres, switches, firewalls or even application level firewalls. They need to be patched and correctly configured. Watch out for standard ports and passwords for admin consoles. Next is the operating system layer. Every part of your applications runs on a separate host eventually (Applicationserver, Database, Message Brokers), so you will have to watch out for latest patches and updates for all of them. But shared filesystems and possibly risky daemon processes are also something to watch out for. When you’re done with that it is time to look at the platform services. This is where the JDK base-install fits in but also the application-server. Check policy files and default passwords for remote connections and web-based admin consoles.
From Here On, Application Security Starts
When the infrastructure is taken care of, we can look into application security. And it is typically divided up into six components: Authentication, Authorization, Auditing, Confidentiality, Integrity, Availability. All those components prevent your system from being exploited. A threat is a potential event that may affect your system. An attack exploits a vulnerability in your system. And ultimately this is what we want to prevent. Always adhere to the best practices for designing secure applications:
- Compartmentalize
- Use least privilege
- Apply defense in depth
- Do not trust user input
- heck at the gate
- Fail securely
- Secure the weakest link
- Create secure defaults
- Reduce your attack surface
Get Started With Java EE Security
Watch the full talk on Vimeo to learn what Java EE has to offer around application security. And make sure to provide feedback in the comments and let me know, if there is anything else, you’d like me to talk about in the future.
Further Reading
- JBoss Keycloak
- JSR 375: Java EE Security API
- Overview Of Java EE 7 Security
- Learn what the new Java EE 8 security API means for developers
| Reference: | Theft-Proof Java EE – Securing Your Java EE Enterprise Applications from our JCG partner Markus Eisele at the Enterprise Software Development with Java blog. |
