Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Re: CGI (in)security

by bradcathey (Prior)
on Jun 15, 2004 at 14:28 UTC ( [id://366903]=note: print w/replies, xml ) Need Help??


in reply to CGI (in)security

kiat, where are you keeping your log-on info for your database? Hard-coded into your script? Hidden somewhere? This topic has come up several times here at the monastery. For a recent thread, start here with this one. No black and white outcome, but worth following the thread (and 'no', I'm not touting my own replies, there's other good stuff there :^)

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

Replies are listed 'Best First'.
Re^2: CGI (in)security
by kiat (Vicar) on Jun 15, 2004 at 14:44 UTC
    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?

      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?

      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

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://366903]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others scrutinizing the Monastery: (6)
As of 2024-04-20 02:30 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found