Covering J2EE Security and WebLogic Topics

Unconventional Warfare

Let’s get medieval.

Imagine a castle, stout and impenetrable even on this ordinary day. Guards mill about with glistening swords at their sides, anxious to try them out. Bored look-outs peer over the parapets, ever watchful for the approach of a mighty army. Prima donna archers play Uno in the towers.

Meanwhile, real life happens. Peasants and traders enter and exit the castle as part of their daily activities. The scent of steak-on-a-stake and cotton candy fills the air. All is well at our imaginary castle.

Or is it?

While the castle is certainly ready for a conventional enemy that would storm the gates and attempt to smash the walls, it was totally unprepared for what happened that fine day.

The crown jewels were stolen.

The lord of the castle is perplexed. After all, the defenses were ready — every man was at his post and ready to engage in mortal combat with enemy knights. Everyone was on the look-out. And still, the jewels are gone.

This castle scenario is what computer security seems like to me these days. We have DMZs and firewalls, intrusion detection, intrusion prevention, encryption, application resources protected by roles, and if we’re lucky, maybe even strong passwords. But more and more I’m coming to the realization that while we need those things, we as developers really need to bring out our inner guerilla. We have a handle on the conventional warfare but we almost never think like a hacker. They’re going to dress like a peasant and mimic the ways of a peasant. They’re going to be the peasant.

They’re also going to rob you blind.

The problem is, thinking like a hacker is not in our nature. Unfortunately, that needs to change. Because quite simply, unlike the crown jewels that physically disappeared, our electronic crown jewels can be stolen and yet simultaneously remain in our possession. It’s the nature of the ones and zeros.

We even need to be security conscious during non-coding activities such as writing uses cases. The reason is that even seemingly innocuous business functions can provide a covert pathway to the crown jewels.

Consider this blog post. Be sure to read the case study.


Did you notice that conventional security techniques wouldn’t have prevented it?

This realization I had — that we need to think more like hackers to protect ourselves — did not just hit me out of the blue. I’m far too dense for that and wouldn’t have felt it. Instead, it comes from reading the blogs of the white hat hackers. In my case, Jeremiah Grossman and RSnake are the ones that scare me on a daily basis. In fact, the blog post above is the work of RSnake. It’s these guys that repeatedly hit me upside the head to make me see things in a different light. And when they hit me, I definitely feel it.

Today, more and more developers are aware of the perils of SQL injection. That doesn’t mean there’s not a lot of vulnerabilities out there but developer awareness of this particular attack is rising. That’s good. Now we need to learn more about XSS and CSRF and do what we can to avoid them. It’s all too easy to read about these attacks and yet not fully comprehend the danger because the descriptions are often too abstract. But folks like Jeremiah and RSnake make us smarter by showing us exactly what the ramifications are in all of the gory detail.

As developers, we need to be familiar with what these guys are writing about. Black hat hackers probably already know this stuff. So should we.