SQL Injection 1

[Crundy]

Hi all,
A department here has outsourced their website design to a company who don't seem to see security as a important issue. Their code seems to be a definite target for a SQL injection attack, but I've been unsuccessful in coming up with a way to prove this.

e.g. one page gets a list of rows from the database based on a value from the querystring:

page.php?id=45

$sql = "select * from tablename where something < 1 and somethingelse=$id";

I've tried changing the querystring to:
page.php?id=45;+drop+table+testtable;

so the query becomes:
select * from tablename where something < 1 and somethingelse=45; drop table testtable;
But it doesn't execute (I presume because it's 2 queries). I'm sure this worked with a SQL Server backend when I was testing out one of my ASP apps, but MySQL just throws an error.

Does anyone know how I can delete a test table from the database to prove to the design company they need to do some var checking? If I don't prove it to them then they'll just leave it and someone else will hack it.

Thanks.

C:\DOS:>
C:\DOS:>RUN
RUN DOS RUN!!

 

[sleipnir214]

I'm not going to touch this question with a 3 meter cattle prod.

Crundy, I mean no offense, but you are just an anonymous poster on a message board. I know I, as an ironclad rule with no exceptions, will not provide the kind of advice you want without vetting your credentials. Which is very difficult to do online.

The information you're looking for is probably available out there. Some Google searches might be useful.

Want the best answers? Ask the best questions!

TANSTAAFL!!

 

[Crundy]

You don't have to answer if you don't want to. Like you say, there's lots of info out there, and I'm only looking for a shortcut from people who have to deal with issues such as SQL injection on a daily basis.

I'm looking to find a bit of evidence to send to a design company to get them to fix security holes in an application they are developing, so I don't have to fix the backlash when someone decides to exploit the open holes later. There isn't much else I can do to prove to you the colour of the hat I'm wearing on this one.

And no, I wasn't expecting a free lunch

C:\DOS:>
C:\DOS:>RUN
RUN DOS RUN!!

 

[skiflyer]

Well, I touch this one just because I'm fairly certain it's possible to do without giving up too much bad info.

The long and short of it is, you're going after the wrong attack.

Basically, if I'm not mistaken, PHP does not allow multiple queries to be sent in one block. I'm kind of surprised by this, as tools like phpMyAdmin have no trouble with it, and whatnot... but that's what my testing, as well as the PHP Manuals commentary about not ending the sql with a semi-colon would seem to imply.

But, the semi-colon isn't needed to do nasty things.

The biggest threat I'm aware of with unsanitized data like you're describing isn't erasing it, it's displaying more of that should be allowed to be seen.

i.e.

http://www.securityfocus.com/bid/12161/info/

 

[Olavxxx]

I however think that if you do not know how to do this by yourself, how are you able to protect the company against such things?

The server can however also have some security measures that you are not aware of.

be aware: you can be persucited for "cracking/hacking" (loose term, often wrongly used).

The company might not like that you are trying to infiltrate theire systems, unless they SPECIFICALLY gave you some written document where you are allowed to try to bring theire system down.

I would also not touch this, as I dont want to be a part of this.

Olav Alexander Mjelde

http://www.volvo-power.net

Admin & Webmaster

 

[748323]

Seems like BS to me. Any company who can use MySQL knows how to use if statements and is_int.

 

[Crundy]

Any company who can use MySQL knows how to use if statements and is_int
Obviously not.

skiflyer: Yes, looking further it seems that using the MySQL connector will only allow you to execute one query at a time by default, so there isn't a problem with data being damaged. The script just pulls out one record about an exhibition and displays it, so there isn't really a problem with pulling out more data than necessary.

The only other thing was an admin section in which they had just used this statement:

$sql = "SELECT id FROM $tablename WHERE username='$username' AND password=password('$password')";

for authentication with no cleaning of the data. However, it seems PHP is automatically escaping any single quotes from the form data, so that should also be ok.

