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

Comments

productize?

[DNS-and-BIND]

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?

[WrongSizeGlass]

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 is hard to read, too.

Re:productize?

[nyctopterus]

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?

[John Hasler]

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

Or worse, they do.

Re:productize?

[hedwards]

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?

[DNS-and-BIND]

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

Re:productize?

[A nonymous Coward]

Page won't even load without setting a cookie. That's silliness enough right there for me.

Re:productize?

[laughingcoyote]

Anyone who uses marketese should not be "well-respected". I echo the condemnation for it.

Re:productize?

[mvdwege]

So essentially Kaminsky's vision comes down to: "Programmer's won't fix their code to prevent SQL injection errors. So my code will prevent SQL injections as long as developers fix their code to use my product"?

<facepalm />

Mart

Re:productize?

[bradorsomething]

Having heard Kaminsky speak a few times, I'd say he used that language as a personal joke... at least I hope he did. Dan is brilliant but his ego choked off his tact a long time ago.

Re:productize?

[Effugas]

[This is Dan]

Actually, that's how the Java version works -- you take strings, and subclass them into safe versions and unsafe versions. Then you combine, either through a vararg shell, or through sequential dot notation.

I'm not a big fan of either; I really think interpolation is the right way for a programmer to express intent, and the compiler should be smart enough to extract it.

Re:productize?

[abigor]

It's pretty interesting that a guy with a resume like yours (tour guide, a bit of web art here and there) feels qualified to imply that Dan Kaminsky, a respected security expert, doesn't have a clue and is a "moron".

Re:productize?

[toxonix]

The article was an attempt at getting some attention for what looks like a MySQL hack.

"Developers [..] prefer being able to reference variables inline, rather than through discrete [..] interfaces. "

This whole thing is half baked. It's all very poorly written too, which makes it even less credible. Good luck "productizing" a "framework" if your target audience is script kids and PHP hackers who BTW expect to benefit from everyone else's work for free.

Re:productize?

[dgatwood]

There are a lot of ways to make SQL injection attacks much, much harder. The simplest requires only a handful of changes:

• Use a transaction around every group of commands.
• Change your SQL database to disallow the comment string (--) in queries.
• Don't use a published schema.

By using a transaction around command groups, you ensure that any error will cause the entire transaction to be rolled back. By disabling the comment character, you make it impossible to make the rest of the command go away and not cause an error. By using an unpublished schema (and specifically, nonstandard column names), you make it nearly impossible for someone to correctly construct a working query out of the last half of the original query. Even something as simple as prefixing every column name with a hard-to-guess string is enough to make it insanely hard to inject SQL unless you pissed off an ex-employee.

That said, I wish substitution (interpolation) were the only query form available. It's particularly annoying in PHP, where you have to roll your own (or copy and paste out of the user-provided comments in the documentation) to get the functionality at all. The array of tokens to substitute should be an optional argument to mysql_query()....

Re:productize?

[StackedCrooked]

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

Or worse, they do.

They merely have a clue of what they're talking about.

Re:productize?

[Effugas]

[This is Dan]

The idea is that we make very expensive asks of developers, who simply don't follow our advice.

The question is whether we can ask less of developers -- specifically, whether we can get out of this silly zero sum game where the harder software is to write, the more secure it is.

Interpolique is an effort in this direction.

Re:productize?

[bi$hop]

You can't argue with one point that Dan repeatedly makes in his slides: the status quo isn't working. I commend Dan for thinking outside the box in an effort to address a very complex and challenging problem.

Re:productize?

[Anonymous Coward]

So you are basically bandaging strong-typing into languages that don't have strong-typing.

If that was really the solution, then why aren't we using strong typing to begin with?

Re:productize?

[cshark]

I hope this one gets modded up. Great Oz, genius!

Re:productize?

[CarpetShark]

So essentially Kaminsky's vision comes down to: "Programmer's won't fix their code to prevent SQL injection errors. So my code will prevent SQL injections as long as developers fix their code to use my product"?

It may seem biased towards Kaminsky's own code now, but remember this is only the initial, very limited release. Kaminsky has promised that, in version 2.0, he'll be providing patent licenses so that ANY secure code can be legal.

Re:productize?

[CarpetShark]

whether we can get out of this silly zero sum game where the harder software is to write, the more secure it is.

The game is that business types want code on the cheap, and developers are afraid to say no, because their livelihoods are on the line. The game is capitalism, and developers don't make good capitalist players.

Re:productize?

[toxonix]

You've written a Java version? By subclassing strings do you mean actually subclassing java.lang.String? (you can't do that) As for interpolation, see Clojure. I think the main problem I'm having is that your language is extremely vague. Is there really something here you are trying to commercialize or are you shooting for another pwnie award?
It would help your credibility a great deal if you would be more specific about your subjects. Provide extremely detailed use cases as if Nobody Knows what you're talking about.

Re:productize?

[zuperduperman]

I really think interpolation is the right way for a programmer to express intent, and the compiler should be smart enough to extract it

There are already languages that do this rather well. It is one of my favorite parts about how Groovy handles SQL. The developer simply writes:

db.execute("select foo from bar where id = $id")

and the language is smart enough to extract that out and bind it correctly to the local "id" variable, with correct escaping, etc. Groovy makes it significantly harder to inject data into a string unsafely than safely.

Re:productize?

[geekmux]

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

Yes, you are right. General marketing bullshit is a turn-off and tends to turn most away. My entire point of knowing Dan or the way he tends to make light of the seriousness of business and marketing in general is he's the kind of guy who would use bullshit "marketriod" terms on purpose to poke fun at marketeers who talk this way and truly don't have a fucking clue what they're talking about.

Of course, with a handle like yours, I'm surprised that you and Dan aren't the ones on a first-name basis here.

Re:productize?

[Effugas]

[This is Dan]

Basically, I create a wrapper class, that's really just a String inside. But when I test the types for each argument of the vararg wrapper, I can see whether the passed string is a SafeString or a bare (thus unsafe) string.

