Confusing problem
clintonia
(and anyone else really)
About a month ago, we had some records go missing from a database
table. There were about 31 records total, but only the first 13 got
removed. We had backups, so the site got restored.
However, the same thing just happened again except the first 13
records were the only ones left and everything after got deleted. This
is a content table and there's only three people that have access to
the admin side. There's no way to delete more than one record at a
time through any of my scripts, so if it is a user case, our client
would have to click the delete link next to every page listed in the
admin side. They say they're doing no such thing. I sure as hell
didn't do it either :)
Our server tech support says there hasn't been any evidence of hacks
or that our system has been compromised in any way.
I've changed user/password access for the database with a password
that's pretty ridiculous, so I'm hoping this doesn't happen again.
I've gone through my code, but my still-somewhat-noobish eyes don't
see anything that could be causing this. I mean, if the script is not
secure, then I don't know why.
I would greatly appreciate any help or suggestions on this. I'll share
code if need be.
Thanks a bunch!
Mike G.
You definitely take the prize for the strange problem of the day. I
can't say that I've heard of anything along those lines, but I still
think that I can offer some toubleshooting tips to try (if you haven't
already).
1. What table type are you using? If it's InnoDB you may have some
incorrect foreign key constraints set up causing data to run away.
2. You don't have any web acceleration apps installed do you? I
remember a while back Google had a crappy app that would "accelerate"
a browser by caching all links on a page (including those "delete"
links in admins).
3. Finally, post some code and seek further counsel.
Let us know what's up!
clintonia
1) I checked my table types...they're all MyISAM.
2) Our server guys tell me we have no acceleration apps installed. We
do use Google Urchin for stat tracking purposes, but not on any of the
admin pages. I just created a robots.txt to disallow robots from
accessing the admin side of the site.
Thanks for your help. I'll be putting code up soon.
ParkinT
13) I would say you may have a SQL injection vulnerability that is NOT
being used by a hacker, but the right set of circumstances (a user
enters a zip code that incudes Zip-plus-four, with the dash).
Either that or, based on the number 13, your system is possessed by
the spirit of some ancient Magi from Zimbabwe.
THOM
On Jun 11, 4:07 pm, clintonia <clinto...@gmail.com> wrote:
Michael Girouard
You could tell really quickly if this is the case by asking yourself if this is happening upon an certain event. For example when someone Edits or deletes something. If so, find query code in your scripts and tell it to die() instead of querying.
die($sql); // mysql_query($sql);
If you are lucky enough to be using CakePHP as a framework, just set the DEBUG constant to a value of 2. That will put a handy-dandy query table at the bottom of all pages showing all queries and their results/errors.
Cheers,
Mike G.
Mike Geee!
Professional Superhero
w: lovemikeg.com
e: mgir...@gmail.com
c: 386-503-3505
clintonia
query and they're all looking correct (no deleting where there
shouldn't be).
On Jun 12, 6:11 pm, "Michael Girouard" <mgirou...@gmail.com> wrote:
> SQL injection is a very real thing. It wouldn't surprise me if that happened
> to be your problem.
>
> You could tell really quickly if this is the case by asking yourself if this
> is happening upon an certain event. For example when someone Edits or
> deletes something. If so, find query code in your scripts and tell it to
> die() instead of querying.
>
> die($sql); // mysql_query($sql);
>
> If you are lucky enough to be using CakePHP as a framework, just set the
> DEBUG constant to a value of 2. That will put a handy-dandy query table at
> the bottom of all pages showing all queries and their results/errors.
>
> Cheers,
> Mike G.
>
> e: mgirou...@gmail.com
> c: 386-503-3505
clintonia
Doesn't it have to be a DELETE SQL statement to delete records? I
mean, if it's an UPDATE, what magical mystery combination of strings
or text could possibly make that statement permanently delete records?
Alexander Rudloff
New to the group -- hi ;)
Having not read the whole thread, I'm assuming this is SQL injection
related? If so, here's an example...
"UPDATE users SET balance = $var";
where $var = "0; DELETE FROM users;"
The "delete from users" is the sql being injected.. There's a bunch of safe
guards you can do if your framework doesn't do them already, but an
immediate one might be to rewrite it as "UPDATE users SET balance = '$var'"
(note the single quotes around $var) while additionally mysql_escaping the
variable before hand.
Hope thats on topic/helps/etc. Looking forward to meeting some of ya'll
soon.
Best,
Alex Rudloff
Emurse.com
clintonia
I followed the example on logging in on this page:
http://www.netlobo.com/preventing_mysql_injection.html
But it tells me I've used the wrong username/password instead of
letting me in.
I'm trying to wrap my head around how these work, but I'm not getting
anywhere.
On Jun 26, 12:08 pm, "Alexander Rudloff" <arudl...@gmail.com> wrote:
> Hey guys,
>
> New to the group -- hi ;)
>
> Having not read the whole thread, I'm assuming this is SQL injection
> related? If so, here's an example...
>
> "UPDATE users SET balance = $var";
>
> where $var = "0; DELETE FROM users;"
>
> The "delete from users" is the sql being injected.. There's a bunch of safe
> guards you can do if your framework doesn't do them already, but an
> immediate one might be to rewrite it as "UPDATE users SET balance = '$var'"
> (note the single quotes around $var) while additionally mysql_escaping the
> variable before hand.
>
> Hope thats on topic/helps/etc. Looking forward to meeting some of ya'll
> soon.
>
> Best,
>
> Alex Rudloff
> Emurse.com
>
Mike G.
Clint,
Most likely thats because magic_quotes_gpc is stepping in and doing
what it's supposed to do: escape quotes, magically. Which makes it
difficult (not impossible) to inject arbitrary SQL into your web app.
Here's three things to do:
1. Examine your logs.
Figure out an approximate time that these records are deleted. Take
that time and open up your Apache log files. Look for any entrees that
target the delete page(s) you've created or look for requests that
contain a bunch of stuff that doesn't belong in a normal URL (IE:
injection strings).
2. Consider it being a relationship problem
If this is a table with a many-to-one relationship (many of its
records to one record in a parent table), it's possible that when it's
parent is removed that the relationship is destroyed no longer making
it visible. In other words, it's referential integrity is compromised
(I was hoping to use that in a sentence today).
For example, if you have products and you have categories: You have
many products in one category. Each product is linked to it's parent
category via a single 'category_id' column in the product table. When
a category is deleted, and you don't have foreign key constraints set
up, the products now have no [valid] parent.
3. Are you on a shared server? If so, get off.
There is no such thing as a secure shared server. Get a worthy system
admin involved and put the issue in his hands. Then start pricing
dedicated or VPS configurations.