perl MySQL using DBI - security issue

Discussion in 'Perl Misc' started by John, Apr 12, 2006.

  1. John

    John Guest

    Hi

    When using MySql with Perl and use:DBI you need to supply username, password
    and database.

    My question is this.

    What is now considered the *best* method to prevent those three variables
    being accessed by outsiders?

    Running on a Linux server.

    Regards
    John
     
    John, Apr 12, 2006
    #1
    1. Advertising

  2. John

    Guest

    By outsiders are you thinking of 1. hackers or 2. people browsing your
    directory who work in your company or do you mean from 3. the web?

    1. If a hacker gets into your comp, he is coming in as root and it
    doesnt matter what you do.

    2. If it is someone else in your company you can stick the data in a
    prop file and use unix security [ chmod 400 <propfile> ]

    3. If you are running CGI based webapps, after your DB processing is
    connected and done nothing should be displayed [ I hope ]

    Now if you want to really get crazy, use the crypt() function to write
    out the info to a file and decrypt() to access it from inside your
    script

    -C
    Internal Kit Kat Contest
    http://www.iamfood.com/contest

    John wrote:
    > Hi
    >
    > When using MySql with Perl and use:DBI you need to supply username, password
    > and database.
    >
    > My question is this.
    >
    > What is now considered the *best* method to prevent those three variables
    > being accessed by outsiders?
    >
    > Running on a Linux server.
    >
    > Regards
    > John
     
    , Apr 12, 2006
    #2
    1. Advertising

  3. John

    Matt Garrish Guest

    <> wrote in message
    news:...
    > "John" <> wrote in message
    > news:...


    [attribution and tofu corrected]

    >>
    >> When using MySql with Perl and use:DBI you need to supply username,
    >> password
    >> and database.
    >>
    >> My question is this.
    >>
    >> What is now considered the *best* method to prevent those three variables
    >> being accessed by outsiders?

    >


    > Now if you want to really get crazy, use the crypt() function to write
    > out the info to a file and decrypt() to access it from inside your
    > script
    >


    Which is really silly, too. I did that once with the note "if you got this
    far, I'm sure you can figure out the rest". If they can access your script
    source (and presumably the filesystem), it would take only a few seconds to
    modify the script to output the decrypted username/password. As you're
    alluding to, however, the best defence is to not let them in in the first
    place.

    <att
     
    Matt Garrish, Apr 12, 2006
    #3
  4. Not sure if it's the best way, but the way I do it is to have that data
    stored in a config file that is owned by a dummy user and only readable
    by that user. I then have a package that reads this data on load into
    my'd variables (so even a subclass can't see them), and internally
    handles the connections. So instead of using the normal DBI connection
    method, you instead do something like:

    $db_handle = LockedDBPackage->connect;

    All programs that need the database then have to be setuid that dummy
    user and then use the database package, 'drop' privs and then exit if
    privs can be regained.

    Problems then become:

    * Taint mode is automatically on. Yeah sure its more secure, but
    you'd be amazed the number of packages out there that completely bork on
    the weirdest of things when taint is on. Case in point - perl/Tk's
    get[Open|Save]File dialog box will not work, and you can't even
    _display_ tainted text in a textbox. Usually its possible to work around
    this, but in places where it isn't the Taint::Runtime module is
    surprisingly handy (assuming of course you use it judiciously and don't
    just turn off tainting alltogether, which I wouldn't recommend).

    * While the password can't be directly accessed, should a user cause
    the program to core dump they can get at it. You can add SIG traps to
    stop core dumping, but that's assuming your users are just using
    programs and not using libraries for their own programs.

    * Allowing people to use these your DB-based code as libraries now
    requires you (or whoever is in control) to vett the code since
    (hopefully!) your users can't setuid their scripts to the dummy user.
    This is actually probably a good thing, but slows development.

    Hope this helped.
    MB

    John wrote:
    > Hi
    >
    > When using MySql with Perl and use:DBI you need to supply username, password
    > and database.
    >
    > My question is this.
    >
    > What is now considered the *best* method to prevent those three variables
    > being accessed by outsiders?
    >
    > Running on a Linux server.
    >
    > Regards
    > John
    >
    >
    >
    >
    >
     
    Matthew Braid, Apr 13, 2006
    #4
  5. "John" <> wrote in message
    news:...
    > Hi
    >
    > When using MySql with Perl and use:DBI you need to supply username,

    password
    > and database.
    >
    > My question is this.
    >
    > What is now considered the *best* method to prevent those three variables
    > being accessed by outsiders?
    >
    > Running on a Linux server.


    If you're using MySQL for a webserver and control everything on that
    webserver, don't bother with a password; just use host-based
    access-control. I do that when I write sample CGI programs on my laptop.

    If you're writing CGI code that goes on some sort of shared-hosting service,
    all you can do is make sure that your source-code is never accessible from
    outside or readable by other users. Don't stick the pssword in a ".txt"
    file; put it at the top of each '.cgi" file, or in a common "include.cgi"
    or whatever.

    If you're writing little scripts to work on a user-authenticated database,
    just "chmod 400" your source-code. If you're worried about people
    shoulder-surfing while you write your programs, set the password in
    "~/.my.cnf" (remember: "chmod 400") and use code like the following:

    open MY_CNF, $ENV{HOME}.'/.my.cnf';
    while (<MY_CNF>) {
    $dbuser = $1 if /^user=(\S+)/;
    $dbpass = $1 if /^password=(\S*)/;
    };
    die if (!defined($dbuser) or !defined($dbpass));

    I wish DBD::MySQL had an easier way to use the "default connect info" from
    the comand-line, environment variables, /etc/my.cnf and .my.cnf, but AFAIK
    it doesn't (yet)..
     
    Daud Lee Lambert, Apr 13, 2006
    #5
  6. John

    DJ Stunks Guest

    Daud Lee Lambert wrote:
    > If you're writing little scripts to work on a user-authenticated database,
    > just "chmod 400" your source-code. If you're worried about people
    > shoulder-surfing while you write your programs, set the password in
    > "~/.my.cnf" (remember: "chmod 400") and use code like the following:
    >
    > open MY_CNF, $ENV{HOME}.'/.my.cnf';
    > while (<MY_CNF>) {
    > $dbuser = $1 if /^user=(\S+)/;
    > $dbpass = $1 if /^password=(\S*)/;
    > };
    > die if (!defined($dbuser) or !defined($dbpass));
    >
    > I wish DBD::MySQL had an easier way to use the "default connect info" from
    > the comand-line, environment variables, /etc/my.cnf and .my.cnf, but AFAIK
    > it doesn't (yet)..


    Not a bad idea, also makes for more portable code -- you don't need to
    specify username in every script that connects to the database. Change
    your DB password and you only have to edit one file.

    But rather that parsing my.cnf on your own, let me suggest (from a
    quick CPAN search):
    http://search.cpan.org/~darren/MySQL-Config-1.03/lib/MySQL/Config.pm

    -jp
     
    DJ Stunks, Apr 13, 2006
    #6
  7. wrote:
    > By outsiders are you thinking of 1. hackers or 2. people browsing your
    > directory who work in your company or do you mean from 3. the web?
    >
    > 1. If a hacker gets into your comp, he is coming in as root and it
    > doesnt matter what you do.


    Not necessarily. In fact a big part of making systems "secure" is
    ensuring that the hacker is not coming in as root, but as a user with as
    little privileges as possible.

    hp

    --
    _ | Peter J. Holzer | Löschung von at.usenet.schmankerl?
    |_|_) | Sysadmin WSR/LUGA |
    | | | | Diskussion derzeit in at.usenet.gruppen
    __/ | http://www.hjp.at/ |
     
    Peter J. Holzer, Apr 14, 2006
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Paul Vudmaska

    dbi:mysql mysql has gone away

    Paul Vudmaska, Apr 21, 2004, in forum: Ruby
    Replies:
    0
    Views:
    116
    Paul Vudmaska
    Apr 21, 2004
  2. Jerome Hauss
    Replies:
    0
    Views:
    176
    Jerome Hauss
    Oct 13, 2004
  3. wana
    Replies:
    0
    Views:
    181
  4. sam
    Replies:
    2
    Views:
    271
    J. Gleixner
    Jan 18, 2005
  5. Jack
    Replies:
    1
    Views:
    151
    Paul Lalli
    Mar 22, 2007
Loading...

Share This Page