It occurs to me I didn't release this implementation; I'll get it out there.

I actually put some more demos and test kits on recursion.com, and the slides aren't bad. I really want this to get bashed on.

Re:productize?

[Effugas]

[This is Dan]

Heh, can you find me a cite that shows that Groovy is actually extracting the SQL grammar and reassembling it safely? If so that is awesome and I want to cite that.

Re:productize?

[mvdwege]

WTF? I didn't say anything about legality. My remark was more to point that this is once again a technical solution to a social problem, which, as you know, does not work.

Mart

Re:productize?

[mvdwege]

The problem I see is that your proposed solution costs as much developer effort as just writing injection-resistant code in the first place. So you assuming you can effect a behavioural change where years of education hasn't worked to effect such a change before.

I'm sceptical. I think it's a stereotypical technical solution to a social problem.

Mart

Re:productize?

[SCHecklerX]

Basically.

I kindof like just using tools that actually don't let it happen in the first place. Embedded perl, for example. You have to really go out of your way to write insecure code with that particular tool.

Re:productize?

[abiggerhammer]

Strong typing across languages is the difficult part, particularly with string interpolation. Interpolique is aiming to preserve a form of strong typing (where there are two types, "safe" and "unsafe") across the inter-language boundary.

Re:productize?

[toxonix]

OK, I see. I'd like to see where this is wired in and how it would effect everyday development. Bashing is good.

Re:productize?

[godefroi]

The array of tokens to substitute should be an optional argument to mysql_query()....

I think what you actually meant was that PHP needs to eliminate mysql_query() NOW. Or, better, 5 years ago.

Re:productize?

[dgatwood]

No, I don't. That would break compatibility with existing PHP-based tools, many of which already do perform adequate sanitization of queries on their own. Case in point, SQL queries into a database using exclusively numeric keys can be sanitized like this:

$id = (int)$id;

Forcing people that don't pass arbitrary user-generated data to use a different function is unnecessary and pointless; they'll just pass the exact same argument(s) they do now, but add an empty array.

Adding another optional parameter to this function would break nothing, and would provide precisely the same benefits.

If you really want people to look at their code, you could make PHP throw a warning when no array parameter is passed in, and make it possible to disable that warning site-wide so it doesn't break things. That would have the advantage of pushing developers to look at their code without breaking backwards compatibility unnecessarily. It would also have the advantage of providing a nice audit log of the offending functions in error logs so sysadmins can audit suspicious code themselves.

Re:productize?

[godefroi]

I agree, we must maintain backwards compatibility with the SQL injection vulnerabilities.

Re:productize?

[dgatwood]

Not all code written that way is vulnerable to injection vulnerabilities. In fact, I suspect the vast majority of production code out there already properly quotes strings by now. So you're asking the PHP team to break every piece of PHP software that uses MySQL just because a small percentage uses a function in an unsafe way? That hardly makes sense. You might as well declare fgets off-limits because a few pieces of code pass the wrong length parameter.

The purpose of providing substitution-style SQL queries is to make it easier for new code to do the right thing. The purpose is not to force code to do the right thing, and in fact, it's impossible to force code to do the right thing unless you disallow string literals in SQL query strings entirely (which would be pretty insane). Thus, even if you broke everybody's code and replaced it with a new parameterized query function, almost everyone who was too lazy to build the query correctly in the first place will still be too lazy to rewrite their code to fix it the right way, so vulnerable code will *still* be vulnerable even if you remove mysql_query entirely.

Removing mysql_query query would break backwards compatibility with *good* code and would do *nothing* to get rid of bad code. It's not the right fix.

Parameterized SQL

[ultranova]

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

[Anonymous Coward]

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

[MichaelSmith]

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.

Re:Parameterized SQL

[erroneus]

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

[AlexiaDeath]

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

[buchner.johannes]

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

Re:Parameterized SQL

[what about]

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

[MichaelSmith]

Yeah but portable.

Re:Parameterized SQL

[WrongSizeGlass]

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

[Splab]

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

Re:Parameterized SQL

[Nerdfest]

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

[Webz]

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

[StormReaver]

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

[Shados]

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

[RogueCode]

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

[will_die]

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

[Xest]

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

[Splab]

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

[erroneus]

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

[A nonymous Coward]

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

[TheSpoom]

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

Re:Parameterized SQL

[Charliemopps]

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

[Alex Belits]

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

[larry bagina]

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

[AlexiaDeath]

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

[RogueCode]

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

[insertwackynamehere]

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

[Keebler71]

obligatory

Re:Parameterized SQL

[Lunix Nutcase]

I can't even think of writing code without checks for every condition imaginable

So you're the idiot who writes code the 500 if else branches and 10 page long switch statements?

Re:Parameterized SQL

[tepples]

The operating system, sure, but there are tons of open source apps written for those systems.

That doesn't help if the attacker uses a defect in the non-free operating system component on which your free application is running to compromise your free application.

Re:Parameterized SQL

[tepples]

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

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

Few SQL client libraries support passing a 1-column table as a parameter, yet that's exactly what you need to do when using SQL's operator IN . So instead, I made a function that escapes such 1-column tables using the quoting rules of SQL, and I tested it thoroughly.

Re:Parameterized SQL

[tepples]

And you are fool enough to get table and column and all sorts of schema names from user input?

You appear to claim that database administration tools such as phpMyAdmin, whose whole purpose is to build ALTER TABLE statements from user input, are developed by fools.

Re:Parameterized SQL

[kalirion]

How about this:

CREATE PROCEDURE pleaseFireMe ( @injection varchar(1000) )
AS
        EXEC(injection)

Re:Parameterized SQL

[sco08y]

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.

I've never seen a complex GUI that could come back to the same state it was in when you pulled the plug on it. Nor have I ever seen a complex GUI that could run for years without having to be restarted. To my knowledge, every major operating system has a function to force kill a hung GUI.

