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

SQL Injection through HTTP Headers

resources.infosecinstitute.com

Post reply on HN
Print view View original

21–30 of 38 posts

Re: SQL Injection through HTTP Headers

#21

Post by buro9 »

pilif wrote: post #13

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-modifyabl…

It's also a great example of assumptions leading to bugs.

It's not a standard header, it's just a header... a string.

IP addresses may easily be IPv6.

You can easily have comma delimited lists of them.

You don't know how long the input will be.

And unless you are sure that your network is cleaning the incoming requests and setting those headers, you shouldn't even begin to think that they are to be trusted for anything.

Re: SQL Injection through HTTP Headers

#22

Post by Jebus »

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.

HTMLPurifier? That thing should only be used if you are accepting html as input (eg: wysiwyg). Just escape everything in the view layer (not in the DBAL. There you only escape to avoid sql injection, not XSS!)

Re: SQL Injection through HTTP Headers

#23

Post by banthar »

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've tried to write a program (https://gist.github.com/392445) which would be affected by this. It seems it should be `'); DROP TABLE servertypes; --` to actually drop any tables. All I was able to get now is syntax error.

Re: SQL Injection through HTTP Headers

#24

Post by bluesmoon »

While building the web performance analytics system at Yahoo!, I took on a daily task to look through access log lines that our parsers didn't like. Things like strange user agent strings, strange referrers, etc. We'd find all sorts of injection attempts in the User-Agent. SQLi, XSS, Shell injection, windows executable injection. Attackers tried whatever they could.

Re: SQL Injection through HTTP Headers

#25

Post by vidarh »

Ralith wrote: post #17
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...

I once worked in a company where another team were responsible for the company flagship services which - after you'd logged in - stored your customer id in a cookie.

That was the only authentication for subsequent requests. And the ids were sequential.

After I demonstrated to them that I could get the CEOs personal details, as well as trivially brute force all other personal details in the system with a bash script calling curl, not to mention run up massive bills (the system allowed setting up phone conferences with up to 30 participants and let you use the web interface to call out to participants worldwide), they thanked me and told me they'd fix it.

Next day they'd released an updated version which they said encrypted the customer id.

Two problems:

No nonce or anything, so if you sniffed it once, you could still trivially use it to "log in" and continue as before.

Secondly, their "encryption" turned out to be base64.

I sent them a new script that showed them how to get the customer id's still. They were amazed that I'd "cracked their encryption".

Re: SQL Injection through HTTP Headers

#26

Post by dangrossman »

banthar wrote: post #23
jedberg wrote: post #16

Earlier quoted context omitted.

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

I've tried to write a program ( https://gist.github.com/392445 ) which would be affected by this. It seems it should be `'); DROP TABLE servertypes; --` to actually drop any tables. All I was able to get now is syntax error.

This is a valid syntax for MySQL:

    INSERT INTO servertypes SET server = 'Apache'

Re: SQL Injection through HTTP Headers

#27

Post by omh »

As well as SQL injection plenty of sites do odd things which mean they don't work for plenty of users. There are numerous sites which don't load when sent the header:

  x-forwarded-for: unknown
Whatever they were trying to achieve with this (I'm guessing some sort of reverse IP/geolocation lookup) the effect was that none of the people behind our corporate filter could view their site at all.

Re: SQL Injection through HTTP Headers

#30

Post by mkopinsky »

dangrossman wrote: post #26
banthar wrote: post #23

Earlier quoted context omitted.

I've tried to write a program ( https://gist.github.com/392445 ) which would be affected by this. It seems it should be `'); DROP TABLE servertypes; --` to actually drop any tables. All I was able to get now is syntax error.

This is a valid syntax for MySQL: INSERT INTO servertypes SET server = 'Apache'

I recently learned about the INSERT SET syntax, and have started to use it across the board. Sooooo much more readable when column names and values are next to each other rather than separated.
Post reply on HN