SQL Injection through HTTP Headers • Hacker News Board

Re: SQL Injection through HTTP Headers

#11

Post by borski » Wed, Apr 04, 2012, 5:33 AM UTC

nullflux wrote: post #5

thesis wrote: post #2

This seems like a total non-issue. Just CORRECTLY sanitize everything going into the database! By the way, just to let everyone know also. You should also sanitize form submissions.

Heh, that's not how most people think. It's more like: Security! It's a total non-issue! Why would anyone want to break my app? Most people seem to feel this way until their apps are dumped, rooted, hacked, or they just end up thinking security is cool and say "Man, I didn't realize how much of a mess I had before." Basic scans need to be part of the CI workflow of startups these days. The same QA tier you use for Se…

Completely agreed. And actually, this is a large part of what Tinfoil is currently working on building. If you have suggestions, we're all ears.

It's all too common to hear people not caring until its too late. At least with all the skiddies running around nowadays it's harder for anybody rational to ignore.

Re: SQL Injection through HTTP Headers

#12

Post by dwich » Wed, Apr 04, 2012, 5:36 AM UTC

thesis wrote: post #2

This seems like a total non-issue. Just CORRECTLY sanitize everything going into the database! By the way, just to let everyone know also. You should also sanitize form submissions.

In defense of the author, his audience appears to be mostly people doing black-box security scans (and those writing security-scanning software). For those people, understanding additional attack vectors is useful.

Re: SQL Injection through HTTP Headers

#13

Post by pilif » Wed, Apr 04, 2012, 6:00 AM UTC

The x-forwarded-for example is the perfect example to explain why you should just escape anything and never try to guess trust boundaries.

Sure. When you started with that query, that IP address likely was just REMOTE_ADDR (guaranteed to not contain "bad" characters), but then the app was put behind a reverse proxy and support for x-forwarded-for was added, suddenly changing the IP address to something user-modifyable.

It costs practically nothing to use your ORM or prepared statements in order to escape all values you put into a query. So just do it and don't try to guess whether you can trust a value or not, because, after all, the source of these values can change, sometimes even without you knowing.

Re: SQL Injection through HTTP Headers

#14

Post by natbat » Wed, Apr 04, 2012, 6:32 AM UTC

thesis wrote: post #2

This seems like a total non-issue. Just CORRECTLY sanitize everything going into the database! By the way, just to let everyone know also. You should also sanitize form submissions.

Thinking about "sanitizing" puts you in the wrong frame of mind in my opinion - you should be thinking about ESCAPING. If you're constructing SQL queries sensibly (using an ORM or a library that replaces placeholders rather than concatenating strings together yourself) you won't even have to think about that.

Re: SQL Injection through HTTP Headers

#15

Post by btbuilder » Wed, Apr 04, 2012, 6:57 AM UTC

This article does not provide a good pattern for protecting against SQL injections. You can protect against all possible input vectors by using placeholders. Constructing SQL queries with string formatting or concatenation should be avoided. When executing bulk queries it is also more efficient.

  $stmt = $dbh->prepare("SELECT user,password FROM admins WHERE user=? AND password=? AND ip_adr=?");
  $stmt->execute($_POST['user'], md5($_POST['password']), ip_adr())

The above approach does not require that you think about what data you are accepting, and if done through-out your code, others who may not be so pre-disposed to think about escaping will not make mistakes if they copy you.

Re: SQL Injection through HTTP Headers

#16

Post by jedberg » Wed, Apr 04, 2012, 7:08 AM UTC

dangrossman wrote: post #6

Reddit.com's response headers: Cache-Control: no-cache Connection: keep-alive Content-Encoding: gzip Content-Length: 18170 Content-Type: text/html; charset=UTF-8 Date: Wed, 04 Apr 2012 04:50:39 GMT Pragma: no-cache Server: '; DROP TABLE servertypes; -- Vary: Accept-Encoding

I put that in as a joke years ago. I can't believe it's still there.

Re: SQL Injection through HTTP Headers

#17

Post by Ralith » Wed, Apr 04, 2012, 7:25 AM UTC

patio11 wrote: post #10

I once found this in live code which was -- irony alert -- checking Authorization headers. Something of the flavor: "select user.* from users where TO_BASE64(email + ':'+ password) = '" + headers["Authorization"] + "' limit 1"; (Can't quite remember -- that base 64 bit might have been pre-calculated in a column. It has been a few years.) One would hope that in addition to fixing the SQL injection they fixed the use o…

Not to mention storing passwords with a trivially reversible transform...

Re: SQL Injection through HTTP Headers

#18

Post by masklinn » Wed, Apr 04, 2012, 7:51 AM UTC

jedberg wrote: post #16

dangrossman wrote: post #6

Reddit.com's response headers: Cache-Control: no-cache Connection: keep-alive Content-Encoding: gzip Content-Length: 18170 Content-Type: text/html; charset=UTF-8 Date: Wed, 04 Apr 2012 04:50:39 GMT Pragma: no-cache Server: '; DROP TABLE servertypes; -- Vary: Accept-Encoding

I put that in as a joke years ago. I can't believe it's still there.

I'm sure somebody somewhere is actually using that to clean up a table in some sort of wonky proxy setup and will cry foul if that header is ever removed.

Re: SQL Injection through HTTP Headers

#19

Post by antihero » Wed, Apr 04, 2012, 8:25 AM UTC

elchief wrote: post #9

If using PHP, use PDO and always use parameters. Use HTMLPurifier to avoid xss. You still need to be careful if building queries dynamically, such as dynamic WHERE or ORDER by clauses.

I'd take that one step further and use an ORM like Doctrine, because otherwise doing trivial stuff is completely annoying. If you don't use an ORM package you quickly start writing your own ORM anyway.

Re: SQL Injection through HTTP Headers

#20

Post by yaix » Wed, Apr 04, 2012, 8:38 AM UTC

If you ever send /any/ client input (or any variable) un-escaped to your DB, I really hope you get your tables deleted as reminder (of course you have a backup, so it will only be a reminder not a disaster).

After 15 years of web development, there is no reason why people still would make this mistake.