The internal people that have been granted access to the servers running
this system probably wouldn't have the knowledge or inclination to attempt a
hack. Only around eighty out of a possibly much higher number have been
given access although it is intended that some external users may be given
access to this system.
The data is mostly proposed project values with projected spending and
revenue. It's not vital but could be a little too sensitive to allow
unrestricted access.
Perhaps instead of describing what I have to work with my question should be
more general:
How do you ensure that Perl CGI scripts are safe from attack?
I can't restrict access to the directories, as the brief is that this should
be potentially accessible from any system provided the user has been given a
valid password. I haven't got the option of making these server logon
passwords so I have to do something in the CGI script.
I've described how I'm doing this in another response.
Thanks for your help.
Garry.
> -----Original Message-----
> From: Gunther Birznieks [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, September 18, 2001 1:08 PM
> To: Grierson, Garry (UK07); [EMAIL PROTECTED]
> Subject: Re: Security Suggestions Please!
>
> At 12:22 PM 9/18/2001 +0200, Grierson, Garry (UK07) wrote:
> >I have to secure a newly developed web search service that deals with
> >sensitive fiscal information, this originally consisted of Perl scripts
> that
> >called html pages or other scripts. The default page ran a rudimentary
> login
> >script that launched a variety of html pages or further scripts, the html
> >pages in turn also ran scripts, one page also runs an IDC search.
> >
> >To disallow direct access to the html I have 'moved' this inside the
> >appropriate Perl scripts so a valid password displays the html page and
> an
> >invalid password returns you to the login script. The password is passed
> >between the scripts using the post method so it won't show up on the URL
> >bar.
> >
> >I have two questions.
> >
> >1) What benefits if any are there from checking the entered passwords
> >against a file or database table as opposed to having a valid password or
> >list of passwords held within the initial validation script?
> > The password will be changed regularly and the server is unlikely
> to be
> >changed to displaying the script text be mistake is unlikely.
>
> This depends on your security model and whether you believe in security
> through obscurity.
>
> >2) What if any dangers are inherent in passing the password between the
> >scripts to verify the users access?
> > This is an Intranet site so the only sniffers should be people
> with
> >colds!
>
> Do you trust your employees? I might if I have 5, but a company of 3000
> would likely and probably should not. Corporate espionage and sabotage is
> definitely a real threat in corporations world-wide and should not be
> ruled
> out even if it seems improbable.
>
> That doesn't necessarily mean you need SSL client certificates. But it
> does
> mean that you should match your security needs with your risks. You really
>
> have not laid out the risks of what your company loses if these areas of
> your web site are exposed.
>
>
>
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
