Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

14 Years of SQL Injection and still the most dangerous vulnerability

mavitunasecurity.com

Post reply on HN
Print view View original

11–20 of 58 posts

Re: 14 Years of SQL Injection and still the most dangerous vulnerability

#11

Post by betterunix »

clarkevans wrote: post #3

When combining software components, you have to gateway between them -- this is done by escaping inputs and validating outputs. It's often non-trivial to grok where the junctures between components are, and how to properly connect them. This requires thought, experience, and diligence. Why it's so common is that you can easily connect components incorrectly, still have it "work" enough to do a demo, and, there is lot…

"this is done by escaping inputs"

Something about that sounds wrong. It is as though you are suggesting that we use in-band signaling with a bunch of notch filters to ensure that Cap'n Crunch whistles cannot be used to get free calls. The right answer is out-of-band signaling -- in other words, not constructing queries / command strings / etc. from user inputs.

Major SQL databases all support prepared statements; this seems like a far more robust approach than trying to sanitize inputs.

Re: 14 Years of SQL Injection and still the most dangerous vulnerability

#13

Post by ecopoesis »

16s wrote: post #7

Unrealistic deadlines and sales reps promising features to clients is a large part of the problem. Get the changes in, test the usability, and ship it. Get it out to the client pronto. We have an earnings report due by X date and this will help the bottom line. It's not that devs and DBAs don't care, it's that in many cases (not all) they aren't given the time to carefully test the system to see how it might be abuse…

How the hell do deadlines have anything to do with SQL injection? Writing

$stmt = $dbh->prepare("SELECT * FROM users WHERE USERNAME = $username AND PASSWORD = $password"); $stmt->execute();

vs

$stmt = $dbh->prepare("SELECT * FROM users WHERE USERNAME = ? AND PASSWORD = ?"); $stmt->execute(array($username, $password));

adds no time or effort. SQL Injection happens because devs haven't been taught to do the right thing or are too dumb to remember to do the right thing. Both conditions are easy to fix: teach the first group, fire the second.

Re: 14 Years of SQL Injection and still the most dangerous vulnerability

#14

Post by SigmundA »

Isn't this more about using strings to build executing code from untrusted input?

This kind of stuff always seems to surface when one language is embedded in another and this tends to be database query languages and one of the most popular is SQL, but it's not limited to it, just look at javascript injection from parsing JSON using eval.

I am not seeing injection going away until we stop sending bits of code between runtimes as strings, which will be hard to avoid so long as databases and applications use different languages. It's a lot of work to abstract one language into the other (See LINQ to SQL), where as string concatenation is understandably the easy way out.

Ideally we could all agree on a good binary data format(something like Go GOBs) and a AST structure to serialize to it then we would have the common building blocks to send dynamically built code between runtimes/languages without using strings.

Re: 14 Years of SQL Injection and still the most dangerous vulnerability

#15

Post by SigmundA »

Shish2k wrote: post #2

TL;DR: "Because you aren't using our snazzy new product; try it today!" Also: This is primarily because of the most obvious problem: We are still using relational SQL databases. Were we to use NoSQL database systems such as MongoDB or CouchDB, none of these attacks would ever happen Yeah, and motorbikes are safer than cars because the third and fourth wheels never fall off...

Make perfect sense, since there is no SQL in NoSQL its impossible to have a SQL injection, problem solved...

Re: 14 Years of SQL Injection and still the most dangerous vulnerability

#16

Post by untothebreach »

16s wrote: post #7

Unrealistic deadlines and sales reps promising features to clients is a large part of the problem. Get the changes in, test the usability, and ship it. Get it out to the client pronto. We have an earnings report due by X date and this will help the bottom line. It's not that devs and DBAs don't care, it's that in many cases (not all) they aren't given the time to carefully test the system to see how it might be abuse…

Deadlines are not an excuse for not doing basic pen/vuln/fuzz testing prior to a release. Even the most basic of tools can detect SQL injections.

Re: 14 Years of SQL Injection and still the most dangerous vulnerability

#17

Post by mikeash »

betterunix wrote: post #11
clarkevans wrote: post #3

When combining software components, you have to gateway between them -- this is done by escaping inputs and validating outputs. It's often non-trivial to grok where the junctures between components are, and how to properly connect them. This requires thought, experience, and diligence. Why it's so common is that you can easily connect components incorrectly, still have it "work" enough to do a demo, and, there is lot…

