Re: CGI Scripts and IE
On Mon, Sep 25, 2006 at 10:53:15AM -0400, Shawn Hinchy wrote:
Everything works fine in Mozilla/Firefox but when I try to use IE 6,
it doesn't seem to call the script when the submit button is pressed,
kind of like it knows it is already loaded and just reloads it from
cache. Is this possible? How do I overcome it?
The script acts differently whether it is called with no parameters or
whether it is called after the submit button press and has parameters
(action=validate, etc).
I'd /guess/ that you have something like button type=submit
name=foo value=bazBar/button, and you are testing for
$q-param('foo') eq 'baz' and falling over IE's problem of sending
Bar as the value.
... but you haven't provided anywhere near enough information about
the problem to say for sure. Real URL? HTML? Perl?
--
David Dorward http://dorward.me.uk
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response
Re: cgi scripts as root or similar - best method
Are you sure that cdrecord needs to run as root? You might check into changin permissions on the device itself. Or if this is a trusted machine/environment (I assume it is, 'cause most people don't write web apps to burn CDs), then you could suid cdrecord itself as root. Be sure you understand the security implications of doing that. Paul 10:08am, Gavin Henry wrote: Dear all, I have a working cgi script, well from the commandline. I haven't enabled -T, but that will be next. I am using $|++ and CGI::Carp to get things to stdout etc. and show me errors. All the script does is creates an ISO file, writes a log and burns the CD with some Javascript quesions to ask if the user wants to continue. I could paste the code, but I don't think it's relevant to my question. What the problem is, is that the ISO and log file are to be saved in non apache2 owned directories and cdrecord needs to be run as root. I have tried changing the group ownership of these dirs and chmod 775 for them, but apache2 still can't write to them. I have looked into suexec, but I am not running VirtualHosts and I have tried just making the scripts setuid, but apache2 won't run them then. I have seen suidperl, but I am not sure what it does. Basically I have tried everything I know at present, read all the perlfaq9 and relevant CGI FAQ etc. Does someone with more experience have any tips, as I am now at a loss. Thanks. -- Just getting into the best language ever... Fancy a [EMAIL PROTECTED] Just ask!!! -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response They're willing to kill people. That makes them dangerous. --News announcer, about South American drug lords -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response
Re: cgi scripts as root or similar - best method
On Fri, 25 Feb 2005, Gavin Henry wrote: [...] the problem is [...] cdrecord needs to be run as root. I assume cdrecord is being invoked from a system command, right? Have you considered prefixing that command with `sudo`, and going into the sudoers file to allow the www user that privilige? Of course, it would be a bit more complicated than that, as sudo will prompt for a password that you have to pass back to it somehow, but after hurdle that I suspect that it should work fine... Alternatively, have you considered using Webmin? Webmin is a way to do various system administration tasks through a web browser, and there appears to be a cdrecord based plugin for it: http://kgolding.co.uk/cd2iso.php Webmin site: http://webmin.com/ The Book of Webmin (not pirated -- it's at the author's site): http://www.swelltech.com/support/webminguide/ This may be an easier approach to the problem... -- Chris Devers -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response
Re: cgi scripts as root or similar - best method
quote who=Chris Devers
On Fri, 25 Feb 2005, Gavin Henry wrote:
[...] the problem is [...] cdrecord needs to be run as root.
I assume cdrecord is being invoked from a system command, right?
I know have it running fine using -T and declaring ENN{PATH} as according
to the Security section of the camel.
Yeah, I have:
!system (blah, blah) or die blah, blah;
Have you considered prefixing that command with `sudo`, and going into
the sudoers file to allow the www user that privilige?
No.
Of course, it would be a bit more complicated than that, as sudo will
prompt for a password that you have to pass back to it somehow, but
after hurdle that I suspect that it should work fine...
I could actually do that for each system command, could I use the expect
perl module for that?
Alternatively, have you considered using Webmin? Webmin is a way to do
various system administration tasks through a web browser, and there
appears to be a cdrecord based plugin for it:
http://kgolding.co.uk/cd2iso.php
It needs to be scripted via an independant sgi script though :-(
Webmin site:
http://webmin.com/
The Book of Webmin (not pirated -- it's at the author's site):
http://www.swelltech.com/support/webminguide/
This may be an easier approach to the problem...
Thanks.
--
Chris Devers
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response
Re: cgi scripts as root or similar - best method
Chris Devers wrote: On Fri, 25 Feb 2005, Gavin Henry wrote: [...] the problem is [...] cdrecord needs to be run as root. I assume cdrecord is being invoked from a system command, right? Have you considered prefixing that command with `sudo`, and going into the sudoers file to allow the www user that privilige? Of course, it would be a bit more complicated than that, as sudo will prompt for a password that you have to pass back to it somehow, but after hurdle that I suspect that it should work fine... [snip] You can use the 'NOPASSWD' flag in the sudoers file for a particular command/alias, etc. so that the user does not have to enter a password. man sudoers http://danconia.org -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response
Re: cgi scripts as root or similar - best method
-- Just getting into the best language ever... Fancy a [EMAIL PROTECTED] Just ask!!! quote who=Wiggins d'Anconia Chris Devers wrote: On Fri, 25 Feb 2005, Gavin Henry wrote: [...] the problem is [...] cdrecord needs to be run as root. I assume cdrecord is being invoked from a system command, right? Have you considered prefixing that command with `sudo`, and going into the sudoers file to allow the www user that privilige? Of course, it would be a bit more complicated than that, as sudo will prompt for a password that you have to pass back to it somehow, but after hurdle that I suspect that it should work fine... [snip] You can use the 'NOPASSWD' flag in the sudoers file for a particular command/alias, etc. so that the user does not have to enter a password. man sudoers Excellent, I forgot that. But that's not very system independant, but ut's fair enough, as it's on only one box and I AM using syste commands. P.S. I love the beginners lists!!! http://danconia.org -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response
RE: cgi scripts as root or similar - best method
Chris Devers [EMAIL PROTECTED] suggested: Have you considered prefixing that command with `sudo`, and going into the sudoers file to allow the www user that privilige? Of course, it would be a bit more complicated than that, as sudo will prompt for a password that you have to pass back to it somehow, but after hurdle that I suspect that it should work fine... From man sudoers: By default, sudo requires that a user authenticate him or herself before running a command. This behavior can be modified via the NOPASSWD tag. Like a Runas_Spec, the NOPASSWD tag sets a default for the commands that follow it in the Cmnd_Spec_List. Conversely, the PASSWD tag can be used to reverse things. For example: rayrushmore = NOPASSWD: /bin/kill, /bin/ls, /usr/bin/lprm would allow the user ray to run /bin/kill, /bin/ls, and /usr/bin/lprm as root on the machine rushmore as root without authenticating himself. HTH, Thomas -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response
Re: cgi scripts
Larry Adamiec wrote:
How do I get the form data to the MS window ASP script using the
POST method? I have tried using the GET method successfully (
print Location: http://ip_address?ENV{'QUERY_STRING;'} ) but I
don't want any data in the URL.
Check out the libwww-perl package, e.g. LWP::UserAgent.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response
Re: CGI scripts, security and MySQL
On Fri, 3 Sep 2004, michael watson (IAH-C) wrote: I need to make this secure such that only users I want can use the system. I want to set up a username and password so that users can log in once at the beginning of a session, carry out their work filling in various forms and writing to the database, and then log-out at the end. What is the best way to do this? I've thought about creating a MySQL user/password for each person who needs to enter data, but I don't want them to have to enter their username and password on every form. I guess what I need is some sort of persistant DBI connection that is present over multiple runs of various CGI scripts (until the person logs off or the browser is closed...) I am running Suse Linux 8.2, MySQL 4, Apache 1.3.28 and perl 5.8.0 Think about what your requirements are here; you seem to have a grab bag of good ideas that are all mixed up together. * System authentication You're asking for a way to avoid making people fill out their username password with each form. A proper authentication system won't allow this situation. The two basic ways you can do authentication are at the server level, with Apache-enforced HTTP authentication (this is the version where the, and at the application level, with code in your CGI scripts that manages user account details. I personally think Apache-level authentication is easier -- if you just add the right directives to your httpd.conf, it's magically turned on for you. For whatever reason though, this isn't often done these days -- it's more popular to reinvent this particular wheel over and over again. If you go for the more popular application level logins, the general approach will mean storing the user's account name in a cookie, and then checking this cookie with each request. As long as the cookie has the right information, they won't have to log in with each page -- it will, in effect, do that automatically in the background. * Database users: I suspect it's not so important to control who's user account is writing to the database, as much as it is to know who wrote what data in the database. Make sense? With that in mind, you could do either or both of [a] add fields to the tables that note who last touched each row, or (probably better) [b] maintain a log of what changes are being made and by who -- this log could even be as simple as a datestamp, the user name, and the SQL statement. This should make maintainence of the database easier, as you don't have to maintain separate MySQL accounts for each user along with the other accounts they are going to need. * DBI connection persistence: It makes sense to maintain a connection to the database, but not so much because of user access control considerations, but just for performance: being able to avoid building up tearing down a DB connection with every page view gets very expensive. The best way to get around this is probably to use mod_perl instead of regular CGI scripts, and then turn on Apache::DBI for database connection pooling. This can help a lot. Does this help ? More questions ? -- Chris Devers [EMAIL PROTECTED] http://devers.homeip.net:8080/blog/ np: 'Mr. Loh's Not Afraid to Be Naked' by Sandra Tsing Loh from 'This American Life: Lies, Sissies, and Fiascoes' -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response
Re: CGI scripts, security and MySQL
Hi, You can put something like this, in httpd.conf file: include ...path_to_file And make the directory where sits that file readable only by the root user. Then, in that file, put something like: SetEnv usr user_name SetEnv pass parolissima Those 2 environment variables will be seen by any script that runs on that server. If you want them to be seen only by the scripts which are ran by a certain virtualhost, put that include line between virtualhost... and /virtualhost. T - Original Message - From: Chris Devers [EMAIL PROTECTED] To: michael watson (IAH-C) [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, September 03, 2004 3:08 PM Subject: Re: CGI scripts, security and MySQL On Fri, 3 Sep 2004, michael watson (IAH-C) wrote: I need to make this secure such that only users I want can use the system. I want to set up a username and password so that users can log in once at the beginning of a session, carry out their work filling in various forms and writing to the database, and then log-out at the end. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response
Re: CGI scripts, security and MySQL
No, the environment variables are set a single time at the start (or restart) of the web server. The problem is that if there is any change in httpd.conf file, the server must be restarted and this might not be very easy for a system with very many users, but it is not impossible. Teddy - Original Message - From: Chris Devers [EMAIL PROTECTED] To: Octavian Rasnita [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; michael watson (IAH-C) [EMAIL PROTECTED] Sent: Friday, September 03, 2004 3:31 PM Subject: Re: CGI scripts, security and MySQL On Fri, 3 Sep 2004, Octavian Rasnita wrote: You can put something like this, in httpd.conf file: include ...path_to_file And make the directory where sits that file readable only by the root user. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response
Re: CGI scripts, security and MySQL
On Fri, 3 Sep 2004, Octavian Rasnita wrote: No, the environment variables are set a single time at the start (or restart) of the web server. Ok, that's what I thought. So in what way does this help manage a pool of several users? This seems to be a solution in search of some other problem... -- Chris Devers [EMAIL PROTECTED] http://devers.homeip.net:8080/blog/ np: 'Drama Bug' by David Sedaris from 'This American Life: Lies, Sissies, and Fiascoes' -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response
Re: CGI scripts, security and MySQL
This might be helpful for more users, because a system admin can create automaticly a special dir where the users can put their config files, and insert that file in httpd.conf. After that, every user can create its own config file, with any variables they want (their names should not be only user and pass), and after that chmod that special dir in order to be viewd only by the root. T Teddy - Original Message - From: Chris Devers [EMAIL PROTECTED] To: Octavian Rasnita [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; michael watson (IAH-C) [EMAIL PROTECTED] Sent: Friday, September 03, 2004 3:56 PM Subject: Re: CGI scripts, security and MySQL -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response
Re: CGI scripts, security and MySQL
On Fri, 3 Sep 2004, Octavian Rasnita wrote: This might be helpful for more users, because a system admin can create automaticly a special dir where the users can put their config files, and insert that file in httpd.conf. After that, every user can create its own config file, with any variables they want (their names should not be only user and pass), and after that chmod that special dir in order to be viewd only by the root. This is all nice to know, but it doesn't appear to have anything at all to do with the questions that the guy was asking. He wants web site user accounts, with control /or a record of who is doing what in the database. He wants some kind of database connection persistance. He is not trying to set environment variables in Apache. It isn't obvious how setting variables like this gets him anywhere near the stated requirements of the system. -- Chris Devers [EMAIL PROTECTED] http://devers.homeip.net:8080/blog/ np: 'Christmas Freud' by David Rakoff from 'This American Life: Lies, Sissies, and Fiascoes' -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response
Re: CGI Scripts
Wiggins d'Anconia wrote:
So since you are not using the OOP interface to CGI, you need to tell
Perl to bring the functions into the local namespace so you can use them
in the way you are, so something like:
use CGI qw/:standard/; # load standard CGI routines
Should help matters greatly. There are two other options, switch to the
OOP interface and request a new CGI object then call the function (now a
method) on the object instance, or practice your typing by including the
full name everywhere:
my $customer = CGI::param('Customer');
Be sure to undersand what and how :standard works, and what other
options are available.
Ok, Thanks but I think I'm still a little baffle here about the
difference in using OOP interface and not using OOP interface.
Could you clarify the difference?
--
*** Phillip B. Bruce ***
*** ***
*** Politicians and diapers have one thing in common. ***
*** They should both be changed regularly and for the ***
*** same reason. ***
*** ***
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI Scripts
Wiggins d'Anconia wrote: In the following line you need a 'my' to give the variable scope $mail = Mail::Internet-new(Header = $head, Body = [$body], Modify = 1); Ok, I did that and now I'm getting this error ./survey.cgi Content-type: text/html Undefined subroutine main::param called at ./survey.cgi line 12. So that is referenceing the following line my code: my $customer = param(Customer); So does Customer in the param setting needs to be $Customer maybe? -- *** Phillip B. Bruce *** *** *** *** Politicians and diapers have one thing in common. *** *** They should both be changed regularly and for the *** *** same reason. *** *** *** -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI Scripts
Phillip Bruce wrote:
Wiggins d'Anconia wrote:
In the following line you need a 'my' to give the variable scope
$mail = Mail::Internet-new(Header = $head,
Body = [$body],
Modify = 1);
Ok, I did that and now I'm getting this error
./survey.cgi
Content-type: text/html
Undefined subroutine main::param called at ./survey.cgi line 12.
So that is referenceing the following line my code:
my $customer = param(Customer);
So does Customer in the param setting needs to be $Customer maybe?
This error is telling you that the compiler can't find the 'param'
subroutine in the 'main' package. The key here is that the 'param'
subroutine is part of the CGI package which you should (and with
experience) know. So the question becomes how do I get 'param' to work
in my script when I have already done a
use CGI;
at the top. Without going into details about 'import', etc. read:
perldoc perlsub
perldoc perlmod
for more.
Essentially you should revisit the section on Programming Style in the
CGI.pm docs, in particular the statement:
The main differences are that we now need to import a set of functions
into our name space (usually the standard functions), and we don't
need to create the CGI object.
So since you are not using the OOP interface to CGI, you need to tell
Perl to bring the functions into the local namespace so you can use them
in the way you are, so something like:
use CGI qw/:standard/; # load standard CGI routines
Should help matters greatly. There are two other options, switch to the
OOP interface and request a new CGI object then call the function (now a
method) on the object instance, or practice your typing by including the
full name everywhere:
my $customer = CGI::param('Customer');
Be sure to undersand what and how :standard works, and what other
options are available.
http://danconia.org
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI Scripts
Wiggins d'Anconia wrote:
Phillip Bruce wrote:
Wiggins d'Anconia wrote:
snip
Thanks for the suggestions. Now I get totally different error. I ran
this on the command line and get following:
% ./survey.cgi
Content-type: text/html
Substitution replacement not terminated at ./survey.cgi line 37.
Here is my code changes I've made:
#!/usr/local/bin/perl
use strict;
user warnings;
In the above line you have 'user' instead of 'use'
use CGI;
use Mail::Internet;
BEGIN {
print Content-type: text/html\n\n;
} # So we can debug using the web
# Collect parameters using CGI
my $customer = param(Customer);
my $learn = param(Learn);
my $opinion = param(Site Opinion);
my $improvements = param(Site Iimprovement);
my $comments = param(comments);
my $head = Mail::Header-new;
# add an error handler here for the above
$head-add(From = 'Webmaster [EMAIL PROTECTED]');
$head-add(To = '[EMAIL PROTECTED]');
$head-add(Subject = 'Peggy's Health Center Survey Response');
In the above literal you have an embedded single quote which must be
escaped or you need to change the quoting method. To escape a single
quote in a single quoted literal throw a backslash before it...
'Peggy\'s Health Center Survey Response', that *should* be the reason it
is failing
# Build the body of your message
my $body = END;
The following information has been sent via form:
Customer Type: $customer
Where They Found US: $learn
Site Opinion: $opinion
Site Improvements: $improvements
Comments: $comments
END
#Send the message
$mail = Mail::Internet-new(Header = $head,
Body= [$body],
Modify = 1);
print $mail-end('sendmail');
=== End of Code ===
Any ideas why I'm getting that error:
I'm using 5.8 version of perl and
have an older version 5.005_03
that does the same thing.
Stick with 5.8 unless you need the older version for some reason...
http://danconia.org
Well,
I'm using perl 5.8 and I'm now getting these error messages.
% ./survey.cgi
Content-type: text/html
Global symbol $mail requires explicit package name at ./survey.cgi
line 37.
Global symbol $mail requires explicit package name at ./survey.cgi
line 41.
Global symbol $mail requires explicit package name at ./survey.cgi
line 42.
Execution of ./survey.cgi aborted due to compilation errors.
Below is my code as it stands right now.
#!/usr/local/bin/perl
use strict;
use warnings;
use CGI;
use Mail::Internet;
BEGIN {
print Content-type: text/html\n\n;
} # So we can debug using the web
# Collect parameters using CGI
my $customer = param(Customer);
my $learn = param(Learn);
my $opinion = param(Site Opinion);
my $improvements = param(Site Iimprovement);
my $comments = param(comments);
my $head = Mail::Header-new;
# add an error handler here for the above
$head-add(From = 'Webmaster [EMAIL PROTECTED]');
$head-add(To = '[EMAIL PROTECTED]');
$head-add(Subject = 'Peggy\'s Health Center Survey Response');
# Build the body of your message
my $body = END;
The following information has been sent via form:
Customer Type: $customer
Where They Found US: $learn
Site Opinion: $opinion
Site Improvements: $improvements
Comments: $comments
END
#Send the message
$mail = Mail::Internet-new(Header = $head,
Body = [$body],
Modify = 1);
print $mail-send('sendmail');
$mail-close;
print H3Return to Peggy's Health Center Web Site/H3;
--
*** Phillip B. Bruce ***
*** ***
*** Politicians and diapers have one thing in common. ***
*** They should both be changed regularly and for the ***
*** same reason. ***
*** ***
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI Scripts
Phillip Bruce wrote:
Wiggins d'Anconia wrote:
snip
Well,
I'm using perl 5.8 and I'm now getting these error messages.
The errors you are getting now are because of the stricture. You have
to declare the scope of all of your variables (among other things).
perldoc strict
For more info When debugging the script start with the first error,
determine where it is being caused (line 37) and what its likely
solution is. In this case the variable $mail has not been properly
scoped and its first usage is on line 37. Sometimes you will get this
error if you misname a variable, etc.
% ./survey.cgi
Content-type: text/html
Global symbol $mail requires explicit package name at ./survey.cgi
line 37.
Global symbol $mail requires explicit package name at ./survey.cgi
line 41.
Global symbol $mail requires explicit package name at ./survey.cgi
line 42.
Execution of ./survey.cgi aborted due to compilation errors.
Below is my code as it stands right now.
#!/usr/local/bin/perl
use strict;
use warnings;
use CGI;
use Mail::Internet;
BEGIN {
print Content-type: text/html\n\n;
} # So we can debug using the web
# Collect parameters using CGI
my $customer = param(Customer);
my $learn = param(Learn);
my $opinion = param(Site Opinion);
my $improvements = param(Site Iimprovement);
my $comments = param(comments);
my $head = Mail::Header-new;
# add an error handler here for the above
$head-add(From = 'Webmaster [EMAIL PROTECTED]');
$head-add(To = '[EMAIL PROTECTED]');
$head-add(Subject = 'Peggy\'s Health Center Survey Response');
# Build the body of your message
my $body = END;
The following information has been sent via form:
Customer Type: $customer
Where They Found US: $learn
Site Opinion: $opinion
Site Improvements: $improvements
Comments: $comments
END
#Send the message
In the following line you need a 'my' to give the variable scope
$mail = Mail::Internet-new(Header = $head,
Body = [$body],
Modify = 1);
print $mail-send('sendmail');
$mail-close;
print H3Return to Peggy's Health Center Web Site/H3;
http://danconia.org
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI Scripts
Phillip Bruce wrote:
Hi,
I have the following form that I use as survey I that I'm
building for my web site.
snip form
Now here is the CGI script I've written so far.
#!/usr/bin/perl
#
use Mail::Internet;
use strict; # always
use warnings; # usually, at least during development
# Collect parameters using CGI
my $customer = param(Customer);
my $learn = param(Learn);
my $opinion = param(Site Opinion);
my $improvements = param(Site Iimprovement);
my $comments = param(comments);
In the above section you are using a function of the CGI module 'param'
but you have not loaded the CGI module, you need another use statement:
use CGI;
You may also want to get all the params at once into a hash, but I leave
that to you, have a look at the docs for the CGI module:
perldoc CGI
my $head = Mail::Header-new;
What does this do on failure? you haven't checked return codes...
$head-add(From = 'Webmaster [EMAIL PROTECTED]');
$head-add(To = '[EMAIL PROTECTED]');
$head-add(Subject = 'hello there');
my $body = END;
This is just a simple e-mail message.
Nothing to get excited about.
Customer Type: $customer
How they learn of us: $learn
Their Opinions: $opinion
Their improvemetns: $improvements
Their comments: $comments
END
$mail = Mail::Internet-new(Header = $head,
Body = [$body],
Modify = 1);
print $mail-send('sendmail');
You have not printed a header back to the browser, usually something
like: Content-type:text/html\n\n, though again see the docs for the CGI
module for easy ways to do this.
end of cgi script.
What I'm concern with is the execution of this script.
I don't seem to be doing something right. Can someone
correct on what it that missing.
Usually the best way to find out problems with a CGI script is to check
the server's error log, or use a 'fatalstobrowser' type of deal, see the
CGI docs for this also...
http://danconia.org
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI Scripts
Wiggins d'Anconia wrote:
Phillip Bruce wrote:
Hi,
I have the following form that I use as survey I that I'm
building for my web site.
snip form
Now here is the CGI script I've written so far.
#!/usr/bin/perl
#
use Mail::Internet;
use strict; # always
use warnings; # usually, at least during development
# Collect parameters using CGI
my $customer = param(Customer);
my $learn = param(Learn);
my $opinion = param(Site Opinion);
my $improvements = param(Site Iimprovement);
my $comments = param(comments);
In the above section you are using a function of the CGI module 'param'
but you have not loaded the CGI module, you need another use statement:
use CGI;
You may also want to get all the params at once into a hash, but I leave
that to you, have a look at the docs for the CGI module:
perldoc CGI
my $head = Mail::Header-new;
What does this do on failure? you haven't checked return codes...
$head-add(From = 'Webmaster [EMAIL PROTECTED]');
$head-add(To = '[EMAIL PROTECTED]');
$head-add(Subject = 'hello there');
my $body = END;
This is just a simple e-mail message.
Nothing to get excited about.
Customer Type: $customer
How they learn of us: $learn
Their Opinions: $opinion
Their improvemetns: $improvements
Their comments: $comments
END
$mail = Mail::Internet-new(Header = $head,
Body = [$body],
Modify = 1);
print $mail-send('sendmail');
You have not printed a header back to the browser, usually something
like: Content-type:text/html\n\n, though again see the docs for the CGI
module for easy ways to do this.
end of cgi script.
What I'm concern with is the execution of this script.
I don't seem to be doing something right. Can someone
correct on what it that missing.
Usually the best way to find out problems with a CGI script is to check
the server's error log, or use a 'fatalstobrowser' type of deal, see the
CGI docs for this also...
Thanks for the suggestions. Now I get totally different error. I ran
this on the command line and get following:
% ./survey.cgi
Content-type: text/html
Substitution replacement not terminated at ./survey.cgi line 37.
Here is my code changes I've made:
#!/usr/local/bin/perl
use strict;
user warnings;
use CGI;
use Mail::Internet;
BEGIN {
print Content-type: text/html\n\n;
} # So we can debug using the web
# Collect parameters using CGI
my $customer = param(Customer);
my $learn = param(Learn);
my $opinion = param(Site Opinion);
my $improvements = param(Site Iimprovement);
my $comments = param(comments);
my $head = Mail::Header-new;
# add an error handler here for the above
$head-add(From = 'Webmaster [EMAIL PROTECTED]');
$head-add(To = '[EMAIL PROTECTED]');
$head-add(Subject = 'Peggy's Health Center Survey Response');
# Build the body of your message
my $body = END;
The following information has been sent via form:
Customer Type: $customer
Where They Found US: $learn
Site Opinion: $opinion
Site Improvements: $improvements
Comments: $comments
END
#Send the message
$mail = Mail::Internet-new(Header = $head,
Body= [$body],
Modify = 1);
print $mail-end('sendmail');
=== End of Code ===
Any ideas why I'm getting that error:
I'm using 5.8 version of perl and
have an older version 5.005_03
that does the same thing.
I appreciate the help.
--
*** Phillip B. Bruce ***
*** ***
*** Politicians and diapers have one thing in common. ***
*** They should both be changed regularly and for the ***
*** same reason. ***
*** ***
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI Scripts
Phillip Bruce wrote:
Wiggins d'Anconia wrote:
snip
Thanks for the suggestions. Now I get totally different error. I ran
this on the command line and get following:
% ./survey.cgi
Content-type: text/html
Substitution replacement not terminated at ./survey.cgi line 37.
Here is my code changes I've made:
#!/usr/local/bin/perl
use strict;
user warnings;
In the above line you have 'user' instead of 'use'
use CGI;
use Mail::Internet;
BEGIN {
print Content-type: text/html\n\n;
} # So we can debug using the web
# Collect parameters using CGI
my $customer = param(Customer);
my $learn = param(Learn);
my $opinion = param(Site Opinion);
my $improvements = param(Site Iimprovement);
my $comments = param(comments);
my $head = Mail::Header-new;
# add an error handler here for the above
$head-add(From = 'Webmaster [EMAIL PROTECTED]');
$head-add(To = '[EMAIL PROTECTED]');
$head-add(Subject = 'Peggy's Health Center Survey Response');
In the above literal you have an embedded single quote which must be
escaped or you need to change the quoting method. To escape a single
quote in a single quoted literal throw a backslash before it...
'Peggy\'s Health Center Survey Response', that *should* be the reason it
is failing
# Build the body of your message
my $body = END;
The following information has been sent via form:
Customer Type: $customer
Where They Found US: $learn
Site Opinion: $opinion
Site Improvements: $improvements
Comments: $comments
END
#Send the message
$mail = Mail::Internet-new(Header = $head,
Body= [$body],
Modify = 1);
print $mail-end('sendmail');
=== End of Code ===
Any ideas why I'm getting that error:
I'm using 5.8 version of perl and
have an older version 5.005_03
that does the same thing.
Stick with 5.8 unless you need the older version for some reason...
http://danconia.org
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI scripts permissions
On Wed, 25 Dec 2002 19:39:58 +, [EMAIL PROTECTED] (Philip Pawley) wrote: I'm a newbie, so the below is a question: Is this problem of cgi permissions different when you are just running a perl script from a virtual include - as I am? Reading this thread, I did some tests and changed my script's permissions to 500 and it still works fine. (I first did it just for a test script of course)! I am just an ordinary user (in my own group) on the web server. How is this possible? You probably have suexec running on the webserver. mode 500 means that the user can read and execute the script. Normally the httpd daemon will be nobody/nogroup, or something similarly underprivileged. With suexec, you are letting the httpd daemon run as user/users. I said that it has it's drawbacks. That's why if you do use it for something important, make a separate user just to run that cgi script. Here is a little test script to run: First run it and see what you get, then go and rename /usr/sbin/suexec to suexec.bak and restart apache. Then see what you get. ### #!/bin/sh echo Content-type: text/plain echo echo Username=`whoami` ### -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI scripts permissions
On Wed, 25 Dec 2002 05:34:04 +0200, [EMAIL PROTECTED] (Octavian Rasnita) wrote: Yes I know these, but ... it seems there is no solution. 1. The web server is not in the same group with me, and if it will be made to stay in the same group with me, the other users that have web pages on that server will need to be added to that group. 2. I saw that I need to give read permission also for a script to work, not only execute permissions. The only solution would be to run the Apache server with my user, but I don't know how to do that. How is this possible? Apache has the suexec program to do this. If suexec is in the path when apache starts up, then the httpd will run as user when in the user's home directory. This has advantages and disadvantages, but it is easily done. Normally apache will run as wwwrun/nogroup or nobody/nogroup, with suexec, apache will run as user/users when in users public_html. You can then run scripts at mode 700. It usually is best to set aside a dedicated user just for some cgi-program. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI scripts permissions
I'm a newbie, so the below is a question: Is this problem of cgi permissions different when you are just running a perl script from a virtual include - as I am? Reading this thread, I did some tests and changed my script's permissions to 500 and it still works fine. (I first did it just for a test script of course)! I am just an ordinary user (in my own group) on the web server. How is this possible? Thanks, Philip Pawley -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI scripts permissions
Hi, At 24-12-2002 18:09 +0200, Octavian Rasnita wrote: Please tell me what file permissions should I use for a CGI script. chmod 755 Can I deny other users to see the content of the cgi-bin directory (chmod 700) and chmod 755 only the files? Put a index.cgi in your cgi-bin directory that routes the users to your homepage. I did this whith all my directories with no index.html in it. Begin index.cgi #!/usr/local/perl $detour = '/somedirectorie/welcom.html'; print Location: $detour\n; print Content-Type: text/html\n; print \n; End of index.cgi Any comments are welcome. Kind regards, Rene Verharen Please DO NOT reply to me personally. I'll get my copy from the list. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: CGI scripts permissions
This is going to depend somewhat on your setup, mainly what user the web server is running as and what group it might be in. You could probably set your script to be 710 if your web server is in the same group as you but not the same user as you. Or if you go to 711, then anyone can execute the script but not read it, except for the owner which may be what you want. The same essentially applies to teh directory, if the web server (owner/group) can't read the directory then it can't execute the script, so setting the directory to 700 with the web server running under a different owner/group will mean the script can't be run in a cgi context. So determine whether the web server is running as the same user as you, if so you can limit it to 700, if it is running as a different user in the same group, then 710 should do the trick, if it is a different user and group then you are looking at 711. There is a chance though I didn't think this was the case that the script also has to be readable, in which case you are looking at 750 or 755. 1st digit = user 2nd digit = group 3rd digit = all 1 = execute 2 = write 4 = read sum the permission values, 7 = (4+2+1) = read, write, execute 6 = read, write 5 = read, execute 4 = read 3 = write, execute 2 = write 1 = execute http://danconia.org On Tue, 24 Dec 2002 18:09:52 +0200, Octavian Rasnita [EMAIL PROTECTED] wrote: Hello all, Please tell me what file permissions should I use for a CGI script. I don't want others users from that server to view the content of my scripts because they contain passwords for MySQL databases. If I chmod 755 the scripts, the other users will also be able to see the files. Can I deny other users to see the content of the cgi-bin directory (chmod 700) and chmod 755 only the files? Or, ... do I have other options? Thank you. Teddy, Teddy's Center: http://teddy.fcc.ro/ Email: [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: CGI scripts permissions
I assume you are connecting to a database? CGIs should have 500 permission and SHOULD NOT contain the password. Instead write a perl module which return the database_handle and put that together with the other modules (/usr/lib/perl5/5.8.0/). Then just call the module in your CGI script. Regards Richard KHOO Guan Chen On Tue, 24 Dec 2002, Octavian Rasnita wrote: Hello all, Please tell me what file permissions should I use for a CGI script. I don't want others users from that server to view the content of my scripts because they contain passwords for MySQL databases. If I chmod 755 the scripts, the other users will also be able to see the files. Can I deny other users to see the content of the cgi-bin directory (chmod 700) and chmod 755 only the files? Or, ... do I have other options? Thank you. Teddy, Teddy's Center: http://teddy.fcc.ro/ Email: [EMAIL PROTECTED] -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI scripts permissions
No, I don't have a problem with the web page visitors but with the other users that have accounts on that server. They could use Telnet or SSH to view the files and directories. They can see all my files if they have 755 permissions. Teddy, Teddy's Center: http://teddy.fcc.ro/ Email: [EMAIL PROTECTED] - Original Message - From: Rene Verharen [EMAIL PROTECTED] To: Beginners-CGI List [EMAIL PROTECTED] Sent: Tuesday, December 24, 2002 7:44 PM Subject: Re: CGI scripts permissions Hi, At 24-12-2002 18:09 +0200, Octavian Rasnita wrote: Please tell me what file permissions should I use for a CGI script. chmod 755 Can I deny other users to see the content of the cgi-bin directory (chmod 700) and chmod 755 only the files? Put a index.cgi in your cgi-bin directory that routes the users to your homepage. I did this whith all my directories with no index.html in it. Begin index.cgi #!/usr/local/perl $detour = '/somedirectorie/welcom.html'; print Location: $detour\n; print Content-Type: text/html\n; print \n; End of index.cgi Any comments are welcome. Kind regards, Rene Verharen Please DO NOT reply to me personally. I'll get my copy from the list. -- 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: CGI scripts permissions
Yes I know these, but ... it seems there is no solution. 1. The web server is not in the same group with me, and if it will be made to stay in the same group with me, the other users that have web pages on that server will need to be added to that group. 2. I saw that I need to give read permission also for a script to work, not only execute permissions. The only solution would be to run the Apache server with my user, but I don't know how to do that. How is this possible? In other cases, the security of CGI scripts is 0. Thank you. Teddy, Teddy's Center: http://teddy.fcc.ro/ Email: [EMAIL PROTECTED] - Original Message - From: [EMAIL PROTECTED] To: Octavian Rasnita [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, December 24, 2002 7:56 PM Subject: RE: CGI scripts permissions This is going to depend somewhat on your setup, mainly what user the web server is running as and what group it might be in. You could probably set your script to be 710 if your web server is in the same group as you but not the same user as you. Or if you go to 711, then anyone can execute the script but not read it, except for the owner which may be what you want. The same essentially applies to teh directory, if the web server (owner/group) can't read the directory then it can't execute the script, so setting the directory to 700 with the web server running under a different owner/group will mean the script can't be run in a cgi context. So determine whether the web server is running as the same user as you, if so you can limit it to 700, if it is running as a different user in the same group, then 710 should do the trick, if it is a different user and group then you are looking at 711. There is a chance though I didn't think this was the case that the script also has to be readable, in which case you are looking at 750 or 755. 1st digit = user 2nd digit = group 3rd digit = all 1 = execute 2 = write 4 = read sum the permission values, 7 = (4+2+1) = read, write, execute 6 = read, write 5 = read, execute 4 = read 3 = write, execute 2 = write 1 = execute http://danconia.org On Tue, 24 Dec 2002 18:09:52 +0200, Octavian Rasnita [EMAIL PROTECTED] wrote: Hello all, Please tell me what file permissions should I use for a CGI script. I don't want others users from that server to view the content of my scripts because they contain passwords for MySQL databases. If I chmod 755 the scripts, the other users will also be able to see the files. Can I deny other users to see the content of the cgi-bin directory (chmod 700) and chmod 755 only the files? Or, ... do I have other options? Thank you. Teddy, Teddy's Center: http://teddy.fcc.ro/ Email: [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: CGI scripts permissions
I can't do that because I am not the root of that server. I am just a simple user like all other users and I don't wantthem see my files. Thank you. Teddy, Teddy's Center: http://teddy.fcc.ro/ Email: [EMAIL PROTECTED] - Original Message - From: Richard KHOO Guan Chen [EMAIL PROTECTED] To: Octavian Rasnita [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, December 25, 2002 3:24 AM Subject: Re: CGI scripts permissions I assume you are connecting to a database? CGIs should have 500 permission and SHOULD NOT contain the password. Instead write a perl module which return the database_handle and put that together with the other modules (/usr/lib/perl5/5.8.0/). Then just call the module in your CGI script. Regards Richard KHOO Guan Chen On Tue, 24 Dec 2002, Octavian Rasnita wrote: Hello all, Please tell me what file permissions should I use for a CGI script. I don't want others users from that server to view the content of my scripts because they contain passwords for MySQL databases. If I chmod 755 the scripts, the other users will also be able to see the files. Can I deny other users to see the content of the cgi-bin directory (chmod 700) and chmod 755 only the files? Or, ... do I have other options? Thank you. Teddy, Teddy's Center: http://teddy.fcc.ro/ Email: [EMAIL PROTECTED] -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI scripts permissions
Octavian Rasnita [EMAIL PROTECTED] wrote in message 002901c2abd3$c17cdcb0$[EMAIL PROTECTED]">news:002901c2abd3$c17cdcb0$[EMAIL PROTECTED]... Yes I know these, but ... it seems there is no solution. 1. The web server is not in the same group with me, and if it will be made to stay in the same group with me, the other users that have web pages on that server will need to be added to that group. 2. I saw that I need to give read permission also for a script to work, not only execute permissions. The only solution would be to run the Apache server with my user, but I don't know how to do that. How is this possible? You need a host that runs some type of setuid wrapper around the CGI program. heres something I noted for the group awhile back: http://groups.google.com/groups?threadm=3DACCC0E.7010903%40uakron.edu Todd W. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cgi scripts and a crashing server:advice needed
not sure if anyone has asked. What kind of server and what do the logs say? --chad On Thu, 2002-10-10 at 11:56, Ben Crane wrote: Hi list, 2 Right, I have a few (6 to be exact) cgi scripts that run (not at the same time) on our web server, all 6 do a variety of different things like parsing data from a csv file and creating a suitable output html format and redirecting to other pages. Our server has crashed and there seems to be a general consensus that the number of scripts being run is causing the problem as the server also runs a Content Management System alongside. I've gone through my scripts to see if I've done anything silly, but the most advanced of all the scripts simply opens a csv file and parses it...i usually have other cgi scripts that use the csv file for validating the data, but I have closed each filehandle... Can anyone think of what types of problems very basic cgi scripts can cause on a server? Thanx Ben __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos More http://faith.yahoo.com -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Chad Kellerman Jr. Systems Administrator Alabanza Inc 410-234-3305 signature.asc Description: This is a digitally signed message part
Re: cgi scripts and a crashing server:advice needed
Ben Crane wrote:
Hi list,
2
Right, I have a few (6 to be exact) cgi scripts that
run (not at the same time) on our web server, all 6 do
a variety of different things like parsing data from a
csv file and creating a suitable output html format
and redirecting to other pages.
Our server has crashed and there seems to be a general
consensus that the number of scripts being run is
causing the problem as the server also runs a Content
Management System alongside. I've gone through my
scripts to see if I've done anything silly, but the
most advanced of all the scripts simply opens a csv
file and parses it...i usually have other cgi scripts
sometimes, it's not how advance or complicated a script that could cause
problem, it's how understandable you are as to what those scripts does. for
example, your cgi scripts can be very simple but if you have lines like:
my @data = FILEHANDLE;
or:
if(/$reg/o){
#-- do something
}
or stuff like that, your script will appear to be working most of the time
but it might fail once a while depends on what really came in. you should
look for those in your cgi scripts for anything that's obvious.
that use the csv file for validating the data, but I
have closed each filehandle...
Can anyone think of what types of problems very basic
cgi scripts can cause on a server?
you could be right that your server might be overloaded but it's really hard
to tell except you are willing to tell us more about the platform, server,
your cgi scripts... etc before anyone can tell you what really cause the
problem
david
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: CGI scripts in Perl
Visit this URL and configure your machine accordingly. http://support.microsoft.com/default.aspx?scid=kb;EN-US;q150629 -- Rex -Original Message- From: Naveen Parmar [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 08, 2002 1:39 PM To: [EMAIL PROTECTED] Subject: CGI scripts in Perl I have Microsoft Personal Web Server on my local machine. My perl scripts run fine from the command line. When I try to run them from cgi-bin within INetpub/wwwroot, they fail raising the HTTP/1.1 500 Server Error. Any ideas? - NP _ Join the world's largest e-mail service with MSN Hotmail. http://www.hotmail.com -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cgi scripts not running...
Chris, I am working within a small network (10 computers). I am trying to create a form that people can access through the f: (global drive). They will fill in this form, and the results will be processed by my script, and emailed to me. I have installed activeperl in the f drivebut I cannot seem to get any scripts to run in the intranet...any suggestions? We are running Netware 4.11 as the server. Is the computer that runs the scripts (on f: drive) the server? Is it a file-server or a web-server? (It needs to be a web-server). When you view the webpages with the forms, is it across the network, or through the web-server? Try setting the f: drive on the web-server as a virtual domain. i.e. so you don't browse to Network\Server\F:\index.html (or whatever) but you browse to http://virtual-server/index.html -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI scripts security
Jonathan wrote:
I don't think the shell is called to
resolve the /home/users/me/web/$in
{'NAME'}.ext bit, and therefore
you cannot run commands with it.
Randal wrote:
It would be if $in{NAME} contained |\0.
NULL characters terminate the string, and
if | appears just before that, bingo, it's
a shell command, not a file open. Trivial
to get:
/cgi-bin/yourscript?NAME=%7C%00
All that's needed now is to make that
\n/evil/command|\0 instead. I'll leave
that up to the guy that's about to visit
your site. :)
Ah, now there's one I forgot about. AFAIK Perl handles
null characters perfectly (8 bit clean :), but many
programs based on C aren't (not properly checked). It's
fine UNTIL perl uses it externally... might be good to
try, just in case Perl's magic does something about it.
Did anyone mention Taint mode? It's really not that hard.
Going back to the original problem, I suggest you don't use
the filesystem at all. A database might be safer in this
instance, and would be my preferred solution. Creating
files based on unchecked (anonymous) user input just seems
stupid to me. Alternatively setup the script in a chroot
enviroment, which is a little safer.
However, if it makes coding easier, and you can afford a
few hacks once and a while why not try tripwire - at least
you'll know when things have been changed. (Bad advice...
fix the real problem before looking at security tools).
Jonathan Paton
__
Do You Yahoo!?
Everything you'll ever need on one web page from News and Sport to Email and Music
Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI scripts security
Jonathan == Jonathan e paton [EMAIL PROTECTED] writes:
Jonathan I don't think the shell is called to resolve the
Jonathan /home/users/me/web/$in{'NAME'}.ext bit, and therefore
Jonathan you cannot run commands with it.
It would be if $in{NAME} contained |\0. NUL characters terminate
the string, and if | appears just before that, bingo, it's a shell
command, not a file open. Trivial to get:
/cgi-bin/yourscript?NAME=%7C%00
All that's needed now is to make that \n/evil/command|\0 instead.
I'll leave that up to the guy that's about to visit your site. :)
Never trust CGI params.
Never trust CGI params.
Never trust CGI params.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] 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]
Re: CGI scripts security
Kevin == Kevin Meltzer [EMAIL PROTECTED] writes: Kevin Never trust anyone over 30 Presuming that's in Hex, sure. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] 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]
Re: CGI scripts security
Jonathan E. Paton [EMAIL PROTECTED] wrote:
something like opening a file, but can somebody
show me how example below can compromise my website?
open(F, /home/users/me/web/$in{'NAME'}.ext);
What if $in{'NAME'} started with ../../../../tmp/?
Now, if in the tmp directory a link was created with that
file extension, then they could open anything according to
your scripts permissions. Scary, but not far fetched -
it's a frequently exploited idea.
That's true but this is not of my primary concern(there are no crackers with
telnet access to the site :)). I'm thinking more of other scary possibility,
that web visitors can execute commands abusing ';' or '|'.
Does something like '; rm * ;' can actually execute?
(note suffix '.ext')
Not in this instance, $in{'NAME'} must result in a string,
Yes %in is filled with parsed user variables, so I'm safe than, huh? :)
it can't magically turn into a subroutine call... unless
it's a tied hash - which you'd definately know about.
No, actually I don't, could you point me somewhere to perldoc?
At the top of your script use:
#!/usr/bin/perl -wT
This code won't even work, since it'll be reported as
insecure. When you've worked that bit out, you'll be back
for a way of untainting your data ;-) We'll be waiting!
Tnx, I've read somewhere about -T switch but right now don't have time to
toy with, variable filtering works nicely.
--
Matija
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI scripts security
Jonathan E. Paton [EMAIL PROTECTED] wrote:
something like opening a file, but can somebody
show me how example below can compromise my website?
open(F, /home/users/me/web/$in{'NAME'}.ext);
What if $in{'NAME'} started with ../../../../tmp/?
Now, if in the tmp directory a link was created with
that file extension, then they could open anything
according to your scripts permissions. Scary, but
not far fetched - it's a frequently exploited idea.
That's true but this is not of my primary concern
(there are no crackers with telnet access to the
site :))
That'd make your script a possible target for further
defeating your security. Since it probably runs as
nobody then it's unlikely it can benefit a hacker.
Getting that telnet account is probably quite hard, on
an appropriately secured box anyway.
However, the fact that this *could* be exploited means
that you shouldn't overlook it... unless the overall
security and importance of that server isn't that high
anyway - on an intranet for example.
I'm thinking more of other scary possibility, that
web visitors can execute commands abusing ';' or '|'.
Does something like '; rm * ;' can actually execute?
(note suffix '.ext')
Not in this instance, $in{'NAME'} must result in a
string,
Yes %in is filled with parsed user variables, so I'm
safe than, huh? :)
I don't think the shell is called to resolve the
/home/users/me/web/$in{'NAME'}.ext bit, and therefore
you cannot run commands with it. Then again, I might be
completely wrong. Read:
perldoc perlopentut
perldoc -f open
It can't magically turn into a subroutine call... unless
it's a tied hash - which you'd definately know about.
No, actually I don't, could you point me somewhere to
perldoc?
A tied hash is magic, it makes an object look like a mere
hash. When you access the hash in any way it calls methods
(subroutines) of the object. It's not a security risk as
such, and only a side interest. Documentation is at:
perldoc perltie
At the top of your script use:
#!/usr/bin/perl -wT
This code won't even work, since it'll be reported as
insecure. When you've worked that bit out, you'll be
back for a way of untainting your data ;-) We'll be
waiting!
Tnx, I've read somewhere about -T switch but right now
don't have time to toy with, variable filtering works
nicely.
-T is for taint mode, the draconian approach to secure
programming. It 'taints' data which comes from outsite
the script, and forces you to 'untaint' it using regular
expressions. Worth learning, if security matters.
perldoc perlsec
Jonathan Paton
__
Do You Yahoo!?
Everything you'll ever need on one web page from News and Sport to Email and Music
Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI scripts security
Hi,
I've read docs on security and I'm aware of that
all user variables should be checked before doing
something like opening a file, but can somebody
show me how example below can compromise my website?
open(F, /home/users/me/web/$in{'NAME'}.ext);
What if $in{'NAME'} started with ../../../../tmp/?
Now, if in the tmp directory a link was created with that
file extension, then they could open anything according to
your scripts permissions. Scary, but not far fetched -
it's a frequently exploited idea.
Does something like '; rm * ;' can actually execute?
(note suffix '.ext')
Not in this instance, $in{'NAME'} must result in a string,
it can't magically turn into a subroutine call... unless
it's a tied hash - which you'd definately know about.
At the top of your script use:
#!/usr/bin/perl -wT
This code won't even work, since it'll be reported as
insecure. When you've worked that bit out, you'll be back
for a way of untainting your data ;-) We'll be waiting!
Jonathan Paton
__
Do You Yahoo!?
Everything you'll ever need on one web page from News and Sport to Email and Music
Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
