"Rik Wasmus" <luiheidsgoeroe@hotmail.com> wrote in message
newsp.t5vnoybr5bnjuv@metallium.lan...
On Fri, 01 Feb 2008 22:32:52 +0100, Kasper Lindberg <NoSp@m.invalid> wrote:
>>
>> well, I am trying to help the guy, not destroy his database .. play nice,
>> okay
>
> Hehe, ask to hack, be hacked, I'm just getting my feet wet here SQL
> injection wise.
>
>>>
>>> No FILE privilage most likely, and I'm not really about to sign up with
>>> http://www.one.com to check out their directory structure anyway.
>>>
>>
>> Well, Asking ther (in)competent support to grant those privileges, might
>> do
>> the trick.
>
> one.com is all about one size fits all, no way you're getting those
> priviliges
>

my experience is that, if you don't take no for an answer, eventualy they
get tired of you and give way, just to get rid of you. (usually I end up
with the same guy, after having gone through 1 or 2 other supporters, before
getting an answer to my questions)

> (and I wouldn't give anyone those in a controlled environment anyway).
>

you wouldn't, but what about their supporters?, I talked to one of them, and
she didn't know why I couldn't use the "into outfile" on a select statement.
To me, this indicates that they have no idea of what privileges they
should(n't) grant to users.

for the record, which user would the query be executed as? the user which
the mysql-deamon is running as, or the user calling ?
(trying to find out how many directories the "into outfile" could write)

>>> Now I'm really going to do something productive, after commenting that

Remember to describe your attempts here, both failures and successes

>>> while hacking has not (yet) succeeded, maybe using ' OR 1=1 FOR UPDATE
>>> ' as a username continously could seriously hinder his ability to alter
>>> the users database.
>>
>> Explain please, what would that acheive?
>
> Locking all rows matched for the duration of the transaction, so they
> wouldn't be able to update or delete those rows. Not really of interest in
> a low traffic site, where a simultanious alter/delete command combined
> with the lock would be extremely rare. On a high traffic site (and with
> anough (almost ddos) power behind the login attempts however, it could
> render all your users incapable of chaging anything about their record.
>

I think it is safe to say, that no changes to the user-table are performed,
ever, unless it is a part of the login-routine.

>>> On that note: never ever show database errors to the users. They are
>>> only
>>> a clue for the potential harmfull, and a nuisance for normal users. Log
>>> errors, show a nice page 'something has failed, our apologies'.
>>
>> Exactly what I am going to tell him, when I'm done.
>
> Hehe, indeed, leave them on for now, I might have inspiration tomorrow....
>

I will send an email to him, describing my findings, sunday evening, meaning
he will read it some time around 8 AM monday morning (GMT +1)

until then, nothing is going to change

--
Kasper