Slashdot Mirror
Kaminsky Offers Injection Antidote
ancientribe passes along this excerpt from DarkReading.com: "Life's too short to defend broken code. That's the reason renowned researcher Dan Kaminsky says he came up with a brand-new way to prevent pervasive SQL injection, cross-site scripting, and other injection-type flaws in software — a framework that lets developers continue to write code the way they always have, but with a tool that helps prevent them from inadvertently leaving these flaws in their apps. The tool, which he released today for input from the development and security community, basically takes the security responsibility off the shoulders of developers. Putting the onus on them hasn't worked well thus far, he says. Kaminsky's new tool is part of his new startup, Recursive Ventures."
As soon as I hit "deliverable" in the first paragraph, warning bells went off. When "productize" appeared as a verb in the second paragraph, I closed the browser window. Sorry, but my experience tells me that the article is simply not worth reading.
Shutting down free speech with violence isn't fighting fascism. It IS fascism!
Parameterized SQL, or prepared statements, completely prevent SQL injection attacks. They might also speed things up in some circumstances. Why not simply use them exclusively?
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
This sounds an awful lot like a special version of mysql_real_escape_string() with extra buzzwords.
# cat
Damn, my RAM is full of llamas.
the essence is this:
Which means he enforces a convention on developers that aims to improve code security. Sounds smart.
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
Great, let's keep offering a crutch to crappy programmers instead of letting them be shamed out of the industry when they cock up something that nowadays is quite well understood.
It doesn't say anything about how this actually works and how it differs from existing solutions. And, hey, most developers aware of SQL injection / XSS etc already protect their apps. Rails has got both, PHP frameworks have, Java had it since like for ever (2001?). What's the point of this article?
Seems to me that this is just perl's taint mode, implemented in a less elegant fashion (one that relies on variable name prefixes, ugh).
From perldoc perlsec:
You may not use data derived from outside your program to affect
something else outside your program--at least, not by accident. All
command line arguments, environment variables, locale information (see
perllocale), results of certain system calls ("readdir()",
"readlink()" [snip - "and other stuff" ] and all file input are marked as "tainted".
Tainted data may not be used directly or indirectly in any command that
invokes a sub-shell, nor in any command that modifies files,
directories, or processes, with the following exceptions:
http://www.webreference.com/programming/perl/taint/
In short, it's not that interesting, although if people pick it up and actually use it, it could do some good.
Nullset to connectionate with grammarifical authoritarists.
They don't leverise things paradigmatically and resemblancing noncontent either. It's "marketroids' job to functionate that.
Kindly demisise in a combustational situation with maxised immidiateness.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
You seem to wander off-point a lot but the basic gist is that everyone should know how a computer works. Hell, *I* don't even know how a computer works, not really... I can spool off books on the technology, structure, electronics, bus interfaces, caching, logic, programming and the like and still not understand why a missing semi-colon caused quite so much trouble. Or how they layer silicon on the chips. Or why probe a certain I/O port hangs the computer.
And the way to counter that is NOT to expect the average joe on the streets to understand deep-level programming and computing. That's pointless, because they will never get it, and what they do get will never be accurate (read the recent article on Knuth's algorithms only working as advertised on a theoretical machine).
It's the same in *ALL* sciences (and anyone that doesn't classify computer science and mathematical sciences as "science" doesn't even begin to understand science), and we can't teach everyone everything. There hasn't been a single person in the world who knew "all of known science" since the ancient Greeks and there hasn't been anyone who knows everything about their own particular area for centuries, most probably.
We already are completely reliant on computers or robots. If you don't think that, then you're crazy. The problem is that we *can't* rely on the programmers and system engineers that put them together. My computer is currently executing billions of logical operations perfectly and flawlessly every single second. It's timing itself to balance these instructions across two major silicon chips (and dozens of minor chips) that were the mainframe-designer's dream of only 10-15 years ago, without fault, on the order of picoseconds - while those chips are shutting themselves down, speeding themselves up and consuming mere watts of electricity. It's integrating with millions of disparate electronic systems and detecting quantum-level errors in itself and correcting them. If there's a problem, I would know about it almost instantaneously (with certain checks on RAM / filesystem use). This computer, and all the ones I work with, has been doing that for several years 24/7 without failure... even through blackouts, brownouts and power-faults. Hell, it's a perfect operating device, like the one that controls my airbag in my car, the ABS, my bank accounts, every control system on a modern aeroplane, the satellite that gives me television / radio, the Internet, etc. They are all operating virtually flawlessly even across BILLIONS of such devices every day, all day. In terms of engineering that's phenomenal. They do *exactly* as they are told, perfectly, for years on end. Hardware faults are so rare as to be a cause for widespread panic in the IT departments when they happen.
Trouble is, some pillock put Linux or Windows or MacOS or VxWorks on them, or confused feet and metres, or thought 2-digit-years would always be enough. The fault with computers almost ALWAYS lies with the programmer, not the devices. Most of those problems are so damn subtle you could spend years analysing them and still not work out what happened. Hell, we've had computer chips "designed" by genetic algorithms which perform a specified task better, quicker and cheaper than any chip we've ever designed to do it - and although we know "how" it does it, we still don't understand exactly how it works or how to use that knowledge to our advantage (the anecdote I remember is one about a chip that could distinguish two different frequencies of electrical input - someone threw a GA at the problem and the chip design that resulted was smaller and lower-powered than any human design at the time to perform that task). We can understand the hardware, that's faultless (overall) but the software *always* lets us down and no amount of intent study and education can stop that. Hell, it's almost impossible to write more than a few thousand lines of C (which could execute in less than a few hundred CPU cycles even on the slowest of embedded processors
I can't even think of writing code without checks for every condition imaginable simply because when I started coding, I was learning among peers whose favorite thing to do was poke holes in your code in some way or another. I guess that's known today as "peer review" but it was more like peer pressure review when I was in school. The last thing I wanted was to have embarrassing or code that may be ridiculed. And I think that's what TRULY missing in today's development environments -- shame and ridicule.
At DEC we had a formal process known as “code review”. A bunch of us got copies of some code to review. We then all met together and went over the code line-by-line describing the flaws that we found. There was also statistics gathering and reporting, but the greatest value of the process was to the coder, who got feedback on his code. I had thought it would be hard to avoid getting upset at what were perceived as personal attacks (“that's my baby you're criticizing”) but, at least in the code reviews that I was involved in, that never happened. The whole thing was handled very professionally.
99.9% of the time if you cannot parameterized a query, you're doing wrong.
In that case, all the 0.1% of the queries appeared to fall on me. Try using operator IN with parameters, and then see why it doesn't always work.
There's nothing stopping you from building a dynamic SQL string with parameters
That doesn't work if the parameter interface in your database's client API expects there to be a constant number of parameters in each statement. For example, how does one pass a variable number of parameters to mysqli_stmt_bind_param() in PHP?
I ended up doing something like (mind this is T-SQL *like* code):
CREATE PROC QueryWithParams
@a1 varchar(100),
@a2 varchar(100),
@a3 bigint,
@a4 bit,
@a5 varchar(50)
AS
BEGIN
SELECT field1, field2, field3, field4
FROM tables
WHERE
(@a1 IS NULL or fieldtest1 = @a1) AND
(@a2 IS NULL or fieldtest2 = @a2) AND
(@a3 IS NULL or fieldtest3 = @a3) AND
(@a4 IS NULL or fieldtest4 = @a4) AND
(@a5 IS NULL or fieldtest5 = @a5)
END
Not as elegant and just building the query you want, but is almost always safe and "pre-compiled" by the query engine. Also, I can control which fields are going to be filtered.