Is it just me
or IS everyone waiting for Facebook to experience one of these losses.
A federal judge has declined to dismiss a lawsuit filed against social-media application developer RockYou for exposing the personally identifiable information of 32 million of its users, which the site stored unencrypted when it suffered a major security breach 16 months ago. Judge Phyllis Hamilton of the US District Court in …
These SQL injection vulns crop-up with monotonous regularity, and it's hardly any surprise that they do. The fact of the matter is that EVEN if you understand the nature of the risks (and some aspects are far from easy to understand!) it is virtually impossible to be certain that none exist in a large block of webpage code.
IMHO there is little point in punishing those who made the mistake leading to the vuln. Instead, it's time the base system was modified to eliminate this weakness.
Meanwhile, if the courts want to do something productive in terms of improving Web security, they would be better to go after sites and software which leak bulk quantities of users' email addresses to spammers, not by mistake but through deliberate negligence. There are after all enough of those to keep 'em in legal fees for a while.
sql injection is very very easy to avoid - simply move to a real database that allows bind variables and avoid POS db drivers that do not properly use BV's.
Today PHP can bind values so why do web coders insist on hand quoting values and building the SQL queries with embedded values?
In any decent database you get optimisations when binding values as the same query is submitted to the database independant of values - this means the same QEP can be re-used so speeding up evaluation of results.
Jacqui
From what I've read, binding of values doesn't guarantee escaping of all possible commands within those values.
In any event this is an attempt to solve a problem of unwanted and dangerous functionality by adding even more labyrinthine complexity. Not good, because there are guaranteed to be hidden, unexpected gotchas in such an approach.
The issue here cannot be properly resolved by any kind of coding tricks. It is that any system which allows commands to be embedded inside user-responses is fundamentally unsuitable for Web response-form use. Exactly what part of that is difficult to grasp?
Essence of situation:
Q: How many bags of potatoes do you want?
A: "3 AND launch missile in silo #37"
SQL: 3 supplied, and I obey. Boom.