in reply to MySQL Status Tool

Looks interesting...

A few "rote" questions spring to mind, though.

Aside from that, looks interesting. The taint checking may be needless paranoia, but I'm not sure, since I don't know how the 3rd arg to DBI->connect gets validated. So I'd rather be paranoid...


--
Mike

Replies are listed 'Best First'.
Re: Re: MySQL Status Tool
by qslack (Scribe) on Apr 15, 2002 at 20:07 UTC
    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&&&'
[reply]
[d/l]
      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]
      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