in reply to Re: MySQL Status Tool
in thread MySQL Status Tool

As I was developing it, I ran it like this:

perl -TwMstrict mysqlstatus.pl

[download]


So, it *is* strict, warning, and taint compatible.

There's no other way to send the root password through HTTP that's completely compatible with all browsers and that doesn't require SSL, as far as I know. If there is a way, I would love to hear it!

You bring up a good point about the root password argument. I do not think that you could set it to "drowssap; drop mysql;" and erase a database. The only thing that could go wrong is a bug in MySQL of the buffer overflow sort, and I have no control over those sorts of things. It's really meant to be used by an admin, and it can even be used with HTTP Auth security so as to disallow potential attackers even the privilege of having a form to validate potential root passwords. :)

Quinn Slack
perl -e 's ssfhjok qupyrqs&&tr sfjkohpyuqrspitnrapj"hs&&eval&&s&&&'

Replies are listed 'Best First'.
Re: Re: Re: MySQL Status Tool
by RMGir (Prior) on Apr 15, 2002 at 20:12 UTC
    Cool... Why not leave the -Tw and use strict; on in the release version, in case of feature creep?

    Short of using javascript to encrypt the password on the client side, with a random "salt" generated from the server each time the page is issued, I don't see a lot of great solutions.

    In any case, make SURE you never use such an app outside your corporate network, and even there, realize that malicious insideers could wind up with your mySQL root passwd...
    --
    Mike

[reply]
      Feature creep might happen, but I add in -w, -T, and -Mstrict as a habit anyways. I will add it if you really want, though. :)<br.
      Any sniffer could also detect the salt used for encryption, so it's unavoidable.

      With a quick edit, you can hardcode in the mysql password in the file. Just change the line like:
      my $rootpwd = $q->param('rootpwd');
      to
      my $rootpwd = 'ilikeapples';.

      -qslack, posting as anon because I am not at my computer and I forgot my password :)
[reply]
[d/l]
[select]
        Seeing the salt of a 3DES or MD5 encrypted password hash isn't enough to make it nearly as easy to read as plaintext. The sniffer would know the encrypted password that one time, but they'd still have to actually crack it in order to use it in the future, or sniff the newly encrypted one next time too, and beat you to submitting the data back to the server. You could also make sure the server only accepts the password encrypted with that salt from the IP to which it sent that salt...

        In other words, don't dismiss advice out of hand without considering that it might actually be good advice.
[reply]
Re: Re: Re: MySQL Status Tool
by graff (Chancellor) on Apr 22, 2002 at 00:35 UTC
    I might be missing something here, but... maybe you should differentiate the two functions that are currently served by the password: (1) validating the person posting the request vs. (2) logging into the database. If your DB status report includes stuff that you don't want to make public (and/or you don't want the public pinging your DB at will), then do something for validation -- whatever's workable and adequate -- that does not involve sending the login password.

    Put the actual DB login password in the code itself -- actually, in a module or "require" file that's readable when the script executes under the web server, but is not directly under $webhome.

    Warning: I haven't researched this idea to figure out how vulnerable it might be (if anyone has facts or data on this, I'd love to hear it), but it seems safer than having ( $user_validation eq $rootlogin ) going through sniffable switches, even granting that it's only "DB root" that we're talking about here (I hope that's all you're talking about).

[reply]

In Section Cool Uses for Perl