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!
Begone, vile shill!
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
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.
I doubt it's much more than a 'recursive' injection success check with some debugger functionality.
Probably too early to "productize" this "deliverable", I'd bet.
Apparently all you have to do is include "Kaminsky" in the summary to get a Slashdot article to the front page. This post has zero real content and TFA uses the word "productize", for science's sake. Looks like Kaminsky has become the nearest thing to a rock star that the security industry has.. which is too bad, because he's sort of a douche bag in real life.
might like what formal verification guru Adam Chlipala (http://adam.chlipala.net/) has been doing: http://impredicative.com/ur/
This is a very cool special purpose language that generates fast native code for web pages, and statically guarantees
the absence of injection and xsrf attacks, and also of broken links and other sorts of errors that plague lots of web sites.
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.
There is a slideshow at http://www.scribd.com/doc/33001026/Interpolique on the product. At this time having problems accessing it, so have not read the full thing.
What the product does is go through your code and change in-line SQL to code like this
select * from table where fname=b64d("VEhJUyBJUyBUSEUgU1RPUlkg QUxMIEFCT1VUIEhPVyBNWSBMSUZFIEdPV CBUVVJORUQgVVBTSURFIERPV04=")
Then when called in the database you get inject safe code.
how is it ground breaking ?
dude, it's a renowned researcher, and he's got a shovel.
/greger
More excuses for hiring developers who can produce bad code by metric ton without understanding what it actually is what they are doing. And that they don't even need to understand. Sigh... It waould be better to ban your developers off SQL and into an abstraction layer that puts the queries together behind the scenes and hire a competent developer to develop that.
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.
Linky linky?
Karma: Excellent (My Karma? I wish...:-( )
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?
I'm guessing you've never met Dan before...Shame you're attempting to condemn a very well-respected member of the IT community for a grammar error that was likely intentional to an extent...Oh well, your loss.
Kaminsky is a fool. He says we try to teach, escape or parameterize, developers try, but fail, then says the solution is to teach these fools to use my untested alpha software, because, we couldn't teach them to do it right . Great logic Laminsky, teach those willfull fools, that'll teach them
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.
It is not possible to solve security problems only with passive measures.
The role of the Internet in business and in social life is increasing and will continue to increase. The next step of this revolution is robotics. It will overshadow everything we saw until now.
Schools and universities, which train police officers, judges, correction institution officers, should start to include programming and robotics courses into curriculum.
When everything is done via net and by robots, there is no use of police officers and judges, who can not even understand what a culprit has committed in a technical terms, how malicious was an intent.
When these public servants and society in general understand the mechanics of this crime, it will be able to start to work to eliminate it.
But if we stop only SQl injection attacks, the criminal minds will find some other way to harm servers. It is an illusion that security can be achieved only by technical means.
I would argue that a wide condemnation by the society and its defense institutions is needed. But if society continues to rely on the network, on computers, on robots more and more without understanding underlying technologies deeply, without ability to understand what is going on inside the system, it would be a recipe for a disaster.
you're obviously an idiot or a troll, so no example needed buchner.johannes'); DELETE FROM TABLE comments WHERE uid='1139593'; DELETE FROM TABLE users WHERE uid='1139593';-- http://bobby-tables.com/
Too many times have I said this. There is no silver bullet.
Security is not an option, it's inherent in the system or not all.
Nothing fixes bad code. Nothing can. Now there are things you can do to prevent writing bad code, like scream when your code goes and screws up stuff. You can automate the things you might do wrong, use a garbage collector, use prepared statements, use a filter to check for input. And it's hard work, but that's why you get paid. Now management can help you too (my boss gives me work that "needs to be done right, first time") by ensuring they don't make you cut corners. Most of us want to do the best job we can, but we're not allowed to - "Just Ship it and put a patch next month", because security is not really a feature that sells, it's assumed to be present and cannot be monetized properly. Bruce Schenier explained it brilliantly in - Market for Lemons.
But there's no silver bullet, in fact there's not even a silver band-aid. And sometimes the bug is in the shield itself. My usual policy is to have as little code as possible, so that I can read and verify it all the time. Smaller the chunks I build, the easier it is to test it apart. Easier it is to tear it apart, to replace a part or just anything. Code in ADA will be more auditable than code in PHP (trust me, I work with php all day). But eventually, you can't really write bad code, push it production and slap security over it.
So tell me, how will you fix this bug that was there in your security tool, Recursive Ventures? :)
Quidquid latine dictum sit, altum videtur
Don't see how he was marked as troll. It is not ground breaking at all.
Comment removed based on user account deletion
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.
When i read quickly the headline, I saw kaspersky and injection, and thought, they have developed a new way to inject dlls running on windows in case they have been compromised, a new type of anti virus, if the dll is hacked, then hack it back...
Then i stopped and realised that the article had nothing to do with the AV company, and had this guy kaminsky talking about how to circumvent sql injection attacks...sort of...then i tried to go read the article, and got the blocked login page, which I have no log in for...and wont create one to just read a story...all said and done, i am not even sure if this has merit...can anyone post a link to
a NON secured website where i could view the story as is...?
It sounds like he offers a way to go through code quickly to replace badly written code...but i could be wrong...
...when you didn't need to spend your time in Slashdot dodging advertisements disguised as news.
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?
in Easternorwestistan, besides the fashion cycle is about to repeat
you can certainly parameterize like
SELECT * FROM blah WHERE [mybooleanfield]=@userinput
but sometimes i want the field i am checking to be variable
for example, say i have a dozen boolean fields, and i want to filter the result set based on the user choosing which boolean field to filter on
so i want SELECT * FROM blah WHERE @userinput=True
can't do that ;-(
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
assuming scrubbed user input, how would one parameterize a field name? or rather, if this is not possible, what is the ingenious method i am not aware of for satisfying this common use case?
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
PA-DSS (a PCI standard) requires code review by someone other than the original author, who has training in secure coding practices.
I have a system which extends its schema at runtime, introducing new tables for user-defined metadata. I name the new tables after their concepts, and keep a table of all the valid user-defined concept names. At access time, I first make sure the concept is in the defined concepts table, then I have to fake my own parametric queries doing the equivalent of this sort of bashy psuedo codet:
# make a select statement for userconcept and uservalue
query="SELECT * FROM \"_"$(sed -e 's/\"/\"\"/g' "$userconcept")"\" WHERE value = \$value"
# run the query
value="$uservalue" doquery "$query"
In other words, I can use the database query layer's parametric form to pass the value via an environment (or a dictionary structure in the database wrapper I actually use). But I have to do my own basic wrapping of user-defined strings into derived table names, quoting any " character and using the SQL syntax for quoted identifiers so I can have any character I want in the table position. Also, it is important that I checked the userconcept value in my own purpose built table before inserting it into a query like this... I wouldn't allow just any string to be inserted. Finally, it is important that I add some prefix systematically to all such derived table names and follow some namespace hygiene for my table naming.
Recursive Ventures indeed...
that's clever
however that's not exactly the use case
so perhaps a mod:
CREATE PROC QueryWithParams
@a varchar(10)
AS
BEGIN
SELECT field1, field2, field3, field4
FROM tables
WHERE
(@a="field1" AND field1 = True) OR
(@a="field2" AND field2 = True) OR
(@a="field3" AND field3 = True) OR
(@a="field4" AND field4 = True)
END
that's the use case i'm talking about. however, its clumsy. if you have 50 fields, you have a monstrosity
the problem being there is no simple way to say
WHERE @a=True
the idea being: the parameter is the name of the field you want tested
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
that's my solution too, unfortunately. its not as fast as a parameterized query
what would be elegant though is if they allowed us to parameterize the names of fields
so we can do
WHERE field=@var
but it would be awesome to do
WHERE @var=True
that's my wish
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
We use PostgreSQL. We expose the libpq not default port directly to the internet through pgbouncer. What we did:
*) Modify pgbouncer to only except extended protocol (parameterized) queries
*) Auto Generate list of allowed queries used by app to store in whitelist
*) Block all functions except auth if authenticated or to the whitelist othewise
have had zero problems. curious what you think.
i know I am replying to myself... but I don't really see why I was marked as offtopic for saying the summary is wrong by saying this is a brand new way to prevent SQL injections... many existing frameworks have offered SQL injection filters/remedies... as well as rogue javascript protection through many ways including parametrized queries.someone must have woken up on the wrong side of bed this morning :).
Never antropomorphize computers, they do not like that
"or thought 2-digit-years would always be enough. The fault with computers almost ALWAYS lies with the programmer, not the devices." - by ledow (319597) on Tuesday June 15, @08:20AM (#32576474) Homepage
Untrue on THIS account, why? Well, since I am probably a relative "oldster" on these forums @ least in comparison to most others here (w/ myself @ 45 yrs. of age)?? I learned to code from a LOT of guys a LOT older than myself, & they told me about the "why" of WHY 2 digit years were used (as well as assembly language): Space & Storage in RAM!
I.E.-> Back then? They didn't have gigabytes to work with as we do today - so, they had to "conserve" memory wherever & whenever possible (because "640k is all anyone will ever need", & before Mr. Gates said that, they were operating on a LOT LESS THAN THAT @ times), & guess what qualifies on THAT account??? Yes, you guessed it - date fields!
---
"So my compiler quite often tells me that I've assigned the wrong type to a variable, or that my pointers have bounced off the end of an array, or that I've tried to dereference NULL" - by ledow (319597) on Tuesday June 15, @08:20AM (#32576474) Homepage
This? This is where "custom error handlers" (such as older VB6 & below had in "On Error Resume Next" or .NET, Java, & Delphi's "Try-Catch") are your best pal... you can "override" the std. structured err handlers the compiler gives you, with ones of your own!
(Over time/over the years, I have caught various programmers omitting that in their code (arstechnica's "CoolMon" being one) & I had to tell their coders they lacked customized err handlers... this is often the mark of someone either poorly taught, self-taught, or just a careless coder usually! Error Trapping/Handling? MATTERS!)
---
"Design systems where XSS attacks and SQL injections *AREN'T* possible (as far as you can humanly tell) - this is easy, it's called not using XSS and SQL" - by ledow (319597) on Tuesday June 15, @08:20AM (#32576474) Homepage
On Mr. Kaminsky's article, & what you stated above:
Well, it's all "well & good" he's taken the time to build tools others can use to "watch out" for 'web programming' (I use this term loosely, as I largely do NOT consider it "classical programming" as done in languages such as C/C++, Delphi, or even VB) errors that lead to injection bugs, but, using STORED PROCEDURES is "the way" to avoid this, AND, to have the server do the work server-side & just return resultsets to the front-end (be that a custom database program, OR, a webbased application in a browser))...
APK
P.S.=> Otherwise? Hell of a post, you merit your "+4 Informative upward modded posting"... & it'd be a "+5" in my book, if you didn't overlook that part (then again, you probably aren't old enough OR you haven't been exposed to folks that had to write code, pre-1980, either)... apk
You'd think that preventing SQL injection attacks was difficult. Basically don't allow multiple queries per request on your db and filter out semi-colons (or replace them with "") from post/get vars.
America, Home of the Brave.
call_user_func_array() You just have to make sure the parameter array contains references to variables
Then the code has to maintain three things in parallel: the string of ?s in the SQL, the list of argument types, and an array containing references to elements in another array. Does this method, which requires reaching into more obscure corners of PHP (references and call_user_func_array()), provide noticeably more safety than a dedicated function for escaping lists?
(mysqli_stmt_bind_param is deprecated, use mysqli_bind_param instead)
I don't use either; I use the bind_param method of a prepared statement object.
So what, you pitch the same ideas over and over again until someone thinks its a good idea?
~Syberz
I don't see the point of this 'solution' - it's going to make things worse. The world is going to build a whole bunch of 'better' idiots that will get around the 'magic tool' in ways that will make your head spin. It's solving the wrong problem.
I also don't understand the infatuation with stored procedures. Programming in the database vendors language is horrible compared to most client side languages. You can concatenate all sorts of dynamic queries client side without opening yourselves to injection attacks if you do it correctly. Decent server implementations cache these queries so you don't lose anything performance-wise either
To all those people who made my life a recent misery by writing crap like:
with ridiculous string operations both prior to calling and then inside of the stored procedure in question, lots more lines of hardcoded bits and pieces some of which get used, some not; misleading or outright lies in the comments (if any) eventually followed by an EXEC (@my_funkified_unmaintanable_mess_sql_string)
You all suck. Please desist, educate yourselves and apologise whoever you are.
"using STORED PROCEDURES is "the way" to avoid this" - by Anonymous Coward on Tuesday June 15, @11:44AM (#32579188)
Going to "correct myself" (actually, write it better & better defined on my part) before ledow can or does, lol!
So, amending my statement above?
You'd need a GOOD DBA to do the above, AND, one that uses the following:
---
A.) Parameterized SQL statements (validating the input, looking out for things like added single quotes passed in (which client-side apps should check for as well prior to passing the parms to the stored proc from a "front-end" app))
B.) Validations of all inputs coming from the user and front end, on the server (even though I recommended doing some of that in the user front-end program as well)
D.) Use parameterized stored procedure w/ embedded parameters (per what I wrote above).
E.) Execute stored procedures using a safer interface like callable statements in JDBC or CommandObject in ADO (MS).
F.) Use a limited privileged accounts to run databases and also systemwide & db security (both native to DB and via programming rights given by programmers (doable via logon systems type stuff, which assign rights to various users & their access to various parts of the DB)).
F.) Use strong privileges for the stored procedures used in apps
G.) Avoid using dynamic SQL query work.
---
So there you are... I tend to think ledow KNOWS what he's about here, and I don't feel like getting "nitpicked" to death by he if I can help it, lol!
APK
I think most (?) languages already have this. It's called using a parameters collection or prepared statements instead of SQL & "CONCATENATION" & HAX. The frameworks already exist. The solution is to fire or brutally "retrain" the programmers who are writing this sloppy code to begin with. The security problem is so widespread that the language or compiler should flag any concatenated string as "dirty" and disallow passing it into the database API to begin with... Maybe that is what this "framework" from Kaminsky is actually doing.
http://it.slashdot.org/comments.pl?sid=1686254&cid=32580108
What's in that URL above addresses your further points, quoted here next:
"Run-time error checking (e.g. exception handling) is also another world to compile-time, but I was simplifying in order to make my post sound more impressive (*cough*). I think one of my previous posts on here was about checking damn return values (and how return values / exceptions / error flags etc. are all pretty much equivalent operations but done via a slightly different mechanism - sometimes it differs by as little as what register they are put into, if at all), which pretty much should be written on a little illuminated signpost and screwed to every programmer's retina." - by ledow (319597) on Tuesday June 15, @01:11PM (#32580512) Homepage
Fair enough & I cover that in my "self correction" (like yourself, I was being TOO brief in my init. post in reply to you, and I corrected it "on the fly" after reading it again, so I was more "specific" is all)... & that signpost you speak of?
It IS "screwed to my retina" & has been for years now... as it's "bitten me in the behind" before those times, & better programmers than myself (rather more experienced ones @ the time circa 10-15 yrs. prior to today that is) whom I had worked with BEAT IT INTO MY HEAD is how/why (along with DBA & System/Business Analysts)... I am glad they did too!
and
"If return values were checked properly, the Google-researcher-discovered Windows XP vulnerability that was posted on here last week ( http://seclists.org/fulldisclosure/2010/Jun/205 ) , that's been in the OS for however-many years would never have happened. It all stemmed from XSS and other problems but the main point of execution was via an unchecked error return value from a minor utility function that converted hex digits to numbers. This is where things like CVS 'blame' should be wired up to some kind of electric-shock device in the programmer's chairs." - by ledow (319597) on Tuesday June 15, @01:11PM (#32580512) Homepage
Again, I think you will LIKE what I put into my "self-correcting" URL 'reply to myself', lol, because it addresses much of what you noted in this quote in fact... and, with SPECIFICS (which I felt I lacked in my init. reply)...
APK
P.S.=> Again? Yes, that "electric shock device" was in my chair a few times over the years, but, it doesn't have to be anymore (I had "quite enough of that", lol, & beating myself up with my mistakes in code - but I am fortunate over time to have worked alongside what I feel have been TRULY "World-Class" people in teams around me who helped ME become "better, faster, stronger" than I was prior to having known them (& having them correct "my ways" in code @ times also)... apk
This is like a making technical control to manage a social engineering risk... missing the point.
So the fact that this is intended to be a commercial product makes it unimportant? Put down the FOSS banner you've been waving and get off your high horse.
Kaminsky is one of the most brilliant security researchers on the planet. For people who care about computer security, when Dan Kaminsky makes an announcement, it's "worth reading".
Comment removed based on user account deletion