SQL (or any system that tries to be as expressive as the relational model) isn't so important for queries as it is for declarative integrity.

If you don't have declarative integrity, you can't centralize your integrity checks. Then you wind up having to reimplement integrity checks through every application.

The typical enterprise scenario is that you have a live data source and when business rules change your schema has to change to reflect that, so you need to be able to update your integrity checks. It's virtually impossible to update live applications simultaneously to honor new integrity checks and guarantee the state of the data store. That's even if you limit yourself to using only thin-clients.

If your integrity checks are centralized in the DBMS, you can have an outdated or buggy client that doesn't know about a new check and it will simply fail with an error message rather than corrupting the state of the database. When your live data represents actual property, this is a major requirement.

Re:Parameterized SQL

[ssbssb]

Correct. If you are building dynamic SQL as a string within a stored proc, simple parameters aren't enough.

This kind of code is common when you need to build a dynamic where, select or order by clauses. Normally you would build this where clause in code and then, yes, use parameters. But some code shops insist that all SQL be in sprocs and ban inline sql. When you parametrize it, you only escape the first level. If you use that value in the dynamic sql string, it will again be treated as literal.

Now before you jump in and say "well thats a stupid way to do it! Stupid code is stupid." ask anyone who has worked in a MS SQL shop or supported 3rd party apps that use MS SQL. Even the built in system sprocs use this kind of dynamic processing. The poster's Buchner's comment was only to show that just using parameters isn't always enough.

Here is some code I wrote to prove it and tested in ms sql:

--these two lines simulate what a parametrize query would do
declare @firstname as varchar(30)
set @firstname='test''' --note the escaped single quote

declare @sqlQuery as varchar(2000)

set @sqlQuery='select * from Employee where '

