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!
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)
Please
enter an authentication Password:
|
\/
(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 <~~~ To Run Script Two, Three , Four ,
etc.~~~
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!
That doesn't sound a good idea at all. Anyone can view the (HTML) source of
a web page, and can pick anything they like out of it.
Having validated a user, by means of password or otherwise, I would create a
session code, (use MD5, or something), and embed this as a hidden field
within the HTML. Arrange that the life of this session code is short (time
out activity after x minutes). Log any changes,with this code, against the
alleged user. If you are paranoid, you can generate a new code for each
page, but this fails if the user clicks on 'Back'.
Its something like using cookies, but works if cookies aren't enabled.
You must realise, however, this is not very secure. Its better that
re-broadcasting the password, however, and shows you are taking precautions,
if someone tries to sue for damages.
I hope this helps.
- Roger -
- Original Message -
From: "Grierson, Garry (UK07)" <[EMAIL PROTECTED]>
To: "Roger C Haslock" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, September 18, 2001 3:20 PM
Subject: 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)
>
>
> Please
> enter an authentication Password:
> name="password">
>
>
> |
> \/
> (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 < ~~~ To Run Script Two, Three , Four ,
> etc.~~~
>
> 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]
>
>
>
>
>
--
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 < ~~~ To Run Script Two, Three , Four ,
> etc.~~~
>
> 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
(*@&L>Nz4L*&#@&^
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]
RE: Security Suggestions Please!
At 04:37 PM 09/18/2001 +0200, Grierson, Garry (UK07) wrote: >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. Well, lets get our terminology straight first :) To "hack" is a good thing...lets not fall into the mass-media trap of equating computer intrusion with "hacking". That being said, nowadays you don't need much knowledge to compromise security on a computer network. Thousands of pre-made "script kiddie" exploit tools are available which make it trivial to sniff passwords, gain root access, cause Denial of Service attacks, etc. etc. Even your grandmother could do it. As has been said before, "security through obscurity" is no security at all. I apologize if I offend anyone by making a parallel to the terrorist attacks in New York City, but it highlights an undeniable truth: Security is compromised most effectively when the target least expects it. > 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. Your system and security model *must* be designed to take ANY "exception" (i.e. "some external users") into account, no matter how infrequently these exceptions may occur. >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? Nothing is safe from attack, but you can make them safer from compromise by doing some of the following: Always run your scripts with taint checking (-T) turned on, but *don't* rely on -T alone to ensure input/output data security. Taint checking is only effective if you write robust regexs to clean and check incoming data. If you're interfacing with a database via CGI, DON'T directly use data received from CGI input parameters to construct your SQL queries. SQL queries should be treated in the same way that you would if you were sending parameters to an external system call: Wring the parameters through a GOOD regex and DBI's quote() function to ensure that you're sending secure data with no funny-business hiding in them (i.e. shell escapes, semicolons etc.). Regarding regexs, instead of trying to filter out all possible forms of "bad" data, its better to write the regex so it only ALLOWS specific data, in the format that you specify. Otherwise, you will invariably fail/forget to disallow something that you shouldnt be letting through. My general rule is, you can't be too paranoid. Write your code from the perspective of a potential attacker, and plug the obvious holes, and use your creativity to figure out all the not-so-obvious holes that exist, and plug them accordingly. Of course, you can't do this unless you know all of the tricks of the trade that system crackers use, so studying exploit scripts and having a subscription to the BUGTRAQ mailing list (or at least a frequent browsing of the web archives) is a *requirement* for any programmer or sysadmin who is interested in maintaining secure systems. hope this helps...Aloha, mel -- mel matsuokaHawaiian Image Productions Chief Executive Alphageek (vox)1.808.531.5474 [EMAIL PROTECTED] (fax)1.808.526.4040 -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Security Suggestions Please!
I would run everything inside of a Secure Socket Layer (SSL) Win32 and/or use some type of algorithm to encrypt the data between scripts. I would look into Digest::MD5, it's a 128 bit one way hash algorithm. Go to CPAN for more info. Could be an idea to get you started. GL, Mark Bergeron' -Original Message- From: "Grierson, Garry (UK07)"<[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Date: Tue Sep 18 03:22:17 PDT 2001 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] > . . .. .__ . , |\/| _.._.;_/ _.._ _| [__)._.* _| _ _ -+- | |(_][ | \ (_][ )(_] [__)[ |(_](_](/, | ._| ___ GO.com Mail Get Your Free, Private E-mail at http://mail.go.com -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Security Suggestions Please!
If you want your usernames and passwords to look something like this.
ªaRtW¢³†Ê¬Ì~“µv$¾ïÃ
then store passwords in a mysql blob field with the encrypt() function and a
"key". I learned this technique from a very excellent tutorial by Aaron
Weiss at the following URL:
www.wdvl.com/Authoring/Languages/Perl/PerlfortheWeb/personalization2.html
If you don't feel like reading through it, I included some of my sample code
below to get you started. Other articles in that same series also include
usage of MD5 for creating checksums. etc.
Ibrahim Dawud
---
my ($uname,$pw1) = @_;
my $key1 = 'some_key';
my $key2 = 'some_other_key';
# Reverse password
my @char = split (//,$pw1);
@char = reverse @char;
my $pwR = join "", @char;
my $pwjoin = $pwR . $key2;
my $qry = qq ( INSERT INTO users_table
VALUES (encode('$uname','$key1'), encode('$pw1','$pwjoin') ));
my $sth = $dbh->do($qry) or bail_out("Unable to perform DO query");
---
and then to decode
my ($uname,$pw) = @_;
my $key1 = 'some_key';
my $key2 = 'some_other_key';
my @char = split (//,$pw);
@char = reverse @char;
my $pwR = join "", @char;
my $pwJ = $pwR . $key2;
$qry = qq( SELECT decode(login,'$key1'), decode(pwd,'$pwJ')
FROM users_table
WHERE decode(login,'$key1')='$uname'
AND decode(pwd,'$pwJ')='$pw');
more code here.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
