×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Kaminsky Offers Injection Antidote

kdawson posted more than 3 years ago | from the won't-have-xss-to-kick-around-anymore dept.

Programming 244

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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

244 comments

FIRST POST (-1, Troll)

Anonymous Coward | more than 3 years ago | (#32575752)

OMG OMG OMG OMG
I ORGASMED

productize? (5, Insightful)

DNS-and-BIND (461968) | more than 3 years ago | (#32575768)

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.

Re:productize? (1)

WrongSizeGlass (838941) | more than 3 years ago | (#32575928)

The article wasn't all that informative, and yes, red flags went up as soon as I read "deliverable" & "productize". Basically his framework requires "developers to use different prefixes that describe variables of the strings, without requiring any major changes to their coding style". That's the gist of the important info in the article.

I'm not making any statements or claims against Kaminsky, Recursion Ventures or Interpolique. I'm just agreeing that the article wasn't all that great.

Ironically, the Recursion Ventures website [recursionventures.com] is hard to read, too.

Re:productize? (0)

geekmux (1040042) | more than 3 years ago | (#32575930)

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.

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.

welcome to slashdot, we condemn fools (0)

Anonymous Coward | more than 3 years ago | (#32576068)

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

Re:productize? (1)

nyctopterus (717502) | more than 3 years ago | (#32576094)

The whole point is that it wasn't a grammatical error, it was intentional marketing-speak. People that use such language often don't have a clue what they are talking about. If you don't want to sound like a moron, don't talk like one.

Re:productize? (2, Insightful)

John Hasler (414242) | more than 3 years ago | (#32576410)

People that use such language often don't have a clue what they are talking about.

Or worse, they do.

Re:productize? (1)

hedwards (940851) | more than 3 years ago | (#32576454)

I've got a patent pending solution. First step you buy a copy of the OED, the largest one you can find. Step 2, you buy a tall ladder, preferably 10" or higher. Step 3 you place said ladder in front of subject. Step 4, you climb it and drop it straight on his head. If the spelling doesn't stick, chances are you've got quite a mess on your hands, and ought to pick up some cleaning supplies.

Re:productize? (0)

Anonymous Coward | more than 3 years ago | (#32576602)

So I guy walks into a bar and pulls out a 10'' pianist ...

Re:productize? (1, Offtopic)

DNS-and-BIND (461968) | more than 3 years ago | (#32576556)

What on Earth makes you think a random commenter on Slashdot would have "met Dan" before? Is meeting the author a prerequisite to comment now? I just said marketroid speak turns me off and based on my previous experiences has a very high potential for being bullshit. Or did you just want to show off how cool you are in front of everyone..."oh yes Dan and I have met and we're on a first-name basis! Look at me and respect me! Remember the utterly forgettable handle I use on this website and quake when I write, for it is with the voice of Oz himself that I speak! Lo, I have met the author of an article on slashdot. Look on my words, ye mighty, and despair!"

Well (2, Informative)

buchner.johannes (1139593) | more than 3 years ago | (#32575976)

the essence is this:

It requires developers to use different prefixes that describe variables of the strings, without requiring any major changes to their coding style, he says. And the resulting code is automatically formatted in such a way that can't be easily abused by the bad guys.

"Our system makes it very clear what is data and what is code without asking the developer to jump through hoops to make that expression" as with existing secure coding options for string-injection prevention, Kaminsky says. The tool establishes a boundary between data and code and then translates it for the destination coding language -- be it SQL or JavaScript, for example, he says.

Which means he enforces a convention on developers that aims to improve code security. Sounds smart.

Re:Well (1)

nacturation (646836) | more than 3 years ago | (#32576026)

the essence is this:

It requires developers to use different prefixes that describe variables of the strings, without requiring any major changes to their coding style, he says. And the resulting code is automatically formatted in such a way that can't be easily abused by the bad guys.

"Our system makes it very clear what is data and what is code without asking the developer to jump through hoops to make that expression" as with existing secure coding options for string-injection prevention, Kaminsky says. The tool establishes a boundary between data and code and then translates it for the destination coding language -- be it SQL or JavaScript, for example, he says.

Which means he enforces a convention on developers that aims to improve code security. Sounds smart.

Interesting... a naming notation to describe the contents of variables. Hungarians like Kaminsky sure are smart!

Re:Well (1)

buchner.johannes (1139593) | more than 3 years ago | (#32576372)

Interesting... a naming notation to describe the contents of variables. Hungarians like Kaminsky sure are smart

Hungarian notation duplicates information the programmer and the system already knows into the syntax. And its not comparable since there is no framework that checks if the programmer actually used the right prefix matching the variable type.

Here, the notation adds information the programmer knows to the system. One could also think of declaring or annotating a variable, allowing it to contain code. That this information is useful to the system (security) is known (W^X and the such).

Re:Well (0)

Anonymous Coward | more than 3 years ago | (#32576762)

Hungarian notation duplicates information the programmer and the system already knows into the syntax.

Off-topic, I know, but this statement really only holds true in strongly-typed languages. If you need to declare a variable as an int, float, String, Boolean, etc. then Hungarian notation is redundant. The system knows what it is, and any IDE more advanced than Notepad will tell you what it is. Where Hungarian really shines is loosely-typed languages, like JavaScript. All you do to declare a variable is use the "var" keyword (and some people don't even do that, creating yet another avenue for XSS by screwing with global variables).

Back on topic, Kaminsky seems to be taking the concept of Hungarian notation to the next level. Instead of it being mere syntax, he developed a tool to give it real semantic value. For those of us who are mindful about security, this is a minor time-saver at best, but it's huge for at least securing the code monkeys' works. Doesn't help make their code any more efficient, elegant, or extensible, but you can't get everything on a budget.

Re:Well (1)

ais523 (1172701) | more than 3 years ago | (#32577206)

What you're describing is Hungarian notation, the way it was originally intended. Unfortunately, the original paper describing Hungarian notation used the word "type" to define this sort of metadata, and it was misinterpreted as meaning "type" as in data type, leading to a sort of bastardised Hungarian that isn't much good for anything. What's semi-new, and interesting, here is the compiler automatically enforcing the meanings of the prefixes. (Splint, a static checker for C, has done that sort of thing for a while, and would be very useful if it wasn't so buggy it was almost unusable.)

Re:productize? (-1, Offtopic)

Rogerborg (306625) | more than 3 years ago | (#32576182)

Theory: "productize" is one of the keywords that the kdawson editard script uses to find likely Slashvertisements.

Re:productize? (0)

Anonymous Coward | more than 3 years ago | (#32576894)

He essentially argues that instead of actually dealing with the problem we should push for the use of Hungarian notation instead. So it isn't really a framework, let alone one that will prevent injection holes on a structural basis. If it were an actual 'framework', he might have considered for example using different classes for normal text, HTML text, SQL text, etc. that can't be coerced by the type system without the necessary escaping. If you were to combine that with io-libraries (or bindings for them) that actually use these classes, that actually might go a long way in preventing injection attacks.

Re:productize? (0)

Anonymous Coward | more than 3 years ago | (#32577352)

Hey he stole the DNS flaw, wonder where he stole this gem.

How is it different from what other frameworks do? (-1, Offtopic)

youn (1516637) | more than 3 years ago | (#32575788)

don't really know this particular framework... but a lot of them offer some sort of XSS & SQL injection protection ... how is it ground breaking ?

Re:How is it different from what other frameworks (1, Funny)

Anonymous Coward | more than 3 years ago | (#32575944)

how is it ground breaking ?

dude, it's a renowned researcher, and he's got a shovel.

Re:How is it different from what other frameworks (0)

Anonymous Coward | more than 3 years ago | (#32576400)

Don't see how he was marked as troll. It is not ground breaking at all.

Parameterized SQL (5, Informative)

ultranova (717540) | more than 3 years ago | (#32575820)

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?

Re:Parameterized SQL (2, Insightful)

Anonymous Coward | more than 3 years ago | (#32575840)

The developer culture around SQL, where the majority of tutorials, cookbook methods, forum support groups, "expert" examples, etc. reinforce doing SQL the insecure way. It may not be current practice, but you can't rewrite the decades of bad advice still out there and being indexed, referred to, taught in introductory classes by uninterested tutors, and used by people who think infosec is analogous to physical security.

Re:Parameterized SQL (5, Interesting)

erroneus (253617) | more than 3 years ago | (#32575916)

There is truth in what you say. "Developer culture" has grown in many bad an improper ways. It's sad and unfortunate. Of course, every time I say so, I lose karma points or whatever. But you have to admit that developer culture varies largely on the platform for which they are developing. Are there excellent Windows coders? Oh yeah, I'm sure of it. Are there bad Windows coders. The question doesn't need to be asked. What is the rate and proportion of said developers? It's a guess but I favor a higher proportion of bad coders in Windows. Do other platforms foster bad/lazy coding?

Well, as put, yes. Tutorials and methods and the like tend to get the messages across as simply and directly as possible. Inserting error check and validation code might confuse matters. But for people who are learning, they may not realize the need for such code until it is too late.

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.

Windows and Mac are both quite "closed source" and peer review, if any ever occurs, happens internally. Linux is open sourced and peer review happens all the time.

Re:Parameterized SQL (2, Insightful)

AlexiaDeath (1616055) | more than 3 years ago | (#32575940)

I agree with you on most of what you said. However, people who are just learning have no business writing business critical code for high risk environments, much less without strong supervision.
Also, writing checks for every case imaginable bloats your code and then there are all the cases you didn't imagine but a clever hacker does. the solution is to write checks for everything valid and have a standard procedure for everything invalid.

Re:Parameterized SQL (1)

WrongSizeGlass (838941) | more than 3 years ago | (#32576120)

However, people who are just learning have no business writing business critical code for high risk environments, much less without strong supervision.

This is very true, but bad habits that are learned early are hard to break. When these 'noobies' start to work on more critical stuff, and they have deadlines, and a boss who isn't as 'understanding' as you or I, they will cut corners because it is already in their repertoire. Teach them properly, right from the start, and everyone is in much better shape: noobies, teachers, employers, the dev community, site owners & operators ... and the general public.

Also, writing checks for every case imaginable bloats your code and then there are all the cases you didn't imagine but a clever hacker does. the solution is to write checks for everything valid and have a standard procedure for everything invalid.

Amen.

Re:Parameterized SQL (1)

erroneus (253617) | more than 3 years ago | (#32576662)

I think the bloat needn't be as bad as you imagine. For example, if you are screening for illegal/disallowed characters in your input string, you could write a series of if/then to test for each one, or you could define a string comprised of disallowed characters and write a loop to test for the presence of any of those characters in the input string. You can be as clever or slick as you like so long as it is accurate and complete. But calling it bloat is something of a misnomer. Are seatbelts on a car "bloat"? Are safety checks on your microwave oven bloat? The point of processing data through software is to ensure that it is accurate and usable data. Data validation is not bloat, it is an essential and requisite function to data processing. It used to be said "garbage in, garbage out." I wonder when people stopped saying that?

Re:Parameterized SQL (2, Insightful)

AlexiaDeath (1616055) | more than 3 years ago | (#32576972)

Sensible safety is never bloaty, its sleek, functional and manageable. Built in safety for every imaginable risk is bloat and risk in itself because your imagination is the limit of your protection and a management nightmare because people keep on thinking up new ways things can go wrong, while the amount of right things stays the same. Data validation is one of the most basic things you can do. But doing it the blacklist way is a slippery slope. Oh, and just for a little mind-bending, imagine a car seat that has safety for every imaginable thing that can go wrong in a car with just the driver from you spilling hot coffee to having a heart attack and compare what you imagine to what you get in an average car. Bloat point should become obvious.

Re:Parameterized SQL (1)

insertwackynamehere (891357) | more than 3 years ago | (#32577186)

I would probably use regex for this. If the language didn't support regex, I would assume that this was a much smaller scale app or utility and then review my options based on that, but for any good sized project, regex would do the job better than any sort of native character comparisons and I can't imagine there is any serious development language that doesn't have a regex library or regex support.

Re:Parameterized SQL (3, Interesting)

Charliemopps (1157495) | more than 3 years ago | (#32576862)

Have been in the situation of having no idea what I was doing and writing business critical code, I'd like to explain how this happens. My boss comes to my team and yells "DO MORE WITH LESS!!!" They decide my department is now in charge of things some other department used to do but they fired them all. When we can't keep up, management comes to us and declares that we obviously must be surfing SlashDot all day instead of working and institutes a metrics system. It's supposed to track every piece of work we do, assign how long it "Should" take to complete (a totally invented number) and then track it. At the end of the day we get a stat that says we were "70% productive" because we completed 70% of what they thought we should. What the system really does is make it take twice as long to do all that work that we now had too much of to do anyway. We start working through our breaks and lunches trying to make our numbers. Finally one day I realize the similarity between many of our tasks. I realize a lot of tasks could be made easier if there was a web-page that collected a lot of the info together, and then maybe some scripting that added things to some different databases. I have limited skills coding so I go out and find example code, manipulate that code until it "sort of" works for what I need. Finally I can make my stats. After a few weeks my manager comes to me "It's impossible for you to meet these stats how are you doing it!" I explain what I have written and I suggest that we have our code department write something similar that actually follows standards and what-not. But no, they apparently are not taking on any new projects at this time because they are busy writing a database for tracking their projects (Totally serious, that's really why they denied our request) My boss decides that what I've written is too important for them not to use. I explain MANY TIMES that I am not a programmer, have no schooling, I just found bits of code on the net, modified it extensively, and not only that what I've written goes down in flames on a REGULAR basis. We're talking database corruption, Crashing the entire workstation etc... They understand that but are going ahead with it. They say they will get a spare programmer to help me work the bugs out when ones available. It's now 3 years ago, my code has grown into a monstrosity beyond imagination. It controls much of everything we do, but every few hours I'm called to fix it. One of the databases corrupts so often that I have it back itself up every 15 minutes but we still constantly lose data. Meanwhile my boss has had me add feature after feature and completely eliminated any time I had been given to maintain the code, making things more complex and dooming the entire system to an even earlier death. When they finally got a coder to look at it was such a mess at that point that they quoted them a total rewrite and a price tag that was 4x my annual salary. The fact that the entire thing hasn't collapsed in on itself is a shocking to me, meanwhile my department is now so dependent on the mess that when it collapses I don't think we could continue to function at all.

Re:Parameterized SQL (0)

Anonymous Coward | more than 3 years ago | (#32577114)

Jesus wept.

code review (5, Informative)

John_Sauter (595980) | more than 3 years ago | (#32576726)

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.

Re:Parameterized SQL (1)

TheSpoom (715771) | more than 3 years ago | (#32576860)

Shame and ridicule are still around; they're just on IRC support channels and newsgroups.

Re:Parameterized SQL (2, Informative)

Nerdfest (867930) | more than 3 years ago | (#32576186)

but you can't rewrite the decades of bad advice still out there

At this point I'd settle for people not writing SQL in all caps with the vowels removed. It's like the 'convention' is to make SQL as unreadable as possible. The 70's are over folks, toss your caps-lock key and buy a vowel. SQL can be readable.

Re:Parameterized SQL (1)

Tim99 (984437) | more than 3 years ago | (#32576664)

At this point I'd settle for people not writing SQL in all caps with the vowels removed. It's like the 'convention' is to make SQL as unreadable as possible. The 70's are over folks, toss your caps-lock key and buy a vowel. SQL can be readable.

Those of us who are refugees from the 70's know that we use capitals for SQL keywords and lower case/mixed case for tablenames, columnnames and values. So
SELECT colname FROM Tablename WHERE colname IN ('value1', 'value2')
is easy to read. Those of us who can do this stuff without needing to use ROR (or whatever is fashionable) are happy with the old stuff - As almost everything that is important (paying people, bank accounts, staff records, etc.) is still in SQL or COBOL you probably should humor us.

Re:Parameterized SQL (1, Insightful)

MichaelSmith (789609) | more than 3 years ago | (#32575858)

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?

I question the need for SQL. Can't we have a simple OO query system? We don't need to write strings of TCL to interact with GUI components.

MOD PARENT UP (-1, Redundant)

coder111 (912060) | more than 3 years ago | (#32575924)

Prepared statements or queries with parameters have been around since forever, and they are impervious to SQL injection attacks. Just go ahead and use them.

--Coder

Re:Parameterized SQL (1)

buchner.johannes (1139593) | more than 3 years ago | (#32575960)

You don't understand all kinds of SQL injection attacks if you think prepared/parameterized SQL statements will save you.

Re:Parameterized SQL (0)

Anonymous Coward | more than 3 years ago | (#32575996)

Could you give some examples?

Re:Parameterized SQL (1)

what about (730877) | more than 3 years ago | (#32576004)

It would be useful to the whole slashdot if you could support your assertion with some examples or reference.

NOTE: As far as I understand the "injection attack" is able to completely change the behaviour of a SQL statement, something like transforming a select into a delete or alter, we are not talking here of some SQL errors that are something like

DELETE from ana_tbl WHERE ana_name LIKE (?)

The above statement can easily be abused if someone pass % as "name", but it is NOT injection attack, it is just plain stupidity from the developer.

So, would you please give us some reference ?

Thanks

Re:Parameterized SQL (1)

Splab (574204) | more than 3 years ago | (#32576130)

Do tell us how you inject SQL into a parameterized SQL statement.

Re:Parameterized SQL (1)

will_die (586523) | more than 3 years ago | (#32576428)

Since this was the first post asking the question on how to inject sql when paramters are used.
When the statment that parameters do not protect the person who is making the statement wants to beable to pass table names into the select statement, in the FROM portion, and you cannot paramaterize table names.
Yes they are missing the point.
The other example I have been given is they want to pass generate a complete where string pass that through a parameter and expect that the parameter will provide protection.

Re:Parameterized SQL (1)

Splab (574204) | more than 3 years ago | (#32576610)

What database are you using?

You can't supply table names in the ones I'm using, in fact the whole point of a parameterized (fuck me I can't spell that) query is to have the query in a fixed state rather than creating them dynamically.

Regarding your other point, when you use parameterized queries you have a guarantee from the driver to escape anything that's put into the position/binding, I don't care how random your string is, there is simply no way you will inject anything into my database.

(Also, I'm using stored procedures and strict user policies for everything, which makes it even harder for you to inject anything), in fact there is no service that can connect to my database with any kind of access to tables.

Re:Parameterized SQL (1)

Alex Belits (437) | more than 3 years ago | (#32576922)

Regarding your other point, when you use parameterized queries you have a guarantee from the driver to escape anything that's put into the position/binding, I don't care how random your string is, there is simply no way you will inject anything into my database.

Actually it's better. Parameters are never seen by SQL interpreter because they are applied to already interpreted queries -- they are not escaped because they don't go through the mechanism that escapes and un-escapes anything. Obviously, if someone is stupid enough to take data from a database and concatenate it with something else to construct an interpreted query statement, he will face exactly the same problem if he taken that data directly from the user -- parametrized queries are only useful if ALL queries are parametrized.

Re:Parameterized SQL (1)

larry bagina (561269) | more than 3 years ago | (#32576964)

SELECT * FROM ? WHERE ? -- is that what you're thinking? Good luck on that one since string parameters are quoted. And most DB engines would reject it.

Re:Parameterized SQL (0)

Anonymous Coward | more than 3 years ago | (#32576150)

You don't understand the meaning of the words "SQL Injection Attack" if you think there are varieties to which parameterized statements (for you T-SQLers out there, that's "stored procedures") are vulnerable. Parameterized statements aren't a panacea for all SQL vulnerabilities, but they very effectively close the door to SQL injection attacks.

no example needed idiot || troll (0)

Anonymous Coward | more than 3 years ago | (#32576152)

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/ [bobby-tables.com]

Re:Parameterized SQL (0)

Anonymous Coward | more than 3 years ago | (#32576212)

Ok, back it up and tell us how.

Yeah, I thought so.

Re:Parameterized SQL (1)

Webz (210489) | more than 3 years ago | (#32576204)

There are many types of queries (typically those that go beyond CRUD operations or are a little meta) that cannot be parameterized.

Re:Parameterized SQL (2, Insightful)

Shados (741919) | more than 3 years ago | (#32576252)

Considering there are entire extremely complex systems made purely on stored procedures (which, from a client point of view, basically are just a little more than parameterized queries), 99.9% of the time if you cannot parameterized a query, you're doing wrong.

There's nothing stopping you from building a dynamic SQL string with parameters, and get the advantages without the drawbacks if you do it right (like using HIbernate/Nhibernate or equivalent) :)

Re:Parameterized SQL (0)

Anonymous Coward | more than 3 years ago | (#32576994)

Please provide an example. Because I don't believe you.

Re:Parameterized SQL (1)

StormReaver (59959) | more than 3 years ago | (#32576244)

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?

Because there's money to be made selling snake oil to bad programmers. Why give them a simple solution for free, when you can sell them an expensive delusion instead?

Re:Parameterized SQL (1)

RogueCode (517348) | more than 3 years ago | (#32576290)

You can't use parameters for things like table and column names, so you can't write stuff like an "advanced query", where you add additional clauses to a select statement in order, without some kind of string concatenation. This fact, in turn, opens the door to SQL Injections even if you use parametrized queries. Another scenario is when you use parametrized SQL to call a stored procedure which is vulnerable to SQL injection. Bottom line: Parametrized SQL helps, but does _not_ completely prevent SQL Injection.

Re:Parameterized SQL (0)

Anonymous Coward | more than 3 years ago | (#32576392)

So basically a parametrized query can be broken by being "advanced" and including string concatenation into it (thus making it not a parametrized query). Also a parametrized query can be written to call a query that isn't parametrized which makes the parametrized query the problem, not the crappy non-parametrized query.

Re:Parameterized SQL (1)

A nonymous Coward (7548) | more than 3 years ago | (#32576836)

And you are fool enough to get table and column and all sorts of schema names from user input? Building strings is not the problem -- building strings from user input is the problem.

Re:Parameterized SQL (1)

RogueCode (517348) | more than 3 years ago | (#32577164)

No - I'm not a fool, but I do security reviews for a living, and this is the kind of stuff a see all the time. Anyway, my point is about the misconception that parametrized SQLs can get you rid of all kinds of SQL injection. As you wrote, the basic problem is lack os proper user input sanitization.

Re:Parameterized SQL (1)

Xest (935314) | more than 3 years ago | (#32576524)

Judging from the summary this tool is useless for good developers- I know I trust myself with security with regards to things like SQL injection attacks more than I'd trust some automated system to eliminate them.

But it sounds like it's designed as a crutch for incompetent developers, those who don't use paramters or prepared statements because they don't know they exist/don't understand them/can't be bothered to learn about them/have some irrational reason for not using them.

Personally though I'm not sure we should keep bad programmers up on crutches, I'd rather just see them hounded out of software development altogether, because you can guarantee as soon as you've given them a crutch for one thing they're incompetent out, they'll find novel new ways to foul something else up and riddle something else with security holes one way or another.

I think tools like this simply mask the fundamental problem, that there are no real repercussions against bad software developers- there's no real accountability in the industry for the truly incompetent. I'm not advocating criminal or even civil punishment for software bugs or anything like that, because everyone makes some mistakes, but it'd be nice if we could at least keep the consistently bad people who do more harm than good out of the industry.

Still, I suppose you can't entirely fault Kaminsky for this effort, I guess he's working with what we have, rather than what we should have, trying to at least minimise the impact of the bad developers we're lumped with.

Re:Parameterized SQL (0)

Anonymous Coward | more than 3 years ago | (#32576710)

Why not simply use them exclusively?

Because the vast majority of them suck total shit at query building. Once you start having WHERE expressions that depend on whatever, you might as well just create a huge if tree with every possible combination of expression so you know you're passing the right crap in the right order. Otherwise, you'll never figure out if you've got the right number of parameters in the right order.

PHP/pg_sql at least makes up for its shitty $5 notation (fuck we have named arrays, use them bitches) by making the parametrers passed in an array rather than trying to be badasssss with VARARGS. That means PHP developers can at least do if ($_POST["limitby_name"]) { $where.="AND name=$".($parameter_counter++)." "; array_push($parameters,$limitby_name); }

But you know what would rock my self-centered little world? $where.="AND name=\$limitby_name "; pg_execute($pg,"query",$_POST);. And stop fucking throwing errors when theres more parameters in the array than I used. No shit sherlock!

Bonus points if you can do that without proceeding to have to call some form of parameter binding function 50 times to be sure you got all of the columns of a SELECT * query.

Also, IN ().

should be marketed as a plugin to extant tools? (0)

Anonymous Coward | more than 3 years ago | (#32575828)

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.

"Kaminsky" (0, Interesting)

Anonymous Coward | more than 3 years ago | (#32575872)

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.

Re:"Kaminsky" (1)

geekmux (1040042) | more than 3 years ago | (#32575956)

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.

Jesus, what is with the grammar nazis on this?! Let it go already. True IT geeks write and comment code, they don't write fucking novels.

Re:"Kaminsky" (2, Insightful)

Hognoxious (631665) | more than 3 years ago | (#32576174)

Jesus, what is with the grammar nazis on this?

Nullset to connectionate with grammarifical authoritarists.

True IT geeks write and comment code, they don't write fucking novels.

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.

Re:"Kaminsky" (0)

Anonymous Coward | more than 3 years ago | (#32576678)

This comment is almost worth creating an account just so I can mod it up.

Fans of functional programming (1, Informative)

Anonymous Coward | more than 3 years ago | (#32575878)

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.

mysql_real_escape_string() (2, Funny)

bcmm (768152) | more than 3 years ago | (#32575890)

This sounds an awful lot like a special version of mysql_real_escape_string() with extra buzzwords.

Re:mysql_real_escape_string() (5, Funny)

nacturation (646836) | more than 3 years ago | (#32576042)

This sounds an awful lot like a special version of mysql_real_escape_string() with extra buzzwords.

Soon to be deprecated and replaced by mysql_gosh_we_mean_it_this_time_escape_string()

Re:mysql_real_escape_string() (0)

Anonymous Coward | more than 3 years ago | (#32577334)

I fear you're being too kind with even that degree of consistency in the API. I foresee something closer to: we_mean_it_This_time_escape_MySQL_string();

Kaminski offers injection (-1, Troll)

Anonymous Coward | more than 3 years ago | (#32575920)

Kaminski offers injection of semen up your arse

Semi-technical paper (1)

will_die (586523) | more than 3 years ago | (#32575936)

There is a slideshow at http://www.scribd.com/doc/33001026/Interpolique [scribd.com] 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.

Great... (1)

AlexiaDeath (1616055) | more than 3 years ago | (#32575962)

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.

Re:Great... (1)

Civil_Disobedient (261825) | more than 3 years ago | (#32576794)

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.

In the Java world they already do. It's called Hibernate [hibernate.org] (or NHibernate [jboss.org] for .NET). It does exactly what you describe.

The only people that should be mucking about in SQL are DBAs that...

  • Know what the fuck they're doing
  • Have a good fucking reason to use it (stored procedures, custom reports, business functions, etc.)

Another crutch (3, Interesting)

Mag7 (69118) | more than 3 years ago | (#32576012)

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.

Re:Another crutch (1, Insightful)

Anonymous Coward | more than 3 years ago | (#32576090)

Bad developers aren't shamed out of the industry, they either carry on churning out bad code or become managers. The people who leave the industry are the decent programmers who tire of working with incompetent assholes.

Re:Another crutch (4, Insightful)

gorzek (647352) | more than 3 years ago | (#32576346)

Having seen this sort of thing firsthand, bad programmers get away with being bad programmers because they have managers who are non-technical and whose bullshit detectors are defective or non-functional.

"It broke because [insert justification that absolves shitty programmer]."

Part of it is just a corporate culture thing. Some companies encourage honesty and owning up to your mistakes so you can learn from them. Other companies have you living in fear of making even the tiniest mistake, so you'll find any excuse you can to make a given problem someone else's fault. Guess which type of company ends up inadvertently protecting the lousy programmers.

This is advertisement, not a story (3, Interesting)

hubert.lepicki (1119397) | more than 3 years ago | (#32576044)

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?

Re:This is advertisement, not a story (1, Funny)

Rogerborg (306625) | more than 3 years ago | (#32576178)

This is advertisement, not a story

What part of "kdawson" is confusing you?

Re:This is advertisement, not a story (1)

setrops (101212) | more than 3 years ago | (#32576200)

Most good developers, but if like me you belong in a very large company and developpers are hired by contract the end result can always be suprising. Because most don't care. They are given a timeline and no matter what the sales dept. will have their way.

oh yes we do vulnerability assessments and code review, but if someone invents the magic wand to make all the bad go away we would surly invest in it.

Oh look it's summer, here comes the students to work on all those special projects.

Re:This is advertisement, not a story (1)

TubeSteak (669689) | more than 3 years ago | (#32576292)

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?

The point of this article is that major vendors/websites continue to place vulnerable code facing the web.
And this is despite the fact that "most developers aware of SQL injection / XSS" and many frameworks attempt to prevent your errors for you.

Because of this, Kaminsky will get rich off his startup if the program secures (in an automated fashion) what everyone else has tried and failed to secure.

Re:This is advertisement, not a story (2, Informative)

Dunbal (464142) | more than 3 years ago | (#32577004)

What's the point of this article?

From TFA: "Dan Kaminsky today went public with the launch of a new venture"

      That was the point of the article. He wants you to buy his "product". Me, I'm sticking to good old fashioned Eau de Snake.

this is just taint mode (4, Interesting)

dirtyhippie (259852) | more than 3 years ago | (#32576088)

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/ [webreference.com]

In short, it's not that interesting, although if people pick it up and actually use it, it could do some good.

Re:this is just taint mode (1)

John Hasler (414242) | more than 3 years ago | (#32576464)

> Seems to me that this is just perl's taint mode...

Yes, but that doesn't matter because Perl is out of fashion.

Police & courts have a role too (1)

Max_W (812974) | more than 3 years ago | (#32576128)

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.

Re:Police & courts have a role too (4, Insightful)

ledow (319597) | more than 3 years ago | (#32576474)

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) without some possibility of error creeping in - take away compiler warnings, established libraries and type-checking and it's even harder. There is no way to stop this, none at all, while humans are programming.

The way to reduce such incidences is not to sow a mistrust of computer hardware (because that's just completely misguided) or to educate every programmer (or layman) on every possible security technique (although that helps, it's an impossible social task) or to mathematically prove every piece of code (that can take DECADES just for a quite-average program). The way to do this is to make interpretation of the code match what the programmer is thinking. This is done by toolchains, programming languages, syntax checkers and other development items, such as the one mentioned in the article. If I could be absolutely certain that when I say "A = 1" in a programming language, it can be interpreted unambiguously, that's a big step, but major programming languages have shipped where that could easily be a test or an assignment without any warning. Because programming can *only* happen by human intervention at the moment (even the GA example above was "steered" by a human at every point), the way to stop things going wrong is to make the programming environment "human-resistant".

Education hasn't and never will counter these problems. I can tell the world not to use "goto" but nobody will actually listen, even if I exactly specify any caveats where its use is acceptable. The same for forming SQL queries without proper sanity checking, or buffer overflows, or anything else that causes security problems. C was invented 38 years ago and we *still* get C programmers who can't use it properly every single day (myself included, technically). That's a whole generation (or two) who were either brought up with, or acquired, bad programming habits that are not security-optimal. It will take *at least* another few generations of people to teach people how to program properly, even if we forced every one of them into "programming camp". And even then, stupid errors will result and people will find ways within their knowledge that still cause security problems.

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. That stops me making BIGGER errors than I would without it, and the more tools like that the better. Few open-source projects, which contain some of the best programmers in the world and some of the worst, have ever won awards for their code quality (GPSD springs to mind, but that's about it - and the BSD's, although they have a fairly decent track record, are a collection of other software so don't count in this instance). How is that judged? By the number of holes found by other humans. Computer-based checkers are nowhere near intelligent enough to do this for us because, well, they were programmed by humans.

The only thing we can do is make programming a little more bullet-proof. It's almost impossible to get a NULL pointer dereference in BASIC. It's virtually impossible to accidentally initialise instead of test without noticing with the GCC compilers. Each time something like that happens, we get a step closer to cleaner code. Not everything can be caught by compiler warnings, though, so a lot of what we do has to be programmed by *designing* it correctly, and some tools help fix that problem too. In the end, education does little, experience does a little more, and stopping people doing the stupid stuff does more than anything else. OS's that *don't* let you access past your allocated memory did more for computer stability than any guideline or programming rule ever did. 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. Or at the very least, applying decent checks at all stages.

Much better than not relying on a technology, or teaching the world about NULL pointers, would be to get people to refer to the people who *do* know their stuff, and to distinguish between those with an immaculate academic record and sound ideas and those without. This is a general rule for society that benefits a whole lot more than just computer-related security. There aren't enough of these experts in the world to do all our programming for us, and you can't "teach" anyone how to program that well, so the inevitable cheap programmers will always be around. So what we need to do is:

- Stop using the idiots for serious tasks (life-saving devices, etc.) - we already do this (hopefully).
- Give everyone as many tools as possible that can help prevent mistakes - we already do this (compiler warnings, debuggers, Valgrind, Coverity etc.)
- Stop letting people tar "computer programmers" with a single brush to include everything from 11-year-old's in their basement to expert logicians / programmers at NASA.

If I couldn't trust computers, I wouldn't be able to do *anything* today. Drive to work (ABS, airbags, ECU, etc.), *get* to work (traffic control systems, sat-nav, my watch, my credit card to buy petrol), work (PC's, printers, franking machines, lighting/heating systems, etc.), get home, or do an awful lot of leisure activities (play games, watch TV, listen to the radio, play most modern musical instruments, make a cup of tea, cook, have running water, etc.etc.etc.). I *can* trust computers. Therefore I *can* trust the majority of programmers. The minority can't be trusted and should never have been put in charge of their projects (human error in itself, so actually computer-security is more a corporate politics problem than anything else) and no amount of education can fix their mistakes. If their program *never* compiles / runs / gets security-assured / gets executed on a mission-critical system because of the problems in it, however, that's a major problem for them.

I will now cut out 99.9% of security-related problems: All managers must assign programming tasks to someone with a proven track-record in programming, and who is confident enough to push their code in front of a million people trying to attack their software and fix any reported problems before releasing it. There. Done.

Re:Police & courts have a role too (0)

Anonymous Coward | more than 3 years ago | (#32577246)

tl;dr

There is no silver bullet (1)

Gopal.V (532678) | more than 3 years ago | (#32576314)

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 [schneier.com].

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? :)

Wow....almost a concept (1)

hesaigo999ca (786966) | more than 3 years ago | (#32576744)

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...

I rememeber the good ole' days... (1)

Lisandro (799651) | more than 3 years ago | (#32577218)

...when you didn't need to spend your time in Slashdot dodging advertisements disguised as news.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...