I'm guessing that means the site, though badly programmed, is relatively safe. Or have I not thought of anything?

C:\DOS:>
C:\DOS:>RUN
RUN DOS RUN!!

 

[Olavxxx]

I would rather offer them some "variable securing", rather than "hacking security".

Eg. Tell them that you can make the script fix:
JOHN DOE -> John Doe
john dOe -> John Doe

And, that you can fix:
<b>hello</b> <img src="...> -> hello

etc.

Also that you can trim away whitespace from things like passwords..

If you sell them some "security", without really knowing what you are protecting against, I think that they will and should blame you, when someone brings theire system down.

Then you are deep in it, if you dont know what happend.

eg. You can offer some securing of theire scripts, but dont say "my scripting will make things perfect".

You need to let them know that there are *always* some issues, if not in the programming, then maybe in the server software, etc.

Maybe you should tell them about backups, etc. also.

Olav Alexander Mjelde

http://www.volvo-power.net

Admin & Webmaster

 

[Crundy]

Hi Olav,
Thanks for the tips. I suspect you're right, but my problem is that the company has been a bit arrogant about their code in the past. I was orginally going to send on some details about a few things to make the scripts more secure, but I was anticipating a 'That won't happen' reply, and was looking for a way to prove it. In the absence of a way to prove it I guess I should just send some suggestions to disclaim myself if the site does get hacked.

C:\DOS:>
C:\DOS:>RUN
RUN DOS RUN!!

 

[skiflyer]

Sometimes you have to demonstrate the hacking so they'll buy the security.

The connectors can let you pull info over from other tables sometimes is the bigger concern.

Inserts are even more dangerous if they're not done right.

But the securing is so simple there's really no excuse not to do it...

 

[Crundy]

The connectors can let you pull info over from other tables sometimes is the bigger concern.

That's one concern, but I don't think it's a massive problem, as there isn't any sensitive info in the db, and I presume there's problems with displaying the data back to the page if the code displays specific column names (e.g. $row["description"])?

But the securing is so simple there's really no excuse not to do it...

Absolutely, but for some reason so few people are willing to do it. I think a lot of programmers are just interested in getting the code to work first, and then implement the security later if they can be bothered. Most can't be bothered. How much hassle is it to do something like:
$id = (int) $id;
as the first line in your script for the querystring vars?


C:\DOS:>
C:\DOS:>RUN
RUN DOS RUN!!

 

[skiflyer]

That's one concern, but I don't think it's a massive problem, as there isn't any sensitive info in the db, and I presume there's problems with displaying the data back to the page if the code displays specific column names (e.g. $row["description"])?


That's actually exactly the trick... you do something like get the password of a high level user in the system put into an item description field.

That kind of thing requires knowledge of the database obviouslly, but with certain systems that are widely distributed that kind of knowledge is easy to come by, with a custom application, not so much.

 

[Crundy]

Ah right, as in using a UNION statement or the like?

Again, I don't think there's much in there of any interest, apart from the admin password hash for the PHP system, but considering it would only really be script kiddies having a go, I don't think it's very high risk.

I did send the designers an email though pointing out the flaws. They haven't got back to me

C:\DOS:>
C:\DOS:>RUN
RUN DOS RUN!!

 

[Olavxxx]

If theire PHP is sloppy, I would guess that theire HTML parsing is also sloppy.

You might consider telling them that they "need" XHTML, if most browsers are to display the site properly.

You can take screenshots of theire pages in different browsers and mail it to them.
Especially a screenshot from a non-gui browser will be a significant one, I'd guess.

Olav Alexander Mjelde

http://www.volvo-power.net

Admin & Webmaster

 

[Crundy]

That's a whole other issue!

I think the only really important one is for the site to be WAI compliant, as we're a University and this is a legal requirement for us now.

C:\DOS:>
C:\DOS:>RUN
RUN DOS RUN!!