Some great writing on Java Security issues

I happened across Will Sargent's blog the other day, and it is a wonderful source of information.

In particular, 5 recent articles really should be on your short-term "I need to learn more about Java Security" reading list:

• Effective Cryptography in the JVM

  Keyczar is the only pure Java high level cryptography library out there. Keyczar’s been reviewed and found good, and the algorithms are solid. However, it hasn’t fundamentally changed since 2008.

• Closing the Open Door of Java Object Serialization

  Java Serialization is insecure, and is deeply intertwingled into Java monitoring (JMX) and remoting (RMI). The assumption was that placing JMX/RMI servers behind a firewall was sufficient protection, but attackers use a technique known as pivoting or island hopping to compromise a host and send attacks through an established and trusted channel. SSL/TLS is not a protection against pivoting.

  This means that if a compromised host can send a serialized object to your JVM, your JVM could also be compromised, or at least suffer a denial of service attack. And because serialization is so intertwingled with Java, you may be using serialization without realizing it, in an underlying library that you cannot modify.

• The Right Way to Use SecureRandom

  How do you generate a secure random number in JDK 1.8? It depends.

• An Easy Way to Secure Java Applications

  One of the things that stands out in the Java Serialization exploit is that once a server side Java application is compromised, the next step is to gain shell access on the host machine. This is known as a Remote Code Execution, or RCE for short.

  The interesting thing is that Java has had a way to restrict execution and prevent RCE almost since Java 1.1: the SecurityManager. With the SecurityManager enabled, Java code operates inside a far more secure sandbox that prevents RCE.

• Self-Protecting Sandbox Using SecurityManager

  Most sandbox mechanisms involving Java’s SecurityManager do not contain mechanisms to prevent the SecurityManager itself from being disabled, and are therefore “defenseless” against malicious code. Use a SecurityManager and a security policy as a system property on startup to cover the entire JVM, or use an “orthodox” sandbox as described below.

None of these articles are easy reading: they are dense and detailed, and astonishingly replete with links to yet more information.

But they are very interesting, and very informative, and you shouldn't call yourself a Java systems programmer without being extremely conversant with the topics mentioned here.

I'll definitely be keeping an eye on Sargent's blog from now on.