"this is done by escaping inputs" Something about that sounds wrong. It is as though you are suggesting that we use in-band signaling with a bunch of notch filters to ensure that Cap'n Crunch whistles cannot be used to get free calls. The right answer is out-of-band signaling -- in other words, not constructing queries / command strings / etc. from user inputs. Major SQL databases all support prepared statements; thi…

I think that comment is a succinct summary of why SQL injections are still common, anyway. The answer: because people think "escaping" is the answer.

Imagine constructing a function in some other language this way:

    function square(x) {
        code = x + "*" + x;
        return eval(code);
    }
This is obviously wrong. Now, let's say I suggest fixing it with escaping:

    function square(x) {
        code = escape(x) + "*" + escape(x);
        return eval(code);
    }
Any sane programming community would string me up by my thumbs for doing this, and rightly so.

Yet, do the exact same thing in SQL and it's just business as usual. Occasionally people talk about prepared statements and parameterized queries and such, but usually people just talk about escaping. As if the problem is just that you need more backslashes, not that you're glomming strings together at runtime and then calling eval() on them.

It's so bizarre. People would think you're crazy for doing it in one environment, but doing it in a different environment where the exact same problems are present is just fine! I can't fathom how we got to this place.

Re: 14 Years of SQL Injection and still the most dangerous vulnerability

#18

Post by 16s »

untothebreach wrote: post #16
16s wrote: post #7

Unrealistic deadlines and sales reps promising features to clients is a large part of the problem. Get the changes in, test the usability, and ship it. Get it out to the client pronto. We have an earnings report due by X date and this will help the bottom line. It's not that devs and DBAs don't care, it's that in many cases (not all) they aren't given the time to carefully test the system to see how it might be abuse…

Deadlines are not an excuse for not doing basic pen/vuln/fuzz testing prior to a release. Even the most basic of tools can detect SQL injections.

I understand this. When security is not part of the culture of the company, and management just wants to ship software, devs won't have time to test. MS used to be this way (back before XP SP2). They stopped and made security a focus and allowed devs to work on securing the software. Today, they are much better off because of that. Not all companies think about security. Many only think about the bottom line.

Re: 14 Years of SQL Injection and still the most dangerous vulnerability

#19

Post by [deleted] »

mikeash wrote: post #17
betterunix wrote: post #11

Earlier quoted context omitted.

"this is done by escaping inputs" Something about that sounds wrong. It is as though you are suggesting that we use in-band signaling with a bunch of notch filters to ensure that Cap'n Crunch whistles cannot be used to get free calls. The right answer is out-of-band signaling -- in other words, not constructing queries / command strings / etc. from user inputs. Major SQL databases all support prepared statements; thi…

I think that comment is a succinct summary of why SQL injections are still common, anyway. The answer: because people think "escaping" is the answer. Imagine constructing a function in some other language this way: function square(x) { code = x + "*" + x; return eval(code); } This is obviously wrong. Now, let's say I suggest fixing it with escaping: function square(x) { code = escape(x) + "*" + escape(x); return eval…

[deleted]

Re: 14 Years of SQL Injection and still the most dangerous vulnerability

#20

Post by dragonwriter »

mikeash wrote: post #17
betterunix wrote: post #11

Earlier quoted context omitted.

"this is done by escaping inputs" Something about that sounds wrong. It is as though you are suggesting that we use in-band signaling with a bunch of notch filters to ensure that Cap'n Crunch whistles cannot be used to get free calls. The right answer is out-of-band signaling -- in other words, not constructing queries / command strings / etc. from user inputs. Major SQL databases all support prepared statements; thi…

I think that comment is a succinct summary of why SQL injections are still common, anyway. The answer: because people think "escaping" is the answer. Imagine constructing a function in some other language this way: function square(x) { code = x + "*" + x; return eval(code); } This is obviously wrong. Now, let's say I suggest fixing it with escaping: function square(x) { code = escape(x) + "*" + escape(x); return eval…

> Occasionally people talk about prepared statements and parameterized queries and such, but usually people just talk about escaping.

Occasionally? For many years "preferred prepared statements and use user input, sanitized (via escaping and/or more involved means) or not, only with a very special need that where prepared statements don't do what you need, and then be as restrictive as possible in what you accept" has been what I've heard everywhere.

Post reply on HN