Secure Portal Authentication
I am trying to create a portal using IIS/MSSQL/PERL... I can capture user input, query user names, and verify passwords. I need to know the best way to make sure the person has authenticated and is allowed to view the restricted content. When people authenticate is there a way pass a variable, and if the variable isn't set redirect them back to the authentication page? Also, need to make sure its secure, dont want to have something in a cookie or a hidden field that could be changed to grant themselves access. Thanks in advance for the responses! Chico -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response
Re: Book Recommendation: Secure web programming ?
Hiya Randy, On Tue, Oct 04, 2005 at 03:30:23 -0400, Randy W. Sims wrote: I know perl. I know some basics of web/CGI programming, but haven't done anything where security really matters. Could anyone recommend books or references that discuss real-world web programming, that show the right way to create secure sites? Topics like creating logins, varying levels of access rights (some can edit, some can view, some have limited views), different methods of storing information storing user data (plain file, DBM, DBMS; strengths/weaknesses), what issues arise in using web hosting vs having your own server. I used to have a link to a very good (online version) of a web-based security book around, but can no longer find it, so I'll share some pe[a]rls ;) I use when working on perl/CGI web-apps: * If at all possible, use perl's built-in taint-mode - see the man-page for `perlsec' for more info on this. With taint-mode enabled, all input is tainted by default until verified to be `correct'. * Escape [shell] `meta'-characters - `', `;', '|', etc. - in all user input. This is especially important if you hand-off user-supplied input to an external program (for example, `sendmail'); * Finally, don't black-list, white-list. In other words, don't check for badly-formed, or `illegal' data, check for valid and correct data. There is just a never ending list of things that'll need black-listing (what with new types of exploits coming out daily (in certain areas)), and you'll always be playing catch-up if you go the reverse route. Also, are there any particularly good general web development books you highly recommend? If I find that link (or remember the name of the book), I'll reply with it. :) Best, Elfyn -- Elfyn McBratney Gentoo Developer/Perl Team Lead beu/irc.freenode.nethttp://dev.gentoo.org/~beu/ +O.o- http://dev.gentoo.org/~beu/pubkey.asc PGP Key ID: 0x69DF17AD PGP Key Fingerprint: DBD3 B756 ED58 B1B4 47B9 B3BD 8D41 E597 69DF 17AD pgpQ8lG1sBWL1.pgp Description: PGP signature
Re: Book Recommendation: Secure web programming ?
Elfyn == Elfyn McBratney [EMAIL PROTECTED] writes: Elfyn * Escape [shell] `meta'-characters - `', `;', '|', etc. - in all user Elfyn input. This is especially important if you hand-off user-supplied Elfyn input to an external program (for example, `sendmail'); Even better, don't let such things get near a shell. Use multi-arg exec or system, or multi-arg open to fork-and-pipe. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response
Book Recommendation: Secure web programming ?
I know perl. I know some basics of web/CGI programming, but haven't done anything where security really matters. Could anyone recommend books or references that discuss real-world web programming, that show the right way to create secure sites? Topics like creating logins, varying levels of access rights (some can edit, some can view, some have limited views), different methods of storing information storing user data (plain file, DBM, DBMS; strengths/weaknesses), what issues arise in using web hosting vs having your own server. Also, are there any particularly good general web development books you highly recommend? Thanks, Randy. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response
Re: How to secure database password? (was Re: Perl/DBI newbie: password storage / security question)
I've written a custom module (say dbConnect.PM) where the password is hard-coded and is a return value from a function (e.g., get_password()). This module is not located in a publicly-accessible folder (i.e., not in htdocs or cgi-bin). My scripts in the cgi-bin call this custom module's function which returns the password, which the scripts then use to connect to the database. An additional security (and maintenance) benefit to this implementation is that the password is stored in a single location, rather than peppered throughout my scripts. This makes regular updates of the database password fast and simple. I continue to ask the same questions you are asking, though. If anybody has better ideas or sees limitations with this solution, I'd love to hear. Todd F. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, September 17, 2003 12:04 AM Subject: How to secure database password? (was Re: Perl/DBI newbie: password storage / security question) Hello, Many thanks to R. Joseph Newton, Motherofperls, essential quint and Chuck Fox for answering my questions, however it is still not what I was asking about. My previous posts were long and maybe unclear so I'll try to get straight to the point this time, adding more details at the bottom of my post. It is actually an extremely common situation: There is a CGI script written in Perl. It is a frontend to an SQL database. The script has to connect to the database so it has to send a password. I need that password to be secure. I am not interested in security through obscurity. There are other websites on the web server and other users on the system. My solution was using SUID wrappers giving my script an EUID of a system user having only one purpose: being the only member of the only group having read privilage to a file storing the database password. The disadvantage of this solution is the large number of system users and groups (few for every website/database) and corresponding database accounts (with the minimum set of privileges each). I am quite new to Perl and particularly new to database programming, so I'd like to ask how all of you Perl gurus are solving that common problem of database password security. Is there any better solution than mine? This problem is simple and common, but if there is any better place to ask this questions, I'd be grateful for pointing me there. I have tried my best to find any related informations on the Web and Usenet archives, only to fail miserably. I will not believe that any sane person has passwords harcoded into the script itself on any production system, like it is suggested in every example of using DBI (which, as I assume, is done only for the sake of the examples simplicity). For more datails of my original questions and reasoning see: Date: Sat, 13 Sep 2003 05:09:58 -0500 (EST) Message-Id: [EMAIL PROTECTED] http://www.mail-archive.com/beginners%40perl.org/msg46845.html Date: Sat, 13 Sep 2003 21:25:55 -0500 (EST) Message-Id: [EMAIL PROTECTED] http://www.mail-archive.com/beginners%40perl.org/msg46856.html I was trying to be very clear this time, moving the most important informations to the top of my message, so everyone could know what I mean before getting lost in the details of my own reasoning. And now some details: Joseph, I was asking about database password, not password database, but speaking about the latter, I would never use a self-made custom hashing algorithm you suggested, nor would I buy any third-party RSA encryption application for that matter.[1] Also, this is not true that the hashing algorithm is any more secure as a compiled object.[2] Quint, I was not wondering whether to use RDBMS or flat files, but there are ways to make working with flat files equally convenient.[3] Of course I use HTTPS for client connections, so the users' passwords are safe in transit.[1] I use CPAN modules for everything I can and I make sure my own scripts themselves are written with security in mind.[4] Quint, you say that the argument againts flat files is that they have to be writable by the httpd process EUID, but then you propose embedding the RDBMS password in the script or module instead (readable by the server process), which essentially makes the whole database world-writable (as anyone with read access to the script or module, like everyone exploiting any other CGI script on the system, can gain full access to the database), which is absolutely unacceptable for any multiuser system connected to the Internet. Chuck, your solutions of storing the password in another database,[5] or moving the password outside the script[6] don't solve the problem, but only move it to someplace else, where it is still unsolved, not improving the security at all. Zedgar. Footnotes: [1] About the security of users' passwords: See
How to secure database password? (was Re: Perl/DBI newbie: password storage / security question)
Hello, Many thanks to R. Joseph Newton, Motherofperls, essential quint and Chuck Fox for answering my questions, however it is still not what I was asking about. My previous posts were long and maybe unclear so I'll try to get straight to the point this time, adding more details at the bottom of my post. It is actually an extremely common situation: There is a CGI script written in Perl. It is a frontend to an SQL database. The script has to connect to the database so it has to send a password. I need that password to be secure. I am not interested in security through obscurity. There are other websites on the web server and other users on the system. My solution was using SUID wrappers giving my script an EUID of a system user having only one purpose: being the only member of the only group having read privilage to a file storing the database password. The disadvantage of this solution is the large number of system users and groups (few for every website/database) and corresponding database accounts (with the minimum set of privileges each). I am quite new to Perl and particularly new to database programming, so I'd like to ask how all of you Perl gurus are solving that common problem of database password security. Is there any better solution than mine? This problem is simple and common, but if there is any better place to ask this questions, I'd be grateful for pointing me there. I have tried my best to find any related informations on the Web and Usenet archives, only to fail miserably. I will not believe that any sane person has passwords harcoded into the script itself on any production system, like it is suggested in every example of using DBI (which, as I assume, is done only for the sake of the examples simplicity). For more datails of my original questions and reasoning see: Date: Sat, 13 Sep 2003 05:09:58 -0500 (EST) Message-Id: [EMAIL PROTECTED] http://www.mail-archive.com/beginners%40perl.org/msg46845.html Date: Sat, 13 Sep 2003 21:25:55 -0500 (EST) Message-Id: [EMAIL PROTECTED] http://www.mail-archive.com/beginners%40perl.org/msg46856.html I was trying to be very clear this time, moving the most important informations to the top of my message, so everyone could know what I mean before getting lost in the details of my own reasoning. And now some details: Joseph, I was asking about database password, not password database, but speaking about the latter, I would never use a self-made custom hashing algorithm you suggested, nor would I buy any third-party RSA encryption application for that matter.[1] Also, this is not true that the hashing algorithm is any more secure as a compiled object.[2] Quint, I was not wondering whether to use RDBMS or flat files, but there are ways to make working with flat files equally convenient.[3] Of course I use HTTPS for client connections, so the users' passwords are safe in transit.[1] I use CPAN modules for everything I can and I make sure my own scripts themselves are written with security in mind.[4] Quint, you say that the argument againts flat files is that they have to be writable by the httpd process EUID, but then you propose embedding the RDBMS password in the script or module instead (readable by the server process), which essentially makes the whole database world-writable (as anyone with read access to the script or module, like everyone exploiting any other CGI script on the system, can gain full access to the database), which is absolutely unacceptable for any multiuser system connected to the Internet. Chuck, your solutions of storing the password in another database,[5] or moving the password outside the script[6] don't solve the problem, but only move it to someplace else, where it is still unsolved, not improving the security at all. Zedgar. Footnotes: [1] About the security of users' passwords: See Digest::* modules on CPAN for hashing digests. I use Data::Password::BasicCheck, Data::Password and Crypt::Cracklib (in that order) with good dictionaries to make sure the user's new password itself is secure enough (to users having problems with hard-to-guess passwords I recommend Password Safe, either the original Bruce Schneier's Counterpane Labs version, or the new one available on SourceForge). The password is stored in the database as a SHA-512 digest of the password salted with other data, as well as a large random number also stored in the database (Crypt::Random). [2] Having the hashing algorithm compiled to a native binary object improves performance, but not security (for an example see Digest::Perl::MD5 and Digest::MD5). [3] See DBD::CSV and DBD::AnyData modules for DBI interface to flat files with simple SQL queries (processed by SQL::Statement). It's great for quick prototyping, but quickly gets slow for larger files. What I personally prefer for prototyping and for any situation when there's no access to SQL database on the server, is DBD::SQLite. It's a DBI Driver
Re: How to secure database password? (was Re: Perl/DBI newbie: password storage / security question)
Zedgar, You are chasing the yourself into circles. Security is dictated by circumstances and resources available. In our case, we had plenty of both and developed for our needs the best solution. Insofar as the storing of the password for the login that is used to get the password, we took the approach of encrypting the passwords prior to inserting them in our password server and using the guest login to get the passwords (no password on guest). So a user could login to our password server as guest and get the passwords for a server, however the data is encrypted and would require our decryption module to make sense of it. Again, the point is that, secure has to be defined for your particular circumstances. If it makes more sense for you to use the OS to protect passwords, then that is your best solution. Good Luck, Chuck [EMAIL PROTECTED] wrote: Hello, Many thanks to R. Joseph Newton, Motherofperls, essential quint and Chuck Fox for answering my questions, however it is still not what I was asking about. My previous posts were long and maybe unclear so I'll try to get straight to the point this time, adding more details at the bottom of my post. It is actually an extremely common situation: There is a CGI script written in Perl. It is a frontend to an SQL database. The script has to connect to the database so it has to send a password. I need that password to be secure. I am not interested in security through obscurity. There are other websites on the web server and other users on the system. My solution was using SUID wrappers giving my script an EUID of a system user having only one purpose: being the only member of the only group having read privilage to a file storing the database password. The disadvantage of this solution is the large number of system users and groups (few for every website/database) and corresponding database accounts (with the minimum set of privileges each). I am quite new to Perl and particularly new to database programming, so I'd like to ask how all of you Perl gurus are solving that common problem of database password security. Is there any better solution than mine? This problem is simple and common, but if there is any better place to ask this questions, I'd be grateful for pointing me there. I have tried my best to find any related informations on the Web and Usenet archives, only to fail miserably. I will not believe that any sane person has passwords harcoded into the script itself on any production system, like it is suggested in every example of using DBI (which, as I assume, is done only for the sake of the examples simplicity). For more datails of my original questions and reasoning see: Date: Sat, 13 Sep 2003 05:09:58 -0500 (EST) Message-Id: [EMAIL PROTECTED] http://www.mail-archive.com/beginners%40perl.org/msg46845.html Date: Sat, 13 Sep 2003 21:25:55 -0500 (EST) Message-Id: [EMAIL PROTECTED] http://www.mail-archive.com/beginners%40perl.org/msg46856.html I was trying to be very clear this time, moving the most important informations to the top of my message, so everyone could know what I mean before getting lost in the details of my own reasoning. And now some details: Joseph, I was asking about database password, not password database, but speaking about the latter, I would never use a self-made custom hashing algorithm you suggested, nor would I buy any third-party RSA encryption application for that matter.[1] Also, this is not true that the hashing algorithm is any more secure as a compiled object.[2] Quint, I was not wondering whether to use RDBMS or flat files, but there are ways to make working with flat files equally convenient.[3] Of course I use HTTPS for client connections, so the users' passwords are safe in transit.[1] I use CPAN modules for everything I can and I make sure my own scripts themselves are written with security in mind.[4] Quint, you say that the argument againts flat files is that they have to be writable by the httpd process EUID, but then you propose embedding the RDBMS password in the script or module instead (readable by the server process), which essentially makes the whole database world-writable (as anyone with read access to the script or module, like everyone exploiting any other CGI script on the system, can gain full access to the database), which is absolutely unacceptable for any multiuser system connected to the Internet. Chuck, your solutions of storing the password in another database,[5] or moving the password outside the script[6] don't solve the problem, but only move it to someplace else, where it is still unsolved, not improving the security at all. Zedgar. Footnotes: [1] About the security of users' passwords: See Digest::* modules on CPAN for hashing digests. I use Data::Password::BasicCheck, Data::Password and Crypt::Cracklib (in that order) with good dictionaries to make sure the user's new password itself is secure enough (to users having problems with hard-to-guess
Re: Secure Form Submission
On Fri, 22 Aug 2003 20:10:37 +, [EMAIL PROTECTED] (Greenhalgh David) wrote: Thanks for that. The MD5 is a one way hash, unfortunately. I need to be able to decrypt at the server side. I agree about SSL, unfortunately my client's host (borrowed space on a non-commercial server) only has 2 IPs for SSL and both are filled until the system upgrade late this year. What I am looking for is a fill in solution that will allow some form of secure transmission of personal information (not a password) until the SSL becomes available. Well you could always use Perl scripts, and setup some socket connections. You could just ask the client to download a small script and run it, which do a safe transfer. It could be done alot of ways. The downloaded perl script could be run to encrypt a file with rc4, then the client could upload the results. The MD5 password method would give you a way to exchange an initial password safely, then that password could be used by both sides for the rc4 password. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Secure Form Submission
On Fri, 22 Aug 2003 05:48:14 +, [EMAIL PROTECTED] (Greenhalgh David) wrote: Hi All, I need to implement a form that is submitted securely. My client does not have access to SSL on his host. I was thinking in terms of a session cookie with a client side RC4 encrypt and a decrypt in the Perl script. Do peoople here consider that to be a secure scenario, or is there another method that you could recommend? The encryption needs to be reversible. There is a method using javascript http://sourceforge.net/projects/perl-md5-login/ It sends a timed out temporary key, which some javascript uses to encrypt the post. It's soo much better to use SSL. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Secure Form Submission
It seems like it should be secure. I am assuming the session cookie would store the server's public key? or some such? My question would be how do you implement an RC4 encryption (or any encryption other than the built-in SSL) on the client side? Possibly a Java applet with the encryption built-in? I suppose you could implement an encryption algorithm in javascript and then just call that via a form's onSubmit, but how would you generate a random number (built into javascript?)... yikes thats a lot of javascript :-)... and at that point you would also have to generate a private key on the client side, and send the corresponding public key to the server... and this would have to be done each time which could get slow... That was basically the plan, use the cookie to transport the key. Your comment about a lot of Javascript is precisely the daunting part. I saw in your other post about the limited IPs, if this really is a temp solution, the implementation difficulty still might suggest springing for extra hosting, or the similar until the upgrade is in place... Now there's a thought, a Summer Sale. I think I may even do it that way. Dave -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Secure Form Submission
Hi All, I need to implement a form that is submitted securely. My client does not have access to SSL on his host. I was thinking in terms of a session cookie with a client side RC4 encrypt and a decrypt in the Perl script. Do peoople here consider that to be a secure scenario, or is there another method that you could recommend? The encryption needs to be reversible. Thanks dave -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Secure Logoff from Session CGI
I have a small series of web pages that talks to a database and uses forms to input/alter data. In order to get to these web pages a user has to authenticate. If valid, I put a cookie on their machine that expires in 10 minutes. So basically, they can use the forms for up to 10 minutes, from which time they have to log back into the system. My problem is that when the user exists the web page, they can still hit the back button and see all the data they entered. This is a security issue since someone could basically sit down at the same computer and hit back to find out some vital information, assuming the original user doesn't exit the browser. I'm trying to setup something that prevents the client from just going back into the secured area by hitting back. I notice that on systems such as Wells Fargo's online banking, once you logoff, you cannot hit back to get back to your account. This is exactly what I'm trying to do, yet I have been unable to find out how to accomplish this. I already have all the no-cache meta options in my HTML. What would be perfect would be if there were a perl/CGI function that could detect if the user is going back to the .cgi file via the back button and then act how you choose. However, I feel there should be an even easier way about this. Any ideas? Thank you, Sean Abrahams SFSU : Fiscal Affairs Business Systems [EMAIL PROTECTED] -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Secure Logoff from Session CGI
I'm not sure, but how do you set a cookie and have it expire in ten minutes? -Rob --- Sean Abrahams [EMAIL PROTECTED] wrote: I have a small series of web pages that talks to a database and uses forms to input/alter data. In order to get to these web pages a user has to authenticate. If valid, I put a cookie on their machine that expires in 10 minutes. So basically, they can use the forms for up to 10 minutes, from which time they have to log back into the system. My problem is that when the user exists the web page, they can still hit the back button and see all the data they entered. This is a security issue since someone could basically sit down at the same computer and hit back to find out some vital information, assuming the original user doesn't exit the browser. I'm trying to setup something that prevents the client from just going back into the secured area by hitting back. I notice that on systems such as Wells Fargo's online banking, once you logoff, you cannot hit back to get back to your account. This is exactly what I'm trying to do, yet I have been unable to find out how to accomplish this. I already have all the no-cache meta options in my HTML. What would be perfect would be if there were a perl/CGI function that could detect if the user is going back to the .cgi file via the back button and then act how you choose. However, I feel there should be an even easier way about this. Any ideas? Thank you, Sean Abrahams SFSU : Fiscal Affairs Business Systems [EMAIL PROTECTED] -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/ -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is this secure
There are probably multiple issues with this script. I don't really have
the time to do a security audit for you but in a 5 minute glance
A) -t is supposed to be -T if you are enabling taint mode
B) It appears as if there is very little checking done on the path that is
issued. Things like
escaped periods would allow backtracking
possible null byte insertion in the regex would obviate the file extension
C) File open is done without explicitly putting in a prefix to indicate
read-only access. So if the path starts or ends with | then an arbitrary
command could be executed.
Some of these might not work in practice, but I don't see an explicit area
of the code which basically prevents these things from occuring, so I can
only suspect it is possible with enough diligence.
I would suggest that if your site is using mod_perl, don't use some
home-grown template system. There are way too many out there that are
reallly well written and well-tested and examined for security. State your
requirements and ask the mod-perl list for some advice.
There are really powerful ones like TemplateToolkit, Mason, EmbPerl, but
then there are simpler ones also. And the #1 thing is that if you see
someone trying to roll their own template system, STOP THEM!! :)
It's really annoying to reinvent the wheel that's already been reinvented
many times.
Later,
Gunther
At 01:18 AM 2/14/2002, Rednecktek wrote:
I've been asked if this script is secure. I believe it is. Can anyone find
any problems with it?
#!/usr/bin/perl -w -t
use strict;
use Apache;
$ENV{GATEWAY_INTERFACE} =~ /^CGI-Perl/ or die GATEWAY_INTERFACE not Perl!;
my $r = Apache-request();
my %args = $r-args();
my $path = $r-uri;
###
$path =~ s/\/(.*?)$//; # Strip off the scriptname
my $tmplpath = template/; # Setup the template path
my $cont_ext = .html; # Allow only content files with this extension
my $tmpl_ext = .tmpl; # Allow only template files with this extension
my $template = $tmplpath .mcti. $tmpl_ext; # Setup the template path
my $page = $args{page} || index; # Are we requesting a page or root?
my $title = Microdyne; # Default Title of not specified in page
my $debug = 1;
###
my ($content, $pageout, $newtitle, $newtmpl);
($content, $newtitle, $newtmpl) = pullpage( $page . $cont_ext );
if ($newtitle) {$title = $newtitle;}
if ($newtmpl) {$template = $tmplpath . $newtmpl . $tmpl_ext;}
$pageout = readfile( $template );
$pageout =~ s/%%TITLE%%/$title/g;
$pageout =~ s/%%CONTENT%%/$content/g;
pageout($pageout);
# Spit out the content
sub pageout {
my $pageout = shift;
$r-content_type('text/html');
$r-header_out( 'Content-Length', length($pageout) );
$r-send_http_header();
my $start = 0;
my $len = 63000;
while (my $p = substr($pageout, $start, $len)) {
$start += $len;
$r-print($p);
}
$r-rflush();
}
# Open content page, and check for options
# checks for tags in format: %%TAG=VALUE%%
sub pullpage {
my $file = shift;
my ($content, $title, $template);
$content = readfile( $file );
while ($content =~ m/%%(.*?)=(.*?)%%/) {
my $key = $1;
my $value = $2;
SWITCH: for ($key) {
/TEMPLATE/ do {
# Override default template
logit(Found $key - $value,2);
$template = $value;
$content =~ s/%%$key=$value%%//g;
last SWITCH;
};
/TITLE/ do {
logit(Found $key - $value,2);
$title = $value;
$content =~ s/%%$key=$value%%//g;
last SWITCH;
};
/INCLUDE/ do {
#Read in an Included file
logit(Found $key - $value,2);
my $repl = readfile( $value );
$content =~ s/%%$key=$value%%/$repl/g;
last SWITCH;
};
};
}
return ($content, $title, $template);
}
# Reads a file and returns the content
sub readfile {
my $file = shift;
my $rv;
logit(Opening file $file,2);
open( FILE, $file ) || return Could not find file $file;
my @lines = FILE;
close FILE || return Could not close filehandle;
logit(Closed file $file,2);
for (@lines) {
$rv .= $_;
}
return $rv;
}
sub logit {
my $warning = shift;
my $level = shift || 1;
my $caller = (caller(1))[3];
if ($debug = $level) {
warn $caller:\t$warning;
}
}
1;
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Open Web Technology Company
http://www.eXtropia.com/
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Re: Is this secure
+ACI-Gunther Birznieks+ACI- wrote: +AD4- There are probably multiple issues with this script. I don't really have +AD4- the time to do a security audit for you but in a 5 minute glance +AD4- +AD4- A) -t is supposed to be -T if you are enabling taint mode Doh+ACE- Missed that one. +AD4- B) It appears as if there is very little checking done on the path that is +AD4- issued. Things like +AD4-escaped periods would allow backtracking +AD4-possible null byte insertion in the regex would obviate the file extension +AD4- C) File open is done without explicitly putting in a +ACIAPAAi- prefix to indicate +AD4- read-only access. So if the path starts or ends with +AHw- then an arbitrary +AD4- command could be executed. I couldn't introduce errors using the null-byte, but I won't stop testing just yet. I have no idea to escape a period on the URL. Could someone give me an example please. +AD4- Some of these might not work in practice, but I don't see an explicit area +AD4- of the code which basically prevents these things from occuring, so I can +AD4- only suspect it is possible with enough diligence. +AD4- +AD4- I would suggest that if your site is using mod+AF8-perl, don't use some +AD4- home-grown template system. There are way too many out there that are +AD4- reallly well written and well-tested and examined for security. State your +AD4- requirements and ask the mod-perl list for some advice. Thanks, but nope, this is a test project. +AD4- There are really powerful ones like TemplateToolkit, Mason, EmbPerl, but +AD4- then there are simpler ones also. And the +ACM-1 thing is that if you see +AD4- someone trying to roll their own template system, STOP THEM+ACEAIQ- :) +AD4- +AD4- It's really annoying to reinvent the wheel that's already been reinvented +AD4- many times. No offense, but I don't want to +ACI-stand on the shoulders of giants.+ACI- Part of the reason I'm doing this is to understand the security issues involved, even in a simple script like this. I know there is always more to learn, now I know /what/ I need to learn. cya, Jon +AD4- Later, +AD4- Gunther +AD4- +AD4- At 01:18 AM 2/14/2002, Rednecktek wrote: +AD4- +AD4-I've been asked if this script is secure. I believe it is. Can anyone find +AD4- +AD4-any problems with it? +AD4- +AD4- +AD4- +AD4AIwAh-/usr/bin/perl -w -t +AD4- +AD4-use strict+ADs- +AD4- +AD4-use Apache+ADs- +AD4- +AD4AJA-ENV+AHs-GATEWAY+AF8-INTERFACE+AH0- +AD0Afg- /+AF4-CGI-Perl/ or die ++ACI-GATEWAY+AF8-INTERFACE not Perl+ACEAIgA7- +AD4- +AD4-my +ACQ-r +AD0- Apache-+AD4-request()+ADs- +AD4- +AD4-my +ACU-args +AD0- +ACQ-r-+AD4-args()+ADs- +AD4- +AD4-my +ACQ-path +AD0- +ACQ-r-+AD4-uri+ADs- +AD4- +AD4- +AD4- +AD4AIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACM- +ACM- +AD4- +AD4AIwAjACM- +AD4- +AD4AJA-path +AD0Afg- s/+AFw-/(.+ACo-?)+ACQ-//+ADs- +ACM- Strip off the +scriptname +AD4- +AD4-my +ACQ-tmplpath +AD0- +ACI-template/+ACIAOw- +ACM- Setup the template path +AD4- +AD4-my +ACQ-cont+AF8-ext +AD0- +ACI-.html+ACIAOw- +ACM- Allow only content +files with this extension +AD4- +AD4-my +ACQ-tmpl+AF8-ext +AD0- +ACI-.tmpl+ACIAOw- +ACM- Allow only template +files with this extension +AD4- +AD4-my +ACQ-template +AD0- +ACQ-tmplpath .+ACI-mcti+ACI-. ++ACQ-tmpl+AF8-ext+ADs- +ACM- Setup the template path +AD4- +AD4-my +ACQ-page +AD0- +ACQ-args+AHs-page+AH0- +AHwAfA- +ACI-index+ACIAOw- ++ACM- Are we requesting a page or root? +AD4- +AD4-my +ACQ-title +AD0- +ACI-Microdyne+ACIAOw- +ACM- Default Title of not +specified in page +AD4- +AD4-my +ACQ-debug +AD0- 1+ADs- +AD4- +AD4AIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACM- +ACM- +AD4- +AD4AIwAjACM- +AD4- +AD4-my (+ACQ-content, +ACQ-pageout, +ACQ-newtitle, +ACQ-newtmpl)+ADs- +AD4- +AD4- +AD4- +AD4-(+ACQ-content, +ACQ-newtitle, +ACQ-newtmpl) +AD0- pullpage( +ACQ-page . ++ACQ-cont+AF8-ext )+ADs- +AD4- +AD4-if (+ACQ-newtitle) +AHsAJA-title +AD0- +ACQ-newtitle+ADsAfQ- +AD4- +AD4-if (+ACQ-newtmpl) +AHsAJA-template +AD0- +ACQ-tmplpath . +ACQ-newtmpl . ++ACQ-tmpl+AF8-ext+ADsAfQ- +AD4- +AD4AJA-pageout +AD0- readfile( +ACQ-template )+ADs- +AD4- +AD4AJA-pageout +AD0Afg- s/+ACUAJQ-TITLE+ACUAJQ-/+ACQ-title/g+ADs- +AD4- +AD4AJA-pageout +AD0Afg- s/+ACUAJQ-CONTENT+ACUAJQ-/+ACQ-content/g+ADs- +AD4- +AD4- +AD4- +AD4-pageout(+ACQ-pageout)+ADs- +AD4- +AD4- +AD4- ++AD4AIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAj- +AD4- +AD4AIw- Spit out the content +AD4- ++AD4AIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAjACMAIwAj- +AD4- +AD4-sub pageout +AHs- +AD4- +AD4- my +ACQ-pageout +AD0- shift+ADs- +AD4- +AD4
trying to secure text input.
Below is the code i'm using to filter out non alphanumeric charecters... however when
i type
?!$BOB
yeilds this:
-_3f_21_24bob-
The ?!$ should be stripped away and come back empty, not
_3f_21_24
ANY ideas as to what I'm doing wrong???
I'm asking for an email address.
my $eaddress = ;
read(STDIN,$buffer,$ENV{'CONTENT_LENGTH'});
$eaddress = $buffer;
###
@list=split(//,$eaddress);
$eaddress=$list[0];
@list=split(/\=/,$eaddress);
$eaddress=$list[1];
$eaddress=~tr/A-Z/a-z/;##changes everything to lowercase !!! THIS
WORKS !!!
$eaddress=~tr/a-z0-9/_/c; ##changes everything but a-z 0-9 to _
print -$password-;
Fwd: [perlguy@perlguy.com: [REDIRECT] Re: Perl and secure CGI]
- Forwarded message from Kevin Meltzer [EMAIL PROTECTED] - I am redirecting this to the cgi-beginners list, which is more appropriate. Please send responses to the sender (Edd Dawson [EMAIL PROTECTED]) and the cgi-beginners list. Thanks. Cheers, Kevin On Tue, Oct 09, 2001 at 04:29:06PM +0100, Edd Dawson ([EMAIL PROTECTED]) said something similar to: Hi, I have created a secure website using Perl and the CGI module, LDAP module, and HTML::Template module, Basically I authenticate a user to Novell via LDAP, then control access to HTML files using HTML::template. Now I need to add controlled access to a pdf file on the server, and I'd like to use a Perl method to do this similar to the template method. Has anyone else ever tried this or know of any modules that might help me achieve this? Thanks for your time Edd Dawson -- -- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - End forwarded message - -- [Writing CGI Applications with Perl - http://perlcgi-book.com] Seen the city, seen the zoo, traffic light won't let me through. -- Phish (Slave to the Traffic Light) -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
secure scripts
anyone have a url that is a decent intro for writing secure cgi scripts? -charles
Re: secure scripts
--- [EMAIL PROTECTED] wrote: anyone have a url that is a decent intro for writing secure cgi scripts? -charles Best bet (IMHO): read section 6 of http://www.w3.org/Security/faq/ Also, Lesson 3 (http://www.easystreet.com/~ovid/cgi_course/lesson_three/lesson_three.html) of my Perl/CGI course has some good, basic information about this. It'll give you a good start on many of the basics, but is not as comprehensive as the above faq. 'perldoc perlsec' is also good. An online version is at http://www.perldoc.com/perl5.6/pod/perlsec.html Cheers, Curtis Poe = Senior Programmer Onsite! Technology (http://www.onsitetech.com/) Ovid on http://www.perlmonks.org/ __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/
