Future Defence of the Realm
When the sirens sound will we be issued with screenshots to wave at the enemy?
The Ministry of Defence is battling a wave of copycat attacks after a hacker took down the Royal Navy's public website this week. Simon Kershaw, head of defence security and assurance services, said IT staff have been monitoring many more attempts to penetrate military sites than usual since the hack, which emerged on Monday …
Isn't this a simple question of not allowing special characters to be used / entered into a search / query box ? It would seem common sense to screen for non-alpha-numeric characters such as < / > $ etc. etc if you're end-user is only going to look for real words / names.
In which case every web designer involved with such work should a) not allow the use of such characters by default and b) test the bloomin thing thoroughly before handing it over to the client.
Is it that simple ? I could be wrong, but thought I would ask.
Somewhere a stupido coded something like
string s("select <bla> from tableXY where colZ = ");
Now if someone enters "5;update credentials set password=''", the SQL engine will also execute the update command:
select <bla> from tableXY where colZ = 5;update credentials set password=''
The solution is to call methods like XXX_sql_escape(), which will know the special characters of the DB engine and properly escape them. This kind of exploit has been known for many years now. The Navy is clearly incompetent here.
Basically, all input should be checked for the correct character set/syntax. Regular expressions might help. And then run it through the escaping method just to make sure.
There could be many more subtle exploits possible if some input fields have a very special syntax.
Security is not simple, but this exploit type has been known for a very long time.
just allow a-z,A-Z,0-9 and strip anything else. It will make attacks 'a little bit' harder.
For passwords, hash them as soon as you receive them and before doing any further processing.
N.B. Unless someone proves me wrong (and I'd be really grateful to person who does for enlightening me), I'd say this makes these fields invulnerable to SQL injection.
"Isn't this a simple question of not allowing special characters to be used / entered into a search / query box ?"
That will only stop users from causing unintended SQL problems (i.e. using an apostrophe).
Someone attacking with intent will bypass the client-side UI entirely and send HTTP POST commands direct to the server which is where the server-side protections the other commenters have said come in.
Any sensitive data open to queries from the public internet should not be subject to user-crafted SQL strings. If that's the way it's got to be then the data tables for public access should exist on an isolated server as a quarantined image of the actual data. Any corruption caused by malicious attempts at data modification or deletion will affect only the ‘public’ version. Changes to the public areas can easily be detected and dealt with. This approach also allows for data sanitisation before publication.
The site might as well carry a caveat with something like ‘Please don’t change our data because if you do and we find out well feel a bit miffed.’
Nope. In my vast years of experience as a Reg consumer, I can say quite definitively that when stories of SQL injection appear on The Register, Operating System and Web Server are almost always either not mentioned or added in a by-the-way fashion.
If there's one thing the hacks here seem to get, it's that SQL injection exploits application and database software weaknesses, not OS and Web server weaknesses.
In general, the press falls into two major categories with respect to SQL Injection reporting:
1. Technical enough to know it's not the OS/Web Server, and so not mentioning it
2. General enough to not even know it's SQL Injection, and hence not technical enough to even research what OS/Web software the target was running
Exceptions exist, I expect, as each event is unique and original.
How is it *possible* to get a job writing the code to maintain these pages yet not *know* that bad stuff happens if you let any viewer type *anything* into a query box plumbed straight into the supporting database?
And BTW don't automated tools exist to scan for this sort of dumbness?
.... for AIDominion and Leading Remote IT Control?
"Nevertheless, the hack was embarrassing for the government, coming less than three weeks after it announced £650m in new funding for cyber security. The four-year budget is meant to strengthen its networks against threats from more serious adversaries than a solo "grey hat", including foreign intelligence agencies and organised criminals."
And with £650m available for cyber security programming pros, there are also those solo rogue home intelligence processing units, .......[and the prodigious virtual virtuoso machine is the one to watch out for, and nab before the price you have to pay to engage their interest and talents are too great to be ignored and swept under the carpet/lost in creative accounting] ...... into red team penetrations betatesting of novel vulnerabilities and systemic flaws in government and treasury defences, which exploit lucrative business and black market opportunities of interest to foreign intelligence agencies and organised criminals too, must also be an abiding worry, especially whenever the adversary/competition/programming can not only weaken networks, but also easily decimate them, with their blissfully unaware capture which strips them bare of all secrets.
Although you may have to realise that for such operands is £650m as just chicken feed in a market place which can deliver trillions .... effortlessly.
and click into the fat image. You get this:
I disagree that this does not matter. Proper Defence is always Deterrance and that is by definition a psychological concept. The Royal Muppets look really weak and it will cost some of their lives because other players will assume they are weak. Irrespective of the fact that they are probably able to do something really nasty.
Biting the hand that feeds IT © 1998–2019