Tales From The World Of Java Development And Security

dev

One thing that’s very surprising about PKI infrastructure is the fact that a lot of the mechanisms put in place don’t work, or don’t work as they should. Often this is driven by sheer necessity, and the need to keep the internet working no matter what. One example of this is certificate revocation. If you are setting up a domain and requesting a new certificate, you would assume that once issued the certificate can be revoked in the case of a security breach.

But you’d be wrong. Even when you revoke the certificate attackers can still use it to enable MIIM attacks. Read on to see why….

In my previous post, I detail how REST allows us to utilise the HTTP’s native caching functionality without the need for additional technologies or knowledge. However, this whole ‘using what we know about HTTP already’ philosophy goes much deeper than that.

Consider one of the biggest problems with API design and maintenance: getting your clients to use the API correctly, especially when it’s changing or is constant development. This might be easy if you are integrating with one team that sits next to you (and even then misunderstandings can arise), but what if you have multiple clients across the organisation, or if you API is public? Read on if you want to see how REST can help….

A security expert once said to me, “It’s the fastest teams and the fastest systems that get used for new features, not the most appropriate, and this causes security breaches”. I never understood what he meant, until I saw it with my own eyes.

Java is strange, in that it makes a distinction between runtime exceptions (which don’t need to be declared, and can bubble all the way up to the top of the stack), and checked exceptions, which need to be either wrapped in a “try-catch” block, or declared in the method signature so that the calling method will have to deal with them.

This is one of the fundamental aspects of Java synchronisation, but I have seen so many people get it wrong when I’m interviewing them. It’s very simple, but slightly contrary to how you might think synchronisation works.

In the event of a breach or an infringement of your companies responsibilities, timely and appropriate escalation is required.

During one breach I witnessed at a company I used to work for, inappropriate and untimely escalation made the situation a lot worse; the dev team and their managers failed to escalate a serious issue (users credentials being logged in a log file) quickly and appropriately, and as result the situation escalated.

access to files is often logged. In the case of a breach, the lower the number of people who accessed the compromised resources the smaller the aftermath (e.g in the case of sensitive data being logged to a file, it’s easier to deal with five people who accessed the compromised file, than thirty). Reducing initial propagation helps this.

Revealing the server/component type and version in their error response -this allows the attacker to search for known vulnerabilities against that version number.

Logging full stack traces, or worse showing them in the error response -again, this tells the attacker what libraries the system uses, and if any of those libraries have known vulnerabilities, the attacker can exploit this.

Just because your client is internal and not ‘user facing’ don’t assume that your error responses won’t filter through to the outside -in a highly distributed system, you never know where your response will end up.

Same goes for logging; you don’t know who will end up reading your error logs.

Basic Action Points For A Team:

Never log full stack traces, unless absolutely necessary.

Confirm that non of your responses contain information about the server products you use or their versions.