if (@firstname is not null) begin
set @sqlQuery = @sqlQuery + ' Firstname=''' + @firstname + ''''
end

print @sqlQuery

exec(@sqlQuery)

Re:Parameterized SQL

[kabloom]

So who was peer-reviewing that Debian OpenSSL bug such that it existed for 2 years?

Who found it? A Debian developer doing peer review.

Re:Parameterized SQL

[Just Some Guy]

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's easy enough to straighten out, though. At my current job, committing non-parameterized SQL strings into production is a firing offense and everyone is told that from the beginning. It's right up there with "don't stab the boss" and "don't smoke crack at your desk".

I laugh here, but it really is that serious. There's not a single legitimate reason for ever using anything other than parameterized queries. They're easier to write ("How many quotes do I need to put here?"), easier to maintain (because you don't ever have to mix SQL and code), always as fast as constructed queries and usually faster, and generally superior in every single way.

Re:Parameterized SQL

[tepples]

If you need string concatenation based on user input, you're doing it wrong.

How do I "do it right" if I want the right side of operator IN to be based on user input, the number of lines in which will vary?

Re:Parameterized SQL

[Splab]

Good point, I always think of it as escaping - bad muju from my days of PHP :)

Still wondering what database he is using, mine won't accept parameters in other places than where a field expression goes.

Re:Parameterized SQL

[ultranova]

Few SQL client libraries support passing a 1-column table as a parameter, yet that's exactly what you need to do when using SQL's operator IN . So instead, I made a function that escapes such 1-column tables using the quoting rules of SQL, and I tested it thoroughly.

Don't do that. Construct the parameterized query dynamically (that is, insert as many "?," as needed), then bind the parameters.

I've run into the same problem and it really is a serious deficiency in client libs, but it's not a reason to use manual quoting.

Re:Parameterized SQL

[Effugas]

Because they're much harder to work with. If they weren't, we wouldn't have to beg developers to use them.

Re:Parameterized SQL

[tepples]

Construct the parameterized query dynamically (that is, insert as many "?," as needed), then bind the parameters.

Unless the client library makes binding a variable number of parameters a pain in the ass *cough*MySQLi and call_user_func_array() and arrays of references*. I wish it were as easy as Python's DB API.

Re:Parameterized SQL

[luis_a_espinal]

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.

Are you that naive to think everything can/should be modeled according to the OO paradigm?

Furthermore, what happen when you have terabytes of relational data? Are you going to rewrite it all into a OODB just so that we can execute OO-based queries on them?

Re:Parameterized SQL

[luis_a_espinal]

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.

Except for the very extreme edge cases that need them, what sort of a deviant, over-engineering architectural astronaut code monkey designs a system with pass table names in the general type of web-facing systems?

Assuming one really needs to pass table names, I doubt they would be passed directly as parameters (but instead be computed from them through internal means not derived from their string representations.) And if we really want to push the envelop and indeed want to somehow expose table names that way, just wrap the hole thing in a stored procedure that constructs the SQL statement internally after successful validation and sanitation of parameters (which should be happening no matter what).

All that complexity to protect against attacks to a feature (passing a table name as a parameter) that no sane developer would ever expose in a web-facing system. Oh boy.

One thing for certain is that even when using prepared statements, one still has to validate and sanitize all parameters. More importantly, one has to structure code so as to be able to spot security issues during code inspections (which should also occur no matter what.) Joel Spolsky wrote something to that effect a while ago. People should read that and learn how to code properly rather than trying to find silver clutches : http://www.joelonsoftware.com/articles/Wrong.html

Re:Parameterized SQL

[petermgreen]

Admin tools are a special case. Why bother with injection attacks when one click will get you a box to type in and run whatever sql you like!

Don't give someone access to phpmyadmin if you wouldn't give them direct access to the database server!

Re:Parameterized SQL

[Lunix Nutcase]

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.

That's incredibly retarded. How anyone would hire someone as dumb as you to code their business critical applications is beyond me. What you're talking about is what a simple regex accomplishes without a bunch of bloated conditionals.

Re:Parameterized SQL

[Lunix Nutcase]

2 years after the fact. That's hardly equivalent to the claimed peer review that "happens all the time".

Re:Parameterized SQL

[Lunix Nutcase]

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.

Yeah, it's incredibly funny how the guy who was trying to talk down on other's for low quality code is someone who doesn't even understand the basics of using a regex to find invalid characters in a string but would instead create a huge spaghetti mess of if/else statements.

Re:Parameterized SQL

[Blakey Rat]

The simple fact is:

1) Any developer who cares about security is already following best-practices and doesn't need this tool
2) Any developers who doesn't care about security will never seek out a tool like this

Seems like a waste of time to me.

Re:Parameterized SQL

[tepples]

Don't give someone access to phpmyadmin if you wouldn't give them direct access to the database server!

I understand that. It's just that 1. I have this compulsion to find absolutes (such as "never") and correct them, and 2. as a web app developer, I spend a lot of time in phpMyAdmin getting a query perfect.

Re:Parameterized SQL

[nut]

You should get out there and start looking for a new job. Brush up your CV and start shopping it around.

You've just spent 3 or more years in the same job, so you're reliable. You've developed a system that the the whole department adopted so you come up with useful creative solutions. You used existing resources off the web - you work smart and don't reinvent the wheel.

Put that stuff on your CV. You can explain the issues you have with the work in the interview if you like, and blame it on time and resource pressure (don't blame it on management stupidity in a job interview.)

The best time to look for a job is when you've already got one, even if the market isn't that great right now. You're looking for a new job because you want to advance your career and your current job isn't giving you that opportunity.

And it definitely sounds like you're not enjoying the current one that much. Take action.

Re:Parameterized SQL

[erroneus]

Who cares about "the best way"? My point to illustrate was the difference between testing one by one and using a loop of some sort to perform the operation. And for your information, what the hell do you think a "regex" does!? Do you think it doesn't perform looping internally? Take it from an assembly programmer -- All computers do is ADD and SHIFT. What is done with those basic functions is added complexity to represent something more abstract. The point is that whatever code that is created, it should be as bullet proof as possible. SQL injection should be impossible.

And insulting someone like that? Not a a good move on your part. You are not as anonymous as you think you are.

Re:Parameterized SQL

[Lunix Nutcase]

Who cares about "the best way"?

Pretty much anyone but an incompetent programmer like you?

My point to illustrate was the difference between testing one by one and using a loop of some sort to perform the operation.

And it's a retarded way to do it.

And for your information, what the hell do you think a "regex" does!? Do you think it doesn't perform looping internally?

I never said anything of the sort. But your statement was a piss poor reimplementation of a regex.

Take it from an assembly programmer -- All computers do is ADD and SHIFT.

Pfft, assembly? Come back to me when you've programmed purely in hex.

What is done with those basic functions is added complexity to represent something more abstract. The point is that whatever code that is created, it should be as bullet proof as possible. SQL injection should be impossible.

Yes, but doing a bunch of stupid checks for all the bad things that can happen is precisely the wrong thing to do as was pointed out above because you can not remotely think of any and all bad cases. That's why you validate against what you know is good input and thus you don't have a bloated mess like your solution.

And insulting someone like that? Not a a good move on your part. You are not as anonymous as you think you are.

Oh noes! An e-thug is gonna come get me! I'm wetting my pants as we speak!

Re:Parameterized SQL

[erroneus]

Odd how I speak of CULTURE not the specific details of a thing. The culture of Mac OS X programming isn't about sharing code. It's just not. And neither is the culture of Windows programming. In both examples, the primary motive for coding in those environments is for profit. The culture of Linux and BSD are quite different as the motives of the participants are quite different. And it hardly requires mentioning that there is OSS for Windows and Mac OS X and that there is commercial closed source software for Linux. It's the over-all culture of the things, not the nit-picky-items themselves. Do people REALLY have to explain these things to you?

Re:Parameterized SQL

[azrider]

as a web app developer, I spend a lot of time in phpMyAdmin getting a query perfect.

And if you do that on a production database, you deserve to be:

• Drawn and quartered.
• Taken out back and shot.
• Skinned alive. (repeat as necessary)
• Stretched on a rack.
• Hung by the neck until dead.
• Buried alive.

Repeatedly.

If anybody has other suggestions (as painful as the imagination will allow), please feel free to add them.

Re:Parameterized SQL

[erroneus]

got trolled again... when will I ever learn? I should have read your posting history. Turns out you can't say anything positive and are obsessively critical about everything anyone says. You offer no new ideas of your own -- just attempting to tear others down. It's clear for all to see. It's a real personality disorder. You should get that checked.

Validating input against all possible bad conditions is simply not a bad idea. Check for over and under size. Check for bad characters. And that's just for starters. Check to see if the record you are about to write has been changed before you write your changes back out in a multi-user environment. There's a world of problems out there waiting to happen if your software isn't capable of handling the variables in the environment you are programming for. And seriously, if someone enters a value that is supposed to be an hour, I will not let someone put 25 in the field. It's bad to let bad data slip through. Once bad data is filtered out, you just eliminated the biggest part of what could go wrong.

Arguing "bloat" while programming in high level languages is pretty ironic though don't you think? I could likely do more in 1K of memory and machine language than can be done in 32k of compiled C.

Seriously, though. You have a personality problem. Get it looked at. It seems to affect the way you see the world a great deal and keeps you pretty dissatisfied with yourself.

Re:Parameterized SQL

[nxtw]

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.

This is not what I've seen using .NET and Java. Is such poor practice limited to PHP/MySQL?

Re:Parameterized SQL

[lonecrow]

I don't think the platform bears any responsibility for the ratio of good to bad programmers. Before PHP there were plenty of insecure ASP and ColdFusion website, PHP has become pretty popular and as a result has attracted lots of developers at at least its fair share of bad programmers.

I especially don't think that PHP enjoys a higher ratio of good to bad programmers because it primarily runs on linux. The OS has no impact on sql injection or xss. In fact php may have a higher ratio of bad programmer because of the larger number of free or next to free LAMP hosting services. This lower barrier to entry makes it easier for novices try their hand at programming with the expected result.

Re:Parameterized SQL

[Effugas]

[This is Dan]

So, if they're so great, why does the boss have to put a gun to people's head?

Re:Parameterized SQL

[ultranova]

Yes, my idea is a workaround to defective API, and there really should be some way to bind a list of items - or append an itme to the list of already bound ones - to a single parameter placeholder. But even so, being completely immune to SQL injection once and for all is very nice.

Re:Parameterized SQL

[Just Some Guy]

What does this have to do with computer science? It's more of a software engineering issue.

Re:Parameterized SQL

[Just Some Guy]

So, if they're so great, why does the boss have to put a gun to people's head?

[This is Kirk :-) ]

I have no idea. Maybe I learned this stuff back before the misteaching was as widespread, or maybe it was because performance with MySQL was so miserable at the time unless you prepared your queries first (which required them to be parameterized), or because my boss threatening to choke me unless I did it that way, or just that I was lucky enough to have read a paper on SQL injection and get scared straight early in my career. I really don't remember. At any rate, I don't know what factors led me to doing things the right way instead of the (temporarily) easy way, or why they haven't been similarly affected other programmers.

Unlike some other posters, I don't think your idea's inherently bad. I just don't think it'll be used. People who care enough about their data and understand the security implications of creating ad-hoc query strings will have been using parameterized queries or ORMs already. People who don't know or don't care aren't likely to see your way of doing things - even if it was clearly superior and brilliant and obviously correct - and adopt it.

Re:Parameterized SQL

[Lunix Nutcase]

Except that OS X is very much about sharing code. Only if you ignore the vast amounts of contribution back to open source projects by Apple and it's employees can you make such a ridiculous statement.

Re:Parameterized SQL

[abiggerhammer]

No, no, no, no, NO. DO NOT use regular expressions to validate context-free languages. The only way to validate SQL using regular expressions is to use Perl-style regular expressions with backreferences, and those are actually pushdown automata. They're also next to impossible to read.

I'll toot my own horn and point out that context-free validation can be done sanely ... though it would be easier for everyone else if I actually had the time to keep up with releases. Dan's asked me to port that project to MySQL, which I'm actually working on right now along with cleaning up some of the dumber design decisions I made five years ago.

Re:Parameterized SQL

[godefroi]

PHP has historically encouraged the ad-hoc generate-your-queries-on-the-fly-and-embed-your-parameters-as-literals behavior. Java and .NET have never prevented or punished this behavior, but from my own experience it has definitely been less pronounced.

Re:Parameterized SQL

[Just Some Guy]

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.

My only problem with your approach is that I'd use a whitelist instead. For example, in Python I'd write something like:

if [char for char in inputstring if char not in allowedchars]: print 'Found bad data!'

My company used to play whack-a-mole with input validation. "Oh! What's the code for \u? Add that to the list!" I've gradually brought the other programmers around to the idea of specifying what we can accept and rejecting everything else.

Re:Parameterized SQL

[Just Some Guy]

Thank you for that. It's easy to slag off on people for making dumb design decisions, and sometimes we need reminders of how intelligent people can come up with some pretty awful ideas when working outside their expertise. If my boss ordered me to build a bridge, and we eventually came to depend on it, a civil engineer would probably want to shoot me when he saw the results.

Re:Parameterized SQL

[insertwackynamehere]

I wasn't referring to SQL, I was referring to the abrrsct example provided by the parent of my OP

Re:Parameterized SQL

[abiggerhammer]

Okay, fair enough - but the statement still holds. If the language you are trying to validate is context-free or stronger, do not use a regex to try to validate it.

Fans of functional programming

[Anonymous Coward]

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()

[bcmm]

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

Re:mysql_real_escape_string()

[nacturation]

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()

[hazah]

Thank god that function names are not case sensitive... Or is this not PHP??? Shit!

Semi-technical paper

[will_die]

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.

Re:How is it different from what other frameworks

[Anonymous Coward]

how is it ground breaking ?

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

Been there, done that.

[Greger47]

I can see it now, it's PHP Magic Quotes all over again.

/greger

Re:Been there, done that.

[dirtyhippie]

Nah. If you RTFA, you'll see it's much more like perl's taint mode.

Re:"Kaminsky"

[geekmux]

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.

Great...

[AlexiaDeath]

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

[Civil_Disobedient]

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 (or NHibernate 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.)

Well

[buchner.johannes]

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

[nacturation]

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

[buchner.johannes]

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

[ais523]

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:Well

[jdoverholt]

Maybe I've misunderstood all these years but Hungarian notation always been intentionally redundant--just there to make it easier to understand code at a glance without having to read three pages up or depending on an IDE's hints.

Re:Well

[kabloom]

Hungarian notation in this case would add semantic value that's not already captured by the type checker, but maybe we should just modify the type system to cover the safety of strings.

As another objection, isn't forcing the programmer to use Hungarian notation for safety a more complicated option than just using parameter binding correctly in pretty much any language/framework that uses varargs for this purpose (Java/JDBC is the notable exception). Don't object-relational mapping systems in many frameworks also provide these benefits for much less effort?

Re:Well

[Tacvek]

hungarian notation is best used not to store actual datatype of the variable, but additional information beyond the raw datatype. So "strTitle" is worthless in a statically typed language, and at best questionable in a dynamically type language.

But "uTitle" to indicate an unsafe (unescped) title and "sTitle" to indicate an title that is safe (has been escaped) is a coding convention that makes plenty of sense. It is very possible to then automatically scan code to find violations of safety, such as any assignment of the form "sFirstName=uFirstName".

Extend the convention to functions, and one can automatically detect the problem with "sAddress=uGetAddress", or passing "sLastName" to a function with the prototype "int HashString(std::string uString)", which clearly wants an unescaped string.

One can also detect other unsafe or undesirable actions like escaping an already escaped string, or concatenating a safe and an unsafe string, etc.

Now when Charles Simonyi described the system initially he had not yet made the full distinction between type information the compiler already knows, and additional type information. Many, but not quite all of his examples in the original paper gave additional information. His lack of a full distinction is what led to many of the uses where Hungarian notation is not giving anybody any useful information.

Of course the best way to handle the whole thing is to have each semantic data-type be a distinct data-type to the compiler. So I would have both an "UnsafeString" and a "SafeString" data-type, and doing something unsafe like assigning one to the other directly would result in a compiler error. For dynamic languages, having a compile-time error is not feasible, but having two data-types and having unsafe operations result in a run-time error is still possible, and should be preferable to a successful injection attack.

Re:Well

[lewiscr]

Perl's Taint Mode already supports this.

It generates runtime errors if you attempt to use a Tainted data. Data is never untainted, but untainted data can be generated by a regular expression match.

Perl takes special precautions called taint checks to prevent both obvious and subtle traps. Some of these checks are reasonably simple, such as verifying that path directories aren't writable by others; careful programmers have always used checks like these. Other checks, however, are best supported by the language itself, and it is these checks especially that contribute to making a set-id Perl program more secure than the corresponding C program.

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(), the variable of shmread(), the messages returned by msgrcv(), the password, gcos and shell fields returned by the getpwxxx() calls), 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...

...

Because taintedness is associated with each scalar value, some elements of an array or hash can be tainted and others not. The keys of a hash are never tainted.

...

Sometimes you have just to clear your data's taintedness. Values may be untainted by using them as keys in a hash; otherwise the only way to bypass the tainting mechanism is by referencing subpatterns from a regular expression match. Perl presumes that if you reference a substring using $1, $2, etc., that you knew what you were doing when you wrote the pattern. That means using a bit of thought--don't just blindly untaint anything, or you defeat the entire mechanism.

There are plenty of examples behind the link.

Re:Well

[Effugas]

[This is Dan]

This isn't taint mode. Taint mode is single language, and in the field, is just turned off without any checking being applied. I don't know of many other efforts that really address the problem that we use strings to communicate across languages, and when we do, we lose all type safety.

There are tricks like LINQ, which allow you to basically express one language with the syntax of another, and I like them lots. (Actually, I think they don't get enough credit for their security implications!).

Re:Well

[maxwell demon]

Hungarian notation to denote the type (like int, pointer, etc) is common, but it's doing it wrong. Correct application of hungarian notation doesn't use type prefixed, but meaning prefixes. For example, imagine a windowing system, where you can have coordinates relative to the window, and relative to the screen. In that case you could e.g. use the prefix w for window-relative coordinates, and s for screen-relative coordinates. Of course both types of coordinates are just pairs of ints, but if you see e.g. sMousePointer, you immediately know that it contains the mouse pointer in screen coordinates, not in window coordinates (which you couldn't see from the type, because both are just coordinates). Also, if you have a statement like

if (sMousePointer.x > wxmin && sMousePointer.y wxmax)

you know immediately that there's something wrong. Without the prefixes, you'd have to look at the logic to spot this problem, because all values are of type int.

Now you could of course make separate types for screen-relative and window-relative coordinates, and also for screen-relative x coordinate, screen-relative y coordinate, window-relative x coordinate and window-relative y coordinate, but at some point 90% of your code would consist of type definitions which all just wrap some simple type.

Now I can imagine some mechanism which would allow you to define such types easy enough to make such a system practical, but I don't think it would work well in any existing language.

Re:Well

[Hognoxious]

Correct application of hungarian notation doesn't use type prefixed, but meaning prefixes.

If you're doing types properly, they should map closely to meanings. If I have two types that are wrappers round a float, and one means a weight and one means a length it shouldn't be valid to add them together.

(For non-Americans, the same principle should apply if they wrap a float and the associated unit too.)

Re:Well

[maxwell demon]

As I said, in a language designed for it, you'd easily create and use arbitrary many fine-grained types. However, I don't know a real language where it's easy enough to write new types to make this feasible. For the specific case there are already C++ libraries, therefore it's easy to use them. However, look at boost::units to see the complexity you need to support reasonable flexibility, and ask yourself if you would be willing to write something like that for your project if not some kind soul had already done it for you. And even that solution can go only so far. For example, for processes you have several different times: Wall time, user time and system time. It doesn't make sense to add user or system time to wall time, so you make them different types, right? But it does make sense to subtract them, to find out how much real time was taken away by other processes or interrupts. So you add another type for that difference. I don't think this scenario is supported by boost::units, so you have to write all that stuff yourself.

And then, there's the situation where you have nice matrices and vectors with units, and then you want to pass them to some linear algebra routines. But those routines don't know the unit types. So now you have do to tricks to get your great dimensional units into the pure numerical linear algebra package (you probably don't want to rewrite the linear algebra package).

OK, so a few days before deadline, your boss asks you how far you got with your project, and you tell him "I'm almost finished with the unit types to be used by the code." I don't think your boss will be pleased to hear that. :-)

Re:Well

[abiggerhammer]

However, I don't know a real language where it's easy enough to write new types to make this feasible.

Ada, but it's unlikely you'll be using Ada unless you're working for DoD or something.

Reference?

[BerntB]

Linky linky?

Another crutch

[Mag7]

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

[Anonymous Coward]

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

[gorzek]

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.

Re:Another crutch

[b4dc0d3r]

They keep getting rid of the smart people by pay cuts or salary freezes. The smart people jump ship, and the people who write functional but terrible code get kept. If you want someone who knows what they are doing, you have to pay, and that increases costs.

Re:Another crutch

[gorzek]

Yup. The good programmers also get sick of shouldering the load--fixing the crappy code written by their incompetent coworkers.

I've known too many good developers who got penalized because they spent all their time cleaning up other people's messes, missing their own deadlines, because they cared about having a quality product. At review time, they'd get chastised, get no raises or bonuses, and eventually they'd split. I can't say I blame them, either.

Re:Another crutch

[imunfair]

As much as I like good code, people like that are not doing their job. Clean up code as much as you have time for while doing your own job, but when you start missing deadlines you visibly cost the company money. Best course of action would be to note down dirty code for after release so that your manager can give you time to write a patch for important issues.

Like it says in this entertaining article:
http://www.joelonsoftware.com/items/2009/09/23.html

"Shipping is a feature"

Re:Another crutch

[DreadPirateShawn]

Yes and no. Bear in mind there's a difference between "dirty" code with bad indentation or inconsistent bracket styles, versus "dirty" code which doesn't follow best practices in actual code design. The former can be tolerated (albeit reluctantly), while the latter poses a real threat.

Often dirty code won't clearly demonstrate the problems it causes -- in which case noting the dirty code and moving on may save an hour up front, but can easily cost half a day once you stumble onto one of its side-effects and follow the breadcrumbs back to the source. Or after the dirty code is copied / inherited / extended into more locations, and fixing the same code now includes exponentially more use-case scenarios.

It's easy to paint the good devs as being "too" anal-retentive, "too" focused on clean code... yet this obsession leads to far more maintainable code, and to "version 2.0" releases going orders of magnitude more smoothly. Not to mention avoiding the loss of time every time the production code tips over, or the customer rants about bugs in the market and devs are forced to investigate, causing unscheduled time impact. But even when fixing dirty code takes days, and fixing comparable clean code takes minutes or hours, the payoff is often dismissed because the time was saved after the initial release date, and the client's money is no longer on the line.

In the best of worlds, the good devs are able to fix the code behind the scenes as much as possible, knowing that one evening of working in front of the TV tonight, can guard against multiple stressful days of cleaning up a mess later, losing time on their own schedule in the process. For better or for worse, "good developers" are considered "good" for a reason.

Re:Another crutch

[godefroi]

Yeah, 'cause that's worked so far, amirite?

Re:"Kaminsky"

[MortenMW]

Why would a code-monkey write erotic novels?

This is advertisement, not a story

[hubert.lepicki]

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

[Rogerborg]

This is advertisement, not a story

What part of "kdawson" is confusing you?

Re:This is advertisement, not a story

[setrops]

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

[TubeSteak]

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

[Dunbal]

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.

Re:This is advertisement, not a story

[nuckfuts]

It doesn't say anything about how this actually works and how it differs from existing solutions.

Are you sure you actually read the article?

How is it different?

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.

How does it work?

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

Not an in-depth explanation, but hardly a case of "doesn't say anything". It works by drawing a line between what is data and what is code. Crossing that line is a common way for bad guys break into systems.

Re:This is advertisement, not a story

[nxtw]

If this problem has been fixed "since, like, for ever (2001?)" then why the hell does it still keep happening even in, like, 2010?

Ignorance and poor tools.

Java has had parameterized prepared statements since 1997 when the JDBC API was released as part of Java 1.1, for example.
And that same API applies to any database with a JDBC driver.

PHP, on the other hand, didn't even get a standard database abstraction layer until 2005 with the release of PHP 5.1 - way too late.

this is just taint mode

[dirtyhippie]

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.

Re:this is just taint mode

[dirtyhippie]

It also looks like an implementation of what Joel Spolsky recommended a while back (search for the stuff about hungarian notation):
    http://www.joelonsoftware.com/articles/Wrong.html

Re:this is just taint mode

[hey]

Perl leads the way!

Re:this is just taint mode

[John Hasler]

> 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

[Max_W]

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

[ledow]

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

Re:"Kaminsky"

[Hognoxious]

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.

There is no silver bullet

[Gopal.V]

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

Comment removed

[account_deleted]

Comment removed based on user account deletion

code review

[John_Sauter]

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:code review

[140Mandak262Jamuna]

So you were working on DEC. I have been waiting to ask this question to some DEC for long long time. The default behavior in DEC for any violation seems to be to crash the executable, without warning, without stack trace, nothing. Have to laboriously insert debug/print statements and find the location of the crash. It was a nightmare of a platform to work with. We were basically using DEC as our hardware bounds checker. If it runs on DEC, you don't have to run bounds checker, purify etc. But very painful to develop in that platform.

Re:code review

[John_Sauter]

So you were working on DEC. I have been waiting to ask this question to some DEC for long long time. The default behavior in DEC for any violation seems to be to crash the executable, without warning, without stack trace, nothing. Have to laboriously insert debug/print statements and find the location of the crash. It was a nightmare of a platform to work with. We were basically using DEC as our hardware bounds checker. If it runs on DEC, you don't have to run bounds checker, purify etc. But very painful to develop in that platform.

The behavior depends on the platform. My experience was with the PDP-10 and VAX systems. The PDP-10-based machines generally were very good for debugging, since the early software was written in assembler. There was no stack trace, since stack handling was an application convention, but there was a good debugger.

On the VAX systems the assembler-level debugger was not as good, probably because we were developing in a high-level (for the time) language by then. Exception handling was much better, though. An access violation got you a good message.

Were you using a PDP-8 or PDP-11 system? They were relatively primitive compared to the PDP-10 and the VAX.

I was told that people used the VAX Ada compiler, even when they did not intend to run the application on the VAX, because its compile-time diagnostics were so good. If I remember correctly, when it reported an error it described what was wrong in great detail, including quoting from the Ada standard by chapter and verse.

Re:code review

[140Mandak262Jamuna]

Belated thanks for the response.

Wow....almost a concept

[hesaigo999ca]

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

Re:"Kaminsky"

[laughingcoyote]

But if they write marketese (like, you know, "productize"), fuck 'em.

I rememeber the good ole' days...

[Lisandro]

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

mysqli_stmt_bind_param()

[tepples]

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?

Re:mysqli_stmt_bind_param()

[Joe Mucchiello]

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?

call_user_func_array() You just have to make sure the parameter array contains references to variables since mysqli_bind_param() (mysqli_stmt_bind_param is deprecated, use mysqli_bind_param instead) expects the parameters to be passed by reference.

$A = Array($mysqli_stmt_handle, 'is', &$int_value, &$str_value);
$ret = call_user_func_array('mysqli_bind_params', $A)

not all the time

[circletimessquare]

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 ;-(

Re:not all the time

[revlayle]

And that is allowing user input to write the query structure - tsk tsk tsk - *slaps hand* BAD SQL DEVELOPER!

Re:not all the time

[Shados]

sure you can. As long as you have a list of valid fields you check against, you can just create the query dynamically from the selected field, then parameterize the value.

However, that has a performance penalty: RDBMS will cache the query plan if the query is all the same except for parameters, so you're better off, performance wise, with a query that checks all the fields. If you do something like:

where (field1 = @foo AND @checkField1 = 1) OR (field2 = @foo AND @checkField2 = 1) OR ....

Most modern RDBMS will optimize all of the redundant conditions away extremely quickly, and the query plan can be cached

so educate me

[circletimessquare]

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?

Re:so educate me

[revlayle]

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.

Re:code review - PA-DSS required

[bearsinthesea]

PA-DSS (a PCI standard) requires code review by someone other than the original author, who has training in secure coding practices.

Recursive Ventures

[mrogers]

When I try to visit the site with cookies disabled, Firefox warns me that "the server is redirecting the request for this address in a way that will never complete".

Recursive Ventures indeed...

ah

[circletimessquare]

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

yup, a hardened dynamic query

[circletimessquare]

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

Our approach

[MagicMerlin]

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.

Re:Our approach

[butlerm]

Sounds like a great idea to me. Possible performance downside on a really busy system, of course.

In general there are a handful of queries that don't take parameters, so they would need to be whitelisted somehow, perhaps by table name. There are all sorts of other fun policies you could enforce, of course.

Re:Our approach

[MagicMerlin]

for the cases that you can't strictly do the query, we push the logic into a function call and dyna-sql it. (to hide the internals, it's actually mostly function calls over the low security interfaces). we also wrote a libpq wrapper to allow sending and receiving extremely complicated structures over libpq protocol efficiently. (here, if you're curious: http://libpqtypes.esilo.com/).

Re:Our approach

[butlerm]

Very nice.

Re:How is it different from what other frameworks

[youn]

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

SQL Injection

[Stooshie]

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.

Re:SQL Injection

[Stooshie]

the "" above should read &[hash]69;

Re:SQL Injection

[butlerm]

That works to prevent SQL statement injection, but is not adequate to prevent predicate (WHERE clause) modification, etc., which can be very serious:

DELETE FROM table WHERE x = 5 OR 1 = 1

for example.

Re:SQL Injection

[nxtw]

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.

This doesn't solve the problem (of generating query strings with data inline); it just prevents anything bad from happening. The correct solution is via prepared or parameterized statements, which do not rely on string replacements.

call_user_func_array()

[tepples]

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.

Recursive Ventures?

[Syberz]

So what, you pitch the same ideas over and over again until someone thinks its a good idea?

Re:Recursive Ventures?

[toxonix]

Wouldn't recursion imply that they pitch the idea to themselves until something comes of it?
When someone thinks this is a good idea, Recursive Ventures will dump its core, citing SIGSEGV.

The world will just build a better idiot

[ghmh]

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:

SomeComplicatedStoredProc int @aresonableargument, nvarchar(4000) @whereclause, nvarchar(4000) @orderby

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.

Just don't concatenate to form SQL strings n00b

[mcferguson]

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.

Re:I read your reply, only 2 "disagreements"

[ledow]

"They told me about the "why" of WHY 2 digit years were used (as well as assembly language): Space & Storage in RAM!"

Granted. It doesn't make them any less pillocks though, and I mean that in an endearing way. Of course they can't be expected to predict that in 40 years time their software would still be necessary, but equally whoever was responsible for that software should have updated it too - 40-year-old bugs should have been fixed approximately 39 years ago. Or failing that 38 years ago. Or failing that...

The original programmers weren't "wrong" here (damn right that at some points in computing history, every byte/cycle counted... back when computer menus consisted of "press 1 for invoicing, press 2 for stock control" and - dear God - bring back those days! How many people would actually do a BETTER, more efficient, less distracted, more secure job now if they were told to sit in front of one of those for 8 hours a day instead of a general-purpose OS with access to the Internet!), but the team responsible for such software (either the IT team still implementing it without checking, or programming team for failing to spot such things later on) are still pillocks. If it had been a security problem more than a simple capacity problem, that's still no excuse for not fixing it 40 years later when you *DO* have Gigabytes of storage. The blame is on the *current* programmer / maintainer / IT support team, though, not the original author.

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.

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.

A little close-minded are we?

[nuckfuts]

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

Re:A little close-minded are we?

[nuckfuts]

You didn't need to "say" FOSS, because your knee-jerk reaction to marketing terms spoke for you.

If anyone sounds "hopping mad", it's you. Are you so averse to any type of marketing that you turn your brain off the second your hear it?

Re:welcome to slashdot, we condemn fools

[geekmux]

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

Real nice logic you have there. I suppose we should condemn all those "fools" who write firewall or anti-virus software too, because God knows we haven't given web or OS developers enough time over the last couple of decades to create a solution that works without this additional protection, right?

And yeah, it's untested alpha software. That's kind of the whole point here of handing it over to the community to test it out on non-production environments, which he INSISTS on the website.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:"Kaminsky"

[kumma]

.. I forgot to log in. About these naming conventions and grammar nazis, well. Finish has these things called prepositions, which are used in quite similar way, and it is said that Finnish is one of the hardest language to learn because of those. Good luck with that Dan... And that kind of behavior is not a new invention. I have faint memories, that for example Symbian did use that kind of trick to interfere memory allocation behavior or smth. It's funny how in Symbian class's variables are always iSomething, and then *tudumtsah* iPhone.