Security Suggestions Please!
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. 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! -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Security Suggestions Please!
1) Ok point taken.
2) Mabey a little unclear here: The script 'prints' a HTML page if the
password is accepted. When an option is selected from the HTML page it calls
another script passing the password data originally passed to the current
script as part of the HTML FORM information.
E.g.
(HTML Input FORM)
form action=../scripts/password.plx method=POST
blockquote
h3 align=centerfont size=4 face=ArialbPlease
enter an authentication Password:/b/font/h3
p align=centerinput type=password size=20
name=password/p
/blockquote
/form
|
\/
(passwords.plx Script One)
print Content-type: text/html\n\n;
use strict;
use CGI;
my $q = new CGI;
my $password = $q-param( password );
if ($password eq 'password'){ #only an example#
print HTML_SCRIPT1;
html~~~FORM(s) To Run Script Two, Three , Four ,
etc./FORM~~~
It works but how secure is it assuming nobody is going to see the
'password'?
-Original Message-
From: Roger C Haslock [SMTP:[EMAIL PROTECTED]]
Sent: Tuesday, September 18, 2001 2:42 PM
To: Grierson, Garry (UK07)
Subject: Re: Security Suggestions Please!
(This is not a perl/cgi question)
1)
It is easier to manage changes if data is held in a database. By similar
triangles, it is easier to manage security if data is held in a database.
2)
I don't understand the question. Exactly how do you propose to pass the
password between scripts?
- Roger -
- Original Message -
From: Grierson, Garry (UK07) [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, September 18, 2001 11:22 AM
Subject: Security Suggestions Please!
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.
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!
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Security Suggestions Please!
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]
RE: Security Suggestions Please!
use strict;
use CGI;
my $q = new CGI;
my $password = $q-param( password );
if ($password eq 'password'){ #only an example#
print HTML_SCRIPT1;
html~~~FORM(s) To Run Script Two, Three , Four ,
etc./FORM~~~
It works but how secure is it assuming nobody is going to see the
'password'?
How, precisely, is anyone prevented from seeing passwords? You haven't mentioned
cookies (which,
in any event, can still be sniffed and are stored on the computer), but you *have*
mentioned the
POST method as a means of securing data. I'm assuming that you are using hidden
fields. Anyone
can view source and see the password. This is a very, very bad idea.
Okay, so this is for an intranet and you're not worried about sniffers. First rule of
CGI
security: never, never, never trust anything outside of your script. What if someone
compromises
your firewall? What if a curious employee wants to see the passwords (one company I
worked for,
that curious employee was then tasked with creating a security department)? What if
someone comes
along later and decides to add bells and whistles to what you have developed? No one
can anyone
predict the future; You don't know what's going to happen with your code. That's why
security is
*always* important.
One problem with not securing passwords, even if the application is not secure, is
that people
tend to reuse passwords. Even if you set a password policy and issue secure
passwords, they will
often take these passwords and use them on other systems. I've heard people
complaining because
they need to synchronize their passwords *again*! If you allow these passwords to be
compromised,
someone may very well have access for a heck of a lot more than just your HTML pages.
In my
security research, I've read more than once that the majority of corporate espionage
comes from
inside the company. Your email address suggests that you work for Honeywell. They're
not a tiny,
fly-by-night non-profit. They have many employees and I would hardly credit all of
them with
goodwill.
For a *brief* overview of Web security with Perl, read
http://www.easystreet.com/~ovid/cgi_course/lesson_three/lesson_three.html (I realize,
inexplicably, that I didn't cover cookies in that!). That material also includes many
links to
other security material. Learn it all and you'll be telling *me* how to lock down a
CGI script :)
sub create_digest_from_password {
my $pass = shift;
my $md5 = Digest::MD5-new;
$md5-add( $pass );
$md5-add( $salt );
$md5-b64digest;
}
The above snippet will return a 22 character digest which is essentially a one-way
function.
You cannot recover the digest from it. The salt should be a very random string of
data that is
read from a non-Web accessible directory (don't put it in the script in case someone
gets your
code). This salt can never change.
Once you create the digest, save the digest and when someone logs in, recreate the
digest from
their login passwords. If the passwords match, you have a successful login (I write
failures to a
security log). You can then pass around the digest rather than the password. It
should require
very little change to your code.
The salt, by the way, is used to stop crackers from brute forcing a password.
Typically, they
use something like l0phtcrack which uses a word list to generate common permutations
of those
words to guess passwords. If your salt is
(*@LNz4L*#@^
few, if any are going to guess it.
Also, you should probably try to use sessions instead of passing around a password
digest. It's
much more secure. If you want to see how that's done,
http://www.perlmonks.org/index.pl?node_id=101247 is an alpha of a security model I
developed.
Unfortunately, I can't release the final product, sorry.
Cheers,
Curtis Ovid Poe
=
Senior Programmer
Onsite! Technology (http://www.onsitetech.com/)
Ovid on http://www.perlmonks.org/
__
Terrorist Attacks on U.S. - How can you help?
Donate cash, emergency relief information
http://dailynews.yahoo.com/fc/US/Emergency_Information/
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
