UN's website still vulnerable after 4 years

More than four years ago, the UN website was hacked via SQL injection. They haven't fixed their problem since then, which I've pointed out over and over and over. This last week, #Anonymous hacked them yet again using the same technique. If, after 4 years, the UN still can't protect their website, it's unlikely that they ever will.

But SQL injection is the easiest of all bugs to fix: simply stop treating data as code (use parameterized queries instead). The difference between the correct way, and the wrong way, is obvious and impossible to miss. Most hacker attacks are hard to understand, and hard to fix, but SQL injection isn't one of those.

So why, after 4 years, has the UN failed to fix the problem? Here are the possible reasons I can think of::

#1. They don't want to fix it; they just don't care if their website is occasionally hacked.
#2. They don't understand the risk of treating data as code.
#3. Their programmers aren't smart enough to fix the problem.

In my experience, it's usually #3: even though this is by far the most obvious and easiest problem to solve, most web programmers still aren't smart enough to fix it. Web site developers treat code as magic spells: they know which incantations work, but they don't understand how they work.

This leads to problem #1: organizations find it easier dealing with getting hacked rather than fixing the underlying problem. This is especially true of an organization like the UN, whose managers are even less smart than their programmers, and who don't have the ability to fire incompetent programmers.

This further leads problem #2: because it's so hard getting your programmers to fix the problem, group-think leads to a state-of-denial, where the entire organization convinces themselves either that there is no risk, or that nobody can fix the problem.

So, next year, I'm going to write another blogpost entitled "UN's website still vulnerability after 5 years", still vulnerable to the easiest security problem on the Internet.

---

Update: By the way, I'm not insisting that they should fix the problem. Their site doesn't appear to have anything sensitive on it, so getting hacked is a small problem. Although, I suspect, if their programmers were more competent and able to fix it, that they would then want to fix it. Or, said another way, competent programmers would never allow SQL injection in the first place.

Update: If you are writing a large project in C/C++, it's very hard to verify that it has no "buffer-overflow" problem. But, if you are writing ASP+SQL code, it's trivially easy to verify that you have no "SQL injection" problems in the code. SQL injection really is the most obvious and easiest cybersec problem to solve.