in reply to Re: CGI (in)security
in thread CGI (in)security

Thanks, Brad!

Yes, I hardcode the database log-on info into the script. I've a single module that does the connection. All my modules reside outside of the web directory (/usr/home/mysite/mymodules). I figured that if anybody gets to the script, he's probably good enough to do anything he desires.

I followed that node you pointed. I'm trying to understand your password encryption/decryption code. So you're suggesting I should encrypt the log-on info and place it somewhere below the web directory, like /usr/home/mysite/secret?

Replies are listed 'Best First'.
Re^3: CGI (in)security
by jeffa (Bishop) on Jun 15, 2004 at 14:58 UTC

    The bottom line is that you can only protect yourself from the outside world. If a user has an account on the same shared system as you, that person can read any file that is "available" for the Web because of chmod. So, all things being equal, i could just pop on over to your cgi-bin dir and read your script with a text editor. There is the username, there is the password. Even if you place the username and password in another file in a directory that cannot be accessed by the web, i can still read it, because it has to be chmod'ed appropriately. By encrypting the username and password, i can no longer simply view the file and glean the goods, but, as jayrom pointed out in that thread, i can read the code that decrypts the goods, and therefore i can decrypt the goods myself.

    FWIW, i think it is better to find a group of friends, if possible, and pool in on a hosted box. That way, you have a lot more trust among the users of that system. Someone can still forget to lock the door, though ... oh yeah. A read-only database user is nice too. If you don't need to write to the database, then connect to the database with a user that cannot write to it -- if you have the means to set such an account up, of course. Again, more reasons to get your own box, at least one where you have root access. :)

    jeffa

    L-LL-L--L-LL-L--L-LL-L--
    -R--R-RR-R--R-RR-R--R-RR
    B--B--B--B--B--B--B--B--
    H---H---H---H---H---H---
    (the triplet paradiddle with high-hat)
    
      Thanks, jeffa!

      I had the impression that, with the appropriate directory settings (701), the users in the group aren't able to peek at what's in your directory. Am I missing something here?

        That indeed keeps them from peeking into the directory, but that doesn't keep them from accessing the file if they know the name ahead of time. And where do they get the name? From the script that opens it for reading, and that script is in the cgi-bin directory for your web site. Now the problem is that the web server executing the script has to have permission to read the password file, so you can't just chmod the file (presumable owned by you) to 600 ... unless you have root. Then you can chown the file to the web server, preventing other local users from viewing it (unless they have root too).

        jeffa

        L-LL-L--L-LL-L--L-LL-L--
        -R--R-RR-R--R-RR-R--R-RR
        B--B--B--B--B--B--B--B--
        H---H---H---H---H---H---
        (the triplet paradiddle with high-hat)
        
Re^3: CGI (in)security
by bradcathey (Prior) on Jun 15, 2004 at 15:19 UTC
    Yes, kiat, you got my drift. One thing that I did not mention, but was by jeffa, I do chmod that text file that holds the password to 600. But like I said, nothing is fool proof, though jeffa's suggestion about hosting your own is close (but frought with other hassles beyond security).

    —Brad
    "Don't ever take a fence down until you know the reason it was put up. " G. K. Chesterton