10 tips to power-up your Java security

“Security”, this word has been said so much in the past few years,
Nowadays it seems like even the smallest company must take this aspect into account.
FYI, security tools, both attack, and defensive ones, get improved by companies, groups, and individuals, so it’s really necessary to understand that there is an entire industry who’s search for security vulnerabilities every day and no matter on what side you are, this game is far from ending.

According to Oracle, there are 9,000,000 java developers across the globe (BTW, Wikipedia claims it’s 10,000,000 🤔).
So I thought it would be a good place to start writing such tips.


My personal note (a disclaimer if you wish)

I must say that for me, security considerations were always a way of thinking, I’ve got the idea and it’s importance when I was a young developer. I ran a research across the web on a weekly base, checked many open-source tools and talked about those issues with some of my best developers/hackers friends. 
Today, as a mature developer, I must say that the game between those two worlds (attackers and defenders) haven’t changed a lot.
Conceptually, it’s nice to think about security issues like the Tom&Jerry carton TV show, they may get smarter from time to time, but the concept remains the same.


Simple but still effective tips

Please, DO NOT count on the following tips to fully protect your project.
Come with an open mind so it may make you think more securely. 
Of course, feel free to change, extend or create new follow-up rules.


Vulnerability 1: SQL injection (just one solution out of many)
  • The input values included in SQL queries need to be passed in safely. Bind variables in prepared statements can be used to easily mitigate the risk of SQL injection.

Solution:

  • Use prepareStatement() function, in order to validate your inputs before execute queries on the DB.
Vulnerability 2: Return mutable objects
  • Doing so leaves you vulnerable to unexpected changes in your class state.

Solution:

  • use an unmodifiable/immutable collection or make a copy of the mutable object, and store or return the copy instead.
Vulnerability 3: Include XSS characters into log messages
  • When data from an untrusted source is put into a logger and not neutralized correctly, an attacker could forge log entries or include malicious content. Inserted false entries could be used to skew statistics, distract the administrator or even to implicate another party in the commission of a malicious act.
  • If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. An attacker may also inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility (e.g. command injection or XSS).

Solution:

  • Manually sanitise each parameter.
  • Configure your logger service to replace such chars for all message events.
Vulnerability 4: file inclusion (reads/writes a file whose location might be specified by user input)
  • The filename comes from an input parameter. If an unfiltered parameter is passed to this file API, files from an arbitrary filesystem location could be read/write.

Solution:

  • Always validate user’s input, but a specially when dealing with files.
Vulnerability 5: Unencrypted server socket
  • Traffic could be read by an attacker intercepting the network traffic.

Solution:

  • Use SSL server socket.
Vulnerability 6: MD5 is not a recommended cryptographic hash function
  • The algorithms MD2, MD4 and MD5 are not a recommended MessageDigest.

Solution:

  • Use secured encryption algorithms like PBKDF2 or others.
Vulnerability 7: java.util.Random is predictable
  • The use of a predictable random value, base on clock’s tickets or any other predictable params, can lead to vulnerabilities when used in certain security critical contexts. For example, when the value is used as: a CSRF token a password reset token (sent by email) or any other secret value.

Solution:

  • Use secure random class & functions.
Vulnerability 8: Throwable.printStackTrace(…) should not be called
  • Throwable.printStackTrace(…) prints a Throwable and its stack trace to some stream. By default that stream System.Err, which could inadvertently expose sensitive information.

Solution:

  • Use Loggers and custom your log messages to be specific and isolated.
Vulnerability 9: Remove use of dynamic class loading
  • Dynamically loaded classes could contain malicious code executed by a static class initializer.

Solution:

  • Just don’t do so :)
Vulnerability 10: Command injections
  • If unfiltered input is passed to an API, it can lead to arbitrary command execution.

Solution:

  • Just don’t do so :)

🤓 That’s it! 🤓

Thank you for reading.
I hope some of the tips cause you scratch your head and think about security more seriously.

If you like this article, you’re welcome to leave a comment and view my page on Medium or LinkedIn.