Really?
Is SQL injection really still a problem? Any half-baked coder knows to use parameterized queries. What's more, their proposed solution sounds ridiculously complex.
One of the most common forms of attack is the SQL injection, and although the vector is ancient and well-understood, it's notoriously difficult to defend against. Kevin Kennedy, senior director of product management for Juniper Networks' security business unit, is in Australia to demonstrate Juniper's latest shot at defeating …
I'm also interested to know if this is still a problem. And on what databases?
The proposed solution does sound complex but I guess it could be turned to different things too, such as an attacker sniffing for scripts that might allow directory traversal.
As the author notes though, this would only keep the skiddies out. Any attacker that knows their stuff will be hopping IP and blocking all cookies of any sort.
If I was still building database applications I would personally still prefer to use some form of stored procedures, with parameter inputs that don't use the names of fields or tables in the database. It really should be obvious to any database application engineer today that the engine of any database system (SQL or otherwise) should never be exposed to the wider world, and the names of any database's objects shouldn't be either.
Yes - and they don't write code with bugs in either. And all code is less than 5 years old. And all code is written by people who care. And all code is written by at least half-baked coder.
It's true that relying on developer competence is a poor way to improve security.
In this specific case, though, it's not terribly difficult to enforce good practice. Restrict permissions on the database accounts used by applications so they can only execute stored procedures, not perform any queries directly. Yes, that will break old code; but it doesn't rely on developer vigilance.
Some college courses (I'm looking at you, Glasgow Uni) were still teaching embedded input SQL as of 2012 with only cursory caution to the students, who are then turfed into the wild and often subsequently find themselves writing their first real code for small start-ups where there is no one else there who knows better.
This can be a recipe for much comedic japery when it comes to database design.
The trouble is that there’s still a lot of code developed by third parties who have yet to get the message.
DreamWeaver generates PHP code that is notoriously convoluted and doesn’t used prepared statements. I’m not sure, but I have the feeling that PHPMyAdmin does things the Old School Way. WordPress seems to be OK, but I don’t know how many other popular CMS packages use them.
Of course, people who rely on off-the-shelf packages are not always best placed to implement a sophisticated defense such as is described. Still, slowing down and misleading attackers is not a bad thing.
Well, I think that programmers can protect against SQL injection, in all cases. With a combination of libraries that escape the data correctly (such libs have existed for years and are rock solid at preventing DB level injection) and proper input validation/sanity checks on all user supplied data. Sure its possible to slip up, but if your developers understand the risks and what not to do they can work inside those parameters.
As for 'super cookies'.. not all live CDs need to have no write access. Theres these things calls virtual machines which can be rolled back to a snapshot.
But I guess these products will still sell, some people cant have enough protection.
With a combination of libraries that escape the data correctly (such libs have existed for years and are rock solid at preventing DB level injection) and proper input validation/sanity checks on all user supplied data.
Fragile and unnecessary. As other contributors have already noted, you're far better off with restricting applications to parameterized operations (stored procedures). Even better, combine that with a proper DAL (data access layer) and/or ORM (object-relational model) - business logic and the UI layer shouldn't know anything about how the data storage works. That should be a black box to them, accessed via a minimum-privilege API. It shouldn't matter if the UI/business layers throw garbage at the data-access layer.
Once attackers have been identified, redirect all traffic from them to a second server, full of good-looking but fake data. The intention is to make them waste time attacking the fake server, and even let them think they've succeeded, while preventing them from accessing the real database.
Rather than watching for something easily changed, like the IP address, the system is now looking for the fingerprint of the super-cookie, and acting accordingly.
Eh? Surely the mere presence of the supercookie and a unique associated ID is sufficient to recognise the machine. IE what's the purpose of the fingerprinting?
Too easy not to get caught out by this problem!!
A simple way around this is check all parameters at the start for banned items like <script and replace them with something harmless. Personally, I replace hacking attempts with the word "cheeseburgers".
Took 30 seconds for global back-end protection from XSS & SQL injection in one project.
As well as validated & parameterised inputs, I have also assigned the login used by the application the public role and assigned its user explicit rights to every stored procedure.
So even if an SQL Injection were to be successful, the attacker can do little more than execute specific SPs, which while not actually a good thing, is better than assigning the application user dbowner rights and allowing the potential dropping of tables and so forth.
Am I wrong in assuming that performing a distributed attack rather than running this from the attackers own machine would get around most of the detection offered by this, if not the actual protection? I know that some idiots use their actual home computers for attacks and that there are non-trivial number of idiots out there, but it seems this is picking low-hanging fruit at most.
It depresses me that IT gets excited over an absurdly complex solution to an embarrassingly simple problem. It's like a fast food manager discovering that his employees aren't washing their hands after the bathroom, and instead of training them on proper procedures, he injects powerful antibacterial chemicals into all the food. Or something.
The problem is caused by connecting two languages (a frontend and a database) to each other using a ridiculous string parsing layer. The entire IT industry has accepted this as OK, why exactly?
"the browser, the installed fonts, timezone, screen resolution, pointer device, camera type and so on – the system can capture a fingerprint of the attacking machine"...
Super-cookies are being abused by non-attackers as well IMHO. I'm trying in vain to get my bank, one of the USA's largest, to stop using Super Cookies. Its the only explanation I have for how their 2-factor authentication challenge question and answer is being continuously cached. I am ensuring all cached sessions / Etags, cookies, flash cookies, temp files are being purged after every login....