Handy Java Service Security Checklist

This is a checklist for securing a Java webservice. The methodology being used helps you to appreciate various threat vectors and common oversights.

Taken from my notes and supplemented with other things I've picked up along with way. Your mileage may vary!

The Basics

Java is only as good as the system that hosts it, so it goes without saying that the following areas should be checked.

• OS patches / hotfixes: whether it's a Nix server or Windows. Having the latest security patches for the OS and JRE is a must
• Java version: if you are using a version lower than Java 8 at this time of writing, you're gonna have a bad time.
• File system: if the application is deployed to a shared mount or deployed to a directory with multiple users. Make sure they can't modify the application class files and inject nasty code.

The User

When running webservices on a host machine a dedicated user profile should be created (don't be lazy and use root!). If you are running on a container, then most of these things should be covered by the hypervisor and can be skipped.

• Permissions: does the user running the java webservice have the correct amount of permissions (RWX) to run the service without being impaired.
• Folders / snooping: can this user snoop on other areas it shouldn't be in and make changes e.g. can the user read the log files of other apps in /var/log
• Is the user in a user group? Having the user in a group makes security management easier in the long run.

Network

Developing a web service with Java, the chances are its going to be publicly exposed.

• OWASP: have you tested your API endpoint or site with OWASP tools?
• Ports: "Any port in a storm?", thats what a hacker thinks when they see your server. Make sure the host machine doesn't have any non essential ports open to the public, use NMAP to scan for anything that shouldn't be open.
• DDOS protection? Is the service protected from a denial of service attack? Maybe utilising a tool or service from Cloudflare or AWS.
• Access Control Lists / security groups: they are a bit old school but still useful. To restrict access by IPs / subnets etc.
• Java admin / monitoring ports open?
• SSL stupid!

Application Layer

Bad code, not me, never.

• SQL injection: only you can stop forest fires Bobby Tables
• Java security: does the application make use of security concepts like Principles, Cryptography / Keys etc.?
• Authentication: for the API consumer, is authentication required (most of the time, the answer should be yes)
• Principles: I mentioned it again, yes these things are useful for defining User's inside the application. They can control user behaviour e.g. prevent a basic user from accessing admin resources.
• Sessions: whether its a basic cookie or a nice JWT token.

Other

• Are you running in production mode? The amount of times i've seen Spring services printing out exceptions to the browser on sites, is scary!
• Are there any testing harnesses / API docs publicly accessible? Having an API tool like Swagger or some markdown docs available to an attacker is like giving them the keys to your Ferrari, or Prius!

That's it, happy Java'ing!