Re: PHP vs Perl
Octavian, In some respects I believe you are correct. Here are my 2cents... 1) It is really not good to enable mod_perl by default. Doing so would dramatically increase the size of the Apache binary. Enabling all scripts to run through Apache::Registry would break half the scripts that exist out there... Even the more backwards compatible form of Apache::Registry is going to require tweaking for probably some scripts and in the meantime would create a support burden for the ISP for sure as well as increasing the ISP memory requirements. Also, mod_perl is a tool with access to Apache internals which can be security problem also (so that part would have to be turned off). mod_perl is more designed for power users. I do think that a beginner can be proficient without too many weeks of work but not the same learning curve (like 1 day) as plain CGI/Perl. 2) PHP has some very rich on-line resources available that also furthers the helping of people. mod_perl has tried to do the same but only since maybe last year or so? My dates may be wrong, but I saw this PHP vs mod_perl discussion on the mod_perl mailing list.I think most people looked at perl.apache.org THEN, and PHP's various websites and the difference in tutorial and sample code quality was overwhelmingly in favor of PHP back then. Since then, perl.apache.org has been revamped, but it takes a long time to change people's perceptions. Sadly, (or perhaps justifiably so), documentation can make all the difference in the success or failure of an open source project. Not the code quality or architecture of the project. 3) In any case, to get close to the speed of PHP, you need mod_perl (which is arguably faster than PHP), but to get close to the user-friendliness/learning curve of PHP, you have to stay in the world of CGI. Although this is my opinion, I believe this, at least, to be arguably true. 4) It's not just that something has a big corporation behind it that can make it a success. It's also your partners and how big they are. ISPs, for example, would be the best friend for any technology to have. Unfortunately for Perl, I would not be surprised if the ISPs have had a hand in pushing PHP's success. Given that PHP will consume less resources than launching CGI shells but allow any beginner to do so (as opposed to mod_perl), what ISP wouldn't want to encourage their users to use PHP instead of Perl/CGI? If they can handle 20 users on a box using Perl/CGI but 100 users on the same box if those users switched to PHP, it obviously helps the ISPs bottomline to have people use PHP. See my comment in #1... sadly, there is no way to easily enable mod_perl by default. The list of ISPs supporting mod_perl has been growing, but it is still quite sparse.. 5) I have done some PHP coding and found it extraordinarily easy to pick up. I wouldn't move to it however because I find that for my purposes CPAN is actually a big bonus. eg I am recently programming in bioinformatics field again after a hiatus in the financial world for 5 years...how many tools exist to integrate with bioinformatics tools in PHP? Maybe a few, but certainly compared to Java and PHP, Perl has libraries for that domain beat hands down. Even if the modules are not in CPAN, many websites have various bits of Perl libraries for accessing their bioinformatics tools. And so just continuing to use Perl makes a lot of sense. For me. :) I think a lot of other people who advocate Perl in one word: CPAN probably feel the same as me though. And that is heartening. :) Thanks, Gunther Octavian Rasnita wrote: Of course I will remain subscribed and I am not gonna start learning PHP immediately. I am thinking to learn it because in my country there are only 2 books for learning perl in my native language and even though I don't need them, there are very few perl programmers and almost no jobs for perl developers. There are even some programmers that just heard about perl but they don't even know too well what it is, and they are good programmers in their languages. My problem is that I am used to work under Windows where no compiler is installed by default and where some CPAN modules don't even compile under this OS, and I cannot just jump and use Linux because Linux is not an operating system too accessible for the blind, and I am totally blind. Unfortunately I cannot try to solve this problem and start creating an accessible version of Linux then creating perl programs under this OS. Perl is great because OF CPAN also, but there are very many modules that require Linux, some of them don't even tell this but the modules don't even want to compile under this OS. I am not trying to convince somebody that PHP or Java is better than perl, but I am just trying to see what makes those programming languages so... en vogue. For example a programmer in Java can create not only java servlets or java server pages, but they can also create java applets and desktop
Re: portability question...IIS Vs. Apache
IIS thinks the CWD is the root directory of the script alias. Just set
up a script alias that points to the directory where the cgi actually is
and you'll be fine.
Peter Kappus wrote:
Hey all,
Anyone move scripts between IIS and Apache or need to write scripts that
work on both? The problem I'm facing is that IIS reports the current
working directory (CWD) as the root dir of the application as defined in
the IIS control panel while apache reports the CWD as the actual directory
of the script file itself.
This is a problem when including other files/modules...
For example, to include /myApp/func.pl from /myApp/index.pl:
require func.pl;#works fine in Apache but not IIS
require /myApp/func.pl; #works for IIS
ditto for modules:
require myMods::myModule.pm;#works in Apache
require myApp::myMods::myModule.pm; #works in IIS
aarrggh. I'd rather not add a big block like:
if(-e func.pl){
require func.pl;
}else{
require /myApp/func.pl;
}
at the top of every file and I don't even know if that would work...
Anybody got a more elegant solution? (other than dump IIS ;-)
Thanks!
-Peter
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How fatalsToBrowser works ?
You might find this link useful...
http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Exception_Handling_for_mod_perl
Basically, fatalsToBrowser is OK to use, but it can be fraught with
underlying issues that Matt outlines pretty well in the above URL. Has
also given a talk on the subject at the last couple of O'Reilly conferences.
As an aside, at eXtropia, therer was a period of a couple years where we
used fatalsToBrowser quite a bit. And everytime some incompatibility
happened with mod_perl or some other advanced environment, we'd submit
the bug (and sometimes a sample patch) to Lincoln Stein who has been
very helpful.
However, Perl 5.6.0 in particular ruined all of that for us by changing
the behavior of how fatalsToBrowser worked making eval {} tests
impossible to use in your code. 5.6.1 fixed the problem, but there are
MANY ISPs still running 5.6.0 and our support email volume skyrocketted.
So now when we give out scripts we provide a debug version of the CGI
which calls the original CGI behind the scenes wrapped in an eval system
that can do the same thing as fatals To Browser. When you are done
debugging, the intention is that you disable it by changing $DEBUG = 0
instead of $DEBUG = 1 or you delete the debug script off your directory.
Generally, you shouldn't enable fatalsToBrowser in production as a
general security practice.
The nice thing about making the debug into a separate script that calls
the original CGI is that if you want to re-enable debugging output in
production, your production users pointing to the main CGI script will
not get any additional information. But you can still troubleshoot with
the debug version of the URL which your production users won't have
(unless they've been hacking around).
This is similar in concept to the fact that CGIWRAP has a debug and
nondebug version I think. Or at least that's the inspiration for me to
have written this. If you want this debug wrapper program, you can get
it by downloading just about any app off our website such as address
book. If you download address book, you will see address_book.cgi
and address_book_debug.cgi. The debug one can be easily modified to
work with your CGI script and as far as I know has no weird Perl version
problems like fatalsToBrowser.
Later,
Gunther
Connie Chan wrote:
Thanks everybody, I've made it =))
code
package Die4CGI;
use strict;
$main::SIG{__DIE__} = \Die4CGI::die;
sub die
{ my $dieMesg = shift; $dieMesg =~ s/ at .+$//;
my ($package, $file, $line) = caller;
$file =~ s/^C:\\Server\\Staff\\Connie\\Project\\onTry\\/\\/;
$file =~ s/\\/\//g;
print Content-type: text/html\n\n;
print HTML;
# A lot of html #
Garfield said: $dieMesg happens at: $file line $line.br
# A lot of html #
HTML
; exit(0);
}
1;
/code
So I can call it like the normal :
use strict;
use Die4CGI;
my $file = 'somewhere/somewhere';
open FH, $file or die $!; # prints what I want
Another fatalsToBrowser, simple and lovely!! ;)
*BUT!! I still not understand, how can this overided
the orgional die ? Why shouldn't I write as :
open FH, $file or Die4CGI::die($!) ;
Would anybody tell me more ?
Rgds,
Connie
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI Calendar Script
At 08:55 AM 7/10/2002, David T-G wrote: Roger -- ...and then Roger Spears said... % % Hello, Hi! % % Well for my next project I'm trying to build an interactive calendar % system using Perl/CGI. Neat. I'd be quite interested in the finished product. I've been searching (fruitlessly) for a calendar that will print multi-day events in a lined-up bar across the days instead of jumbling events together. Will yours work for me? Our calendar does something like this within our day view. We call it a chunking algorithm to allow events to span different hours and overlap with other events within the same day while looking nice. Our month and week views do not do this same chunking (the events are just repeated) but the general chunking algorithm could probably be reused in our month and week views if this was something you were keen on. It's part of the downloads on http://www.extropia.com/ Later, Gunther -- 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: mod_perl and nntp.perl.org
At 11:58 AM 10/31/2001, Scott R. Godin wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Ask Bjoern Hansen) wrote: [EMAIL PROTECTED] (Scott R. Godin) writes: aside from the mailing lists @apache.org I haven't seen much else, and having a fair preference for a usenet-style discussion as opposed to a mailing list format, it might be useful to bring such onboard here at nntp.perl.org... I don't think we to make an extra mod_perl list. Maybe I'll get around to adding some of the apache.org lists to the perl.org news server some day, but don't hold your breath - my list of projects is (too) long. :-) I just thought it would be nice to centralize the mod_perl discussion here, along with the rest of the perl-related stuff.. seeing as the stiff competition from the PHP fanatics and with the help of the Zend Optimizer, PHP appears to far outstrip mod_perl in both memory usage and speed. the more people that can get involved with improving mod_perl the better, and again, bringing discussion to one centralized location for these things isn't a bad idea. He's not saying that there should not be a mod_perl list. It's that there is already a mod_perl list on apache.org. Go to http://perl.apache.org and subscribe to the mod_perl list there. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: configuring apache to run cgi -perl on win32 system
You'll need to change your shebang line to #!c:/perl/bin/perl.exe instead of #!/usr/local/bin/perl or something like that. Search the past archives on this list (assuming there are any) as this question has definitely come up in the last 3 months before. At 01:06 AM 10/17/01, rabs wrote: Subject: configuring apache to run cgi -perl on win32 system Hello, thank you for taking the time to read this, I hope you can help, I have downloaded the release of Apache/1.3.20 to run on windows 98. I wish to run perl cgi so I have made the following changes to the httpd.config file changed #ServerAdmin to ServerAdmin [EMAIL PROTECTED] changed #ServerName to ServerName 127.0.0.1 removed the #preceddingAddHandler cgi-script .cgi I then placed the following program named hello.cgi in the directory c:/apache/cgi-bin/ ## #!/usr/local/bin/perl # hello.pl -- my first perl script! print Content-type: text/html\n\n; print Hello, world!\n; ### this script runs ok from the command line## I then went to the url http://localhost/cgi-bin/hello.cgi I get this error message ## Fri Oct 12 20:48:47 2001] [error] [client 127.0.0.1] couldn't spawn child process: c:/apache/cgi-bin/hello.cgi ## what am I doing wrong? Activestate Perlis installed at C:\Perl\bin\perl.exe I think this has something to do with it. But I Ive been looking at this config file for the last eight hours and dont know anymore.. Anyway If you can help thanks in advance... Ric -- 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 commands, e-mail: [EMAIL PROTECTED]
Re: LWP and SSL
It's pretty much the exact same thing. Except that you need to compile LWP to work with SSL. You may wish to talk to your ISP about your needs if you don't control your own web server. At 06:01 AM 10/9/2001, Greg Puleo wrote: Anyone have any examples of using LWP to post information to https sites? -- 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 commands, e-mail: [EMAIL PROTECTED]
Re: Using Win32::ODBC
I would second what Curtis said. Avoid Win32::ODBC entirely.
Not just because of the features, but because it's also not going to be
portable anyway beyond simple CGI on WinNT. Every few months someone on the
ActiveState PerlEx (loosely known as the NT equivalent to mod_perl) mailing
list posts
Win32::ODBC mysteriously crashes on me...
And perennially, the response is Don't use Win32::ODBC.
The reason is that Win32::ODBC is not thread safe. DBD::ODBC is. NT is a
multi-threaded OS so if you start using a shared interpreter model for
speed like PerlEx, you'll run into a lot of problems. And even if you don't
now, you might later and then you will run into problems.
Here is a snippet from PerlEx tech support (Murray Nesbitt) on the issue
Win32::ODBC is notoriously unreliable when used with PerlEx, as this
extension is not thread-safe. You will likely have much better luck with
DBD::ODBC which is thread-safe, portable, and more actively maintained
than Win32::ODBC. More details and a list of known thread-safe extensions
is at:
http://www.activestate.com/ppm/threads.htm;
As an aside, these issues are also similar to what will become issues with
Apache 2.0. Although I am not the biggest fan of PerlEx (eg no formal
support for taintmode), I think ActiveState has done mod_perl 2.0 a huge
advance service by basically culling out modules that won't work with a
multi-threaded Perl interpreter pool since this is exactly how PerlEx works
today.
Later,
Gunther
PS I notice the URL from Murray's msg no longer works and I can't seem to
find a similar reference on ActiveState to a list of threadsafe modules
although it might now be embedded in the docs to Win32 Perl.
At 12:38 AM 10/10/2001, Curtis Poe wrote:
--- [EMAIL PROTECTED] wrote:
I'm successfully connecting to a Pervasive 7 database with my PERL program
when running from the command line.
I try to run the program in my webbrowser and I get the following error.
Error connecting to MO Error: [802] [] [Pervasive Software][ODBC
Interface][Pervasive Software SQL Engine]General error.
(MO is the name of my system DSN)
any ideas how to fix this so it runs on the web server properly
While this is not the answer you seek, have you considered switching to
DBI with the DBD::ODBC
driver? This would give you several advantages:
1. It's portable.
2. Placeholders are supported. That, combined with DBD::OBDC's separate
prepare and execute
statements could let you do this:
my $sql = 'SELECT firstName, lastName FROM table WHERE uid=?';
my $sth = $dbh-prepare( $sql );
foreach my $uid ( @uid ) {
push @names, $sth-fetchrow_arrayref( $uid );
}
Since the statement is already prepared, this is much faster than Win32::ODBC.
3. Notice I didn't use any error handling in step 2? (ignoring for the
moment that I could have
had an invalid $uid) DBI allows me to set RaiseError automatically, thus
catching errors for me.
For large applications, this is critical.
4. Win32::OBDC has no bind parameters. As a result, you can't specify a
BLOB, for example.
Forget about using binary data.
5. More programmers know DBI and thus can offer you better support.
6. DBI has the DBI-trace method, which is a godsend for debugging.
Cheers,
Curtis Ovid Poe
=
Senior Programmer
Onsite! Technology (http://www.onsitetech.com/)
Ovid on http://www.perlmonks.org/
__
Do You Yahoo!?
NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1
--
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 commands, e-mail: [EMAIL PROTECTED]
Re: setuid question: insecure dependency?
The problem isn't setuid Perl it's that suid forces taintmode on. Read all available docs on taintmode. In particular start with Lincoln Stein's Web security FAQ at the www.w3c.org website... and re-read perldoc perlsec as you've stated you've done, but this time pay attention to the taintmode stuff. Lincoln Stein also has a good article on calling setuid stuff like changing passwords from a Web App in one of the past Perl Journal issues, but I can't recall which one at the moment. It was quite a good article though as it went through the pros and cons of several different ways of doing it. Later, Gunther At 05:14 PM 9/19/2001 -0400, Andria Thomas wrote: Hi all -- I'm trying to write a setuid script to change passwords on a machine via the web. I am not trying to change the local passwords (i.e. *not* modifying /etc/password), but I do need the script to be run as root so it can call another password-changing utility which is doing the actual work. When run from the command line as root, the script works fine. However, when run as myself (after setting the script to be setuid root) I get the following error generated from the script's system call: Insecure dependency in system while running setuid at ./chpass_web.pl line 159. Perl is installed on this system to use suid emulation, so it's calling the 'suidperl' binary. The problem originates from the following line of code: system /bin/echo $new_password1 | /usr/local/sbin/saslpasswd -p $in_username; The documentation I've seen implies that variables can't be passed directly into the shell, as they are above, but I couldn't reword the system call in any way that still enabled it to work. Can anyone help with this? Or lead me to any pointers on suidperl? I've already read the perlsec manpage, and searched through the mailing list archives... Thanks! Andria -- -- Andria Thomas [EMAIL PROTECTED] System Administrator -- Tovaris, Inc. (434) 245-5309 x 105 -- 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 commands, e-mail: [EMAIL PROTECTED]
Re: editing script
At 08:44 AM 9/13/2001 -0300, Wagner wrote: Hello, I'm editing a script that produces a .png image, i want it to turn it into a .html doc. My first doubt is that i can't put the image in the html doc. The image is stored in $im and i don't know how to put it in the doc. ex: print Content-type text/html\n\n; print HTMLimg src=$im/HTML; Not unless $im is a URL and even then you may want to consider quoting it. You can't just dump binary data inside an HTML document. So $im must be a URL not the binary data of an image. I'm also trying to put this image in a file this way: $file = 'c:\image.png'; open (INFO, $file); print INFO $im-png; close (INFO); But it doesn't work... It's possible that you want to turn binmode on INFO... binmode(INFO) before printing a binary image to it. The second doubt is how can i put the content of a variable in the doc. For example, if i have a valiable: $file = 'c:\dir\asdf.asd', Then i try to put in the doc this way: print HTMLFONT$file/FONT/HTML; But when i run it apears $file in the .html doc and i wanted to see c:\dir\asdf.asd $file should interpolate fine if you truly did use double-quotes in your print statement, but I think it is possible that you should cut and paste exactly what you used because you seem a bit confused, and I am afraid that it's possible that you're information is not relayed exactly as you say you typed your tests out. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Complete beginner can't get Sendmail to work
Please do a search on the archives of this list from the past couple weeks having to do with mail and you'll see many good, verbose suggestions on some good alternatives At 04:49 PM 9/13/2001 +0100, Andrew Cocks wrote: my sendmail.pm file (stored in the SYS\Perl\lib\Mail directory) has the following line: $default_smtp_server = '192.9.200.222'; my formmail.pl file refers to the sendmail file with the following line: $mailprog = '/perl/lib/Mail'; Can anyone see anything wrong with these lines of code? Is it possible to test sendmail.pm without using another script? ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. [EMAIL PROTECTED] ** -- 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 commands, e-mail: [EMAIL PROTECTED]
Re: file write problem
In addition to Randal's lucid explanation of your specific problem. I would
encourage you to also use taintmode flag and filter both subject and
filename as they are being used to create the file. The commented out
attempt to do this with $name shows that you basically may be aware of
this, but I figure that I would just raise it quickly since it's important
topic.
Another minor thing is that I thought was the operator for opening
with appending not . But I haven't done appending in a long time so I
could be wrong.
At 09:51 PM 9/11/2001 +0100, Francesco Scaglioni wrote:
Hi,
I have a script which collects a comment than should write it to a
file. Initialy several scripts did individual jobs but I am combining
them. the opening gets the details like this:
my $email = param( 'email') || '';
my $text= param( 'text' ) || '';
my $name= param( 'name' ) || '';
# ( my $name )= ( param('name') =~ /^(\w+)$/ );
my $filename= param( 'filename' ) || '';
my $subject = param( 'subject' ) || '';
my $action = param( 'action' ) || '';
my $heading = param( 'heading' ) || '';
my $title = param( 'title') || '';
and then like this:
if( $action eq 'start' ) { start(); }
elsif ( $action eq 'list') { list( $subject ) ; }
elsif ( $action eq 'display' ) { display( $subject , $filename ); }
elsif ( $action eq 'get_comment' ) { get_comment( $heading , $subject ,
$filename ); }
elsif ( $action eq 'write_comment'){ write_comment( $name , $email ,
$text , $subject , $filename ); }
else { start() }
Then the write bit is:
sub write_comment {
$name = $_[0];
$email= $_[1];
$text = $_[2];
$subject = $_[3];
$filename = $_[4];
# $COMMENT_DIR = (../data/$subject/.comments);
$COMMENT_FILE = (../data/$subject/.comments/$filename) ;
if ( ! $name ) {
die No value for name;
}
else {
local *WRITE_COMMENT;
open ( WRITE_COMMENT, $COMMENT_FILE ) || die $COMMENT_FILE : $!;
flock WRITE_COMMENT, LOCK_EX || die cannot lock comment file: $!;
print ($text, $name, $email ) || die cannot print hello : $!;
close WRITE_COMMENT || die Cannot write to comment file ; $!;
}
}
What is throwing me is that none of it errors or dies but the file
remains blank. What am I missing?
TIA
Francesco
--
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 commands, e-mail: [EMAIL PROTECTED]
Re: A Framework for Building An WML/HTML Application Using Perl???
At 09:30 AM 9/10/2001 -0500, David Simcik wrote: Hey all, I'm trying to modify an existing script that searches a test file for what one could qualify as normal phonebook style entries; name, phone #, email addy, etc. We've got an internal presentation coming up in two weeks, and my boss would like to WAP-ify this directory for it. That almost certainly means moving the app to produce an XML doc of some kind. Ideally, I would like to use XSLT to convert the raw XML doc into WML and HTML; to seperate data from presentation of course. The Perl script would handle the actual search mechanism, any logic required to detect different browsers, and the handling of the XSL transformations. The most comprehensive XSL Transform API for Perl is Matt Sergeant's AxKit. http://www.axkit.org/. It works with mod_perl and is quite heavily optimized. Can anybody provide a few pointers on the best approach to take with this? More specifically, any recommended modules that could be used to facilitate this? How can I detect different WAP browsers??? You can detect different WAP browsers with an Agent string, but really there are some guidelines to programming WAP in a fairly cross-browser way. I've programmed for about 12 different WAP phones and found many of them to be quite similar with the original Nokia 7110 and Motorola PDA phone being the biggest offenders and pain in my neck programming. Caveat: my experiences may not be the same as you may find because I wrote my apps for use in a GSM market phones in Asia. But if you are in the USA, your WAP phones may have different quirks than the entire rest of the world. As a shameless plug, I would direct you to the book Applied Perl edited by Peter Williams where I've written a chapter on programming WAP applications using Perl based on my experiences writing WAP and SMS enabled Web-applications in that market. Anyway, since all you really want is a demo, I would just download one of the WAP emulators and just simply code for that emulator and your life will be much easier than coding some weird XSLT transform. I am of the opinion that WML is really so completely different and changes your forms so drastically and what you would want to display and bring back as data, that a simple XSLT transform is not enough -- you really require logic changes to the application. People talk all the time about separation of UI from application code, but to some degree, the UI medium does have a big effect on the workflow of the application. For example, in an HTML app, you can often get away with long parameters passed back and forth but in WML where you might have a single HTML form split into many WML forms, you have to more readily maintain the state of the previous forms in your WML application which requires more session logic. These things can't really be emulated in a simple transform. Good Luck, Gunther -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: String to Date conversion
At 08:42 PM 9/10/2001 -0400, [EMAIL PROTECTED] wrote: Hello, Can some one please suggest me a pointer to do easy date manipulations in perl. I have dates as strigs I need to compare 2 dates and may be sort an array of dates(Strings). Thanks s- Look at the Date modules on CPAN. I quite like one of the recent ones called Class::Date but you'll find that it isn't in ActiveState's PPM repository yet and requires a C compiler to compile if you are using Windows NT. Otherwise consider looking at Date::Manip and Date::Calc. Also, questions like this beg for you to buy the Perl Cookbook from O'Reilly. It has all sorts of quick recipes for Perl for doing operations like this. In addition, you might find some operations are quite trivial. eg if you have a string and you know how to parse it into date parts, you could put the date parts together again in a way that will compare easily in a sort. eg mmdd will sort fairly accurately in scalar context. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: options for the checkbox...?
No, the fact that unchecked boxes aren't sent is a browser issue. It's the
same reason why submit buttons that are not clicked are undefined as well
on a multi-submit form.
What you can do, however, is use other form fields in combination with
logic. For example, let's say the name of your check box is
view_all_records and you want it to explicitly be set on or off.
Well, then you can always create a hidden variable called the same thing
and set it to off by default...
So
input type=hidden name=view_all_records value=default_off
And then in CGI.pm, expect $q-param('view_all_records') to return an array
if the check box is on, and return an array with a single value if the
check box is off (the single value will be the hidden field).
The technique would be slightly different if you had many check boxes with
the same name but different value. eg In a WebDB, you might allow selection
of the id of a record by allowing the user to click next to database rows.
The extrapolation of the above technique to the second I describe with
multi-checks is left as an exercise to the reader (since it wasn't the
situation you described anyway).
At 06:08 PM 9/8/2001 -0700, Simon K. Chan wrote:
Hi Everyone,
Let's say I have this snippet of code for a checkbox:
input type=checkbox name=bill
$name = param('bill');
If the box is checked, $name will have a value of on
If the box is NOT checked, $name will be undefined (have no value).
My Question:
Is there a way to make $name have a value of off when the box is UNCHECKED?
Many thanks for your time, Everyone.
=
#
Warmest Regards,
Simon K. Chan - [EMAIL PROTECTED]
Great spirits have always encountered violent opposition from mediocre
minds.
-Albert Einstein
__
Do You Yahoo!?
Get email alerts NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com
--
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 commands, e-mail: [EMAIL PROTECTED]
RE: Is it a security risk to use identical names for database fields and html forms?
At 12:53 PM 9/3/2001 +0100, yahoo wrote: Hi Gunther, yes, you are right - maybe my answer was a bit flippent - it was only meant to be a conversational addition to the thread rather than a definitive answer ;-) By access to the DB I meant a valid SQL login. I enjoyed reading that URL you posted. Seeing the SQL being returned to the web user for his/her inspection is certainly a most worrying situation! Once again it reinforces the golden rule that you should NEVER trust (or make unfounded assumptions about) user input. I think that dynamically created SQL statements (such as in the norm in MySQL) are very vulnerable to this kind of attack in contrasts to, say, using stored procedures. I enjoyed reading your post :-) Thanks! I also gave a talk on these issues at this past year's ApacheCon. I've placed the slides are up here: http://www.extropia.com/presentations/cgi_security_history.html Since me and Selena Sol have been around giving out open source web apps since 8 years ago (very early on the Web), we've of course seen the gamut of security holes, including those within our own past software. So this talk was really an attempt (within a tiny 45 minute talk) of going through common problems from a long time ago and linking them up to problems that are more recent and have gotten little publicity but 2 years down the road may be as rote as knowing that filenames need to be filtered. There's actually quite a bit of interesting stuff out there that has really only been discovered and publicized at all in the last year or two. Null byte is another huge issue few Perl programmers seem to know about/understand as it affects the file open() command in a subtle way yet I think it is not described in perldoc perlsec (it seems mostly focused on tainting and general validation issues). joel -Original Message- From: Gunther Birznieks [mailto:[EMAIL PROTECTED]] Sent: 02 September 2001 01:15 To: yahoo; [EMAIL PROTECTED] Subject: RE: Is it a security risk to use identical names for database fields and html forms? At 02:29 PM 8/31/2001 +0100, yahoo wrote: nah! what difference does it make? I mean, if they guy gets access to your DB server then he's gonna find out the fieldnames anyway! If he can't get access to your DB then what has he got?, a few POSSIBLE DB field names (i mean, how does HE know the names are real?) for him to attempt to recreate fragments of the data model pah! best of luck... joel Joel, while I do think that this is a nice succinct reply to the thread, I am not sure that it really uncovers the entire problem. It's a bit hard to understand what you mean in your post as you don't really qualify the phrase access to the DB. Sure, if I have a TCP stream to mySQL, it's possible to get anything. But access to a database through exploiting CGI is not always perfect and therefore being able to glean extra information is helpful to any cracker on the system. I do firmly believe that restricting the information you give the user about your system will help security, but I also think it is a matter of diminishing returns and would rather the user who asked the question focus on the things I highlighted in my post yesterday (eg quoting issues, data validation, etc). If the SQL is exploitable, then mucking about with the fields whose values are obvious candidates for being sent to the database makes a difference. But further, it does make a difference to know about the field naming when it comes to extrapolating how to generate the rest of the query. Do you really think that this is inconceivable? The following URL is a well-written account of rain forest puppy hacking into a BBS forum software by exploiting it's error handling routines to gather some bits of information about how the queries are being created and exploiting that information through the CGI script. http://www.wiretrip.net/rfp/p/doc.asp?id=42iface=2 Since I read this article and then in reviewing the security of other CGI scripts, I have found exploitable SQL code in at least several places. I guarantee that bad SQL coding is a problem for sure in the latest CGI scripts. But the degree varies from application to application. Just as seeing one cockroach in a kitchen actually entails a million more behind the walls, since reviewing CGI security is not a full time job for me (just an occasional if someone asks me), the fact I have seen this much exploitable code is an indicator to me that the problem is currently quite huge. In summary, I would heartily encourage careful best practices for SQL coding in Perl as I indicated yesterday and as RFP describes in the URL I gave above. And I would agree that the form variable changing names is probably not that useful to avoid attack, but I would not agree that it's entirely useless. I think risk assessment is a reasonable thing for this person to have asked about on this list, and shows a smart attitude towards security. Especially
Re: Script compliation Sequence.
At 11:19 AM 9/17/2001 +0800, Rajeev Rumale wrote: Hello EveryBody I needed some advice for all. I am working on a untilty which needs to perform server functions. I am bit confused with compliation sequency of scripts, when we use do, require or use to include into our scripts. I have written a library file which contains all the common routines, and include this in evey other script i write. This file is very very long running around 3000 lines. But most of the scripts use around 10% of the libraray routines only. Well, considering that CGI.pm is 6400 lines long and that includes yet other modules etc, I don't know if you should be worried about 3000 lines. However, if most scripts use only 10% of the library routines, you might consider looking into a feature called AUTOLOAD and require the second library to instantiate the routines that are called less often. As per my understanding when ever any script is invoked it will complie both the script and the included files. This is done each time the script is invoke. Not necessarily. use is always loading the modules at compile time. But require is only hit at run-time so you can selectively break up your library and only require the library or module on-demand. AUTOLOAD is something you should look into though. I would like to know if I can group this subroutines into different files and include only the relevant routines an and when required depending upon coditions at runtime. This will keep the files size to be less and will also avoid unnecessary compilation time. You should definitely consider refactoring a little bit to make sure that routines that are alike are grouped together. However, IMHO refactoring the library code just on how often the routines are called is not good in the long term. I appreciate that you want to improve the performance of your CGI, but 300 lines of code versus 2700 lines of code being loaded later is not going to make a big difference to the overall performance when you consider the many other libraries you are probably loading (and may not even know it!). Second, refactoring based on how often the code is used rather than based on grouping them by like-task will be guaranteed to make your life a headache as you add and subtract routines as your requirements change for what the application is supposed to do (and any good program will change over time). If performance is really your primary concern, I would sooner recommend that you split your code up by like functions, not for loading time and then for performance increase use mod_perl, Speedy::CGI or any other number of environments that can compile your code once but just keep it in memory for the future. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Urgent !!! installing Storable.pm
At 01:08 PM 9/17/2001 +0800, Rajeev Rumale wrote: Hi, I need to install and use the Storable.pm in my machine. I am useing Active Perl on Win2k machine. I have not done this before. Its urgent, kindly let me know the procedure for same. rajeev Really, you should consider subscribing to the beginner-perl list for this sort of question and not the beginner-cgi list. The short answer to your urgent question is that you should read the ActiveState documentation on downloading modules. It's really easy, just run ppm. Perl Package Manager. C:\ ppm PPM install Storable Blah blah blah about how it is installing storable PPM quit And voila. Later, Gunther __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/ -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Extened - Re: securing sensitive information in CGI scripts
This is a very different security question. Basically I think there are two major classes of solution. One is based on randomness and the other is based on a harder core ACL check in the CGI itself and requires the CGI control access to the file more tightly. In Detail: One way which isn't the most secure is to generate random directories to place these files in and then put the file in these random directory names for download. Unless a hacker guesses correctly (eg use an MD5 hash is pretty strong) which is unlikely, they won't be able to get a file of someone else's without knowing the session key. This is subject to brute force checking and is potentially breakable through other means. The more secure way is to store the file outside the document tree and check a database to see if the authorized user can access that particular uploaded file. If so, then the CGI program itself should open the file and present it back to the user. Otherwise, no dice. At 10:32 AM 9/5/2001 +0800, Rajeev Rumale wrote: Greetings to all, This is really a good thread we have. How ever as the title is not restricting to database security. I would like to add my concern to it. I need to store some uploaded files from the visitors into some directories which are inside website root. Since the files submited are confidential info We need to protect it from people directly accessing the files depending upon the ownership rights (the actual owner, site admin, site operator, other authorised user). Any suggestions for same . Thanking in advance. Rajeev Rumale -- 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 commands, e-mail: [EMAIL PROTECTED]
Re: securing sensitive information in CGI scripts
At 10:34 AM 9/4/2001 +, Mel Matsuoka wrote: At 07:20 PM 09/04/2001 +0100, yahoo wrote: Hi all, I'd like to find out peoples opinion on the following. If you have a perl cgi script which accesses a database, are there any security issues with having the DBI connection details in the perl script (rather than, say, an external file not in the document root - is this better?)? My general policy regarding things like this is, the more paranoid you are , the better :) Having password information embedded in a publicly accessible document such as a CGI script is playing with fire, as far as I'm concerned. There may be a time when you least expect it when someone (or you) screws up the webserver config, and accidentally allows cgi-scripts to be sent out as plaintext documents. Ouch. That's why for all of my Perl and PHP scripts, I include the database server connection details using an include file which is saved outside of the webserver root. Of course, this isn't 100% secure, since anyone who has local filesystem access to the server can still get at the information, but then again, if someone has achieved that level of access, you have bigger problems than worrying about your DBI include files and CGI scripts ;) You can even go one step further, in banking practices, you typically never access the database directly anyway from a CGI. Instead you have a multi-DMZ (well DMZ isn't the exact right term) but multi-partitioned architecture so that if someone does break into the web server they still do not have direct access to the database. Something like Internet - Firewall - WebServer - Firewall - App Server - FW - DB Server Each major server essentially being controlled by dual homed hosts on separate subnets with the network interface on the firewall only controlling a single direction of traffic to the server in question. Of course, most normal people can't afford this and make do with chrooting and running on a dedicated host with a linux IP Tables firewall on one single machine even if they go dedicated. As an aside, eXtropia has an open source toolkit which allows this higher level of indirection without any application logic programming. The abstraction is called Extropia::DataSource (written in Perl) and for this abstraction we have DataSource::File (For flat file) and DataSource::DBI (for DBI). But if you require stronger security (like the above approach), you can use our DataSource::SOAP which talks to a Java Servlet container (as the app server eg Jakarta-Tomcat) running code from the Apache SOAP Project as the infrastructure and then on top of it, our com.eXtropia.datasource.soap.SoapDataSource package wrapped around our com.eXtropia.datasource.SecureDataSource API. The SecureDataSource API allows you to restrict permissions in a way very similar to how permissions are restricted using grant statements on SQL and in addition the password to the database is stored in the middleware server (breaking into the webserver does not grant access). The other cool thing about this is that most servlet containers also handle JDBC connection pooling for you (an additional performance boost which makes the performance lag introducing a middleware server more reasonable). Of course, you can go even farther than this. Obviously the best middleware server will contain the equivalent of stored procedures which tightly restrict in a typed concept, what sort of data may pass into it and out of it (as opposed to essentially arbitrary queries). Later, Gunther -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: postie (command line mailer for windows)
Lynn,
If you are interested in an alternative tool to send mail than postie, you
may want to look at Mail::Sender which is what we tend to recommend to
user's of our NT Scripts. Although if anyone has more up to date
information on the best Mailer to use for NT, I'd be glad to hear it and
update our documents. :)
One thing you should also be careful about is that programs that require
command-line input to pass parameters are really quite dangerous
potentially so we tend to shy away from them. I don't know if Postie is
like that, but Blat definitely is. Of course, you can use the array context
system() call as well as taintmode but it is still risky.
In addition, launching an extra process on windows (especially) is quite
expensive and slow. So your feeling on using SMTP is good.
If you are interested in a fairly generic API to send mail from CGI
scripts, all our newer scripts come with Extropia::Core::Mail API which
supports drivers for blat, Mail::Sender,
NTSendmail and Sendmail natively with the exact same calling API.
We did this because the state of mail packages out there on CPAN seem a
somewhat disjointed (especially with poor support for NT). But eventually
should they become better we'd end up replacing our API with theirs (the hope).
The modules for doing this come with our current WebCal and WebDB
distributions. We try quite hard to make sure they work under NT, so most
of the stuff should be NT compatible.
The usage is quite simple
use Extropia::Core::Mail;
my $mailer = Extropia::Core::Mail-create(
-TYPE = 'MailSender',
-SMTP_ADDRESS = 'something'
);
$mailer-send(-FROM = $from, -TO = $to, -SUBJECT = $subj, -BODY = $body);
And that's pretty much it. I am pretty sure this will work well on NT for you.
You can download Mail::Sender using PPM on your NT Server. So type
ppm
And then
install Mail-Sender
Note that the PPM package for Mail-Sender is not available for older Perl's
I think. But it definitely downloads fine for me on ActiveState Perl 5.6.1.
Anyway, I think Mail::Sender will be much easier for you (even if you
decide to use it natively) than Net::SMTP.
Later,
Gunther
At 01:15 PM 9/4/2001 -0700, Lynn Glessner wrote:
Here is an interesting tidbit for anyone thinking of using the command line
mail tool postie on Windows from their cgi script.
I decided to send email through a system call to postie, just because postie
is how I have always sent mail from the command line in Windows :) I
couldn't figure out why I was getting a display error from IIS - it worked
fine in a test script but not in my real script. Turns out postie was
wanting to display a complaint about CGI, and I finally found this tidbit
from the author of the utility:
To run Postie from a CGI program and get it to process command-line
arguments properly you must first un-set the environment variable
'GATEWAY_INTERFACE' or run the program without inheriting the parent CGI
program's environment
In other words, use undef(ENV{GATEWAY_INTERFACE}); before executing your
system command calling postie, and then all is well.
Thought I would pass this on so no one else wastes time on the same thing, I
only found one mention of it in my google web search and and none in my deja
news search (or whateve it is called now) so it most not be a very popular
way to go - or else people give up and do it another way.
BTW, I looked at the NET:SMTP included with activeperl and didn't see how I
could make the contents of a text file be the body of my message. If someone
can tell me how that is possible, I would prefer to use that method in the
future. (I'm avoiding installing any more modules than what were included.)
--
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 commands, e-mail: [EMAIL PROTECTED]
Re: active perl on IIS
At 09:07 AM 9/3/2001 -0700, Lynn Glessner wrote: That did it - thanks :) I am slowly but surely getting this changed over. I changed FORM ACTION=c:\inetpub\scripts\sl3.pl to FORM ACTION=http://198.162.0.1/scripts/sl3.pl; (Obviously if I decided to make this public I would need a different IP or hopefully a DNS name.) I can't believe this is taking me so long, when the script WORKS on a different OS and web server, but hopefully once I have gone through this once I'll be able to do this again in the future (or just develop on the same platform, that would be nice!) As an aside, you should consider that your action does not even have to be an absolute URL. Even if the form is in the HTML tree instead of the CGI tree, you can at least get away with just ACTION=/scripts/myscript.cgi isntead of the whole HTTP://etc.. If the form was generated by another scripts in the scripts directory, then you can get away with ACTION=myscript.cgi. And finally, if the script that generated the form is the same that is being posted to, you can leave off ACTION= entirely because the default action is to submit the data to the same exact script. Later, Gunther -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: active perl on IIS
At 08:36 AM 9/3/2001 -0700, Mark Bergeron wrote: Let me also add, unlike *nix, you may run scripts from virtualy any folder you see fit on Win (within wwwroot for the web of course). Everything is really governed by the permissions and etc... you set on the folder itself. In some cases it makes sense to name the cgi folder something less obvious like, wordfiles, oldapps or the like. Be creative. This way should the casual hacker break in you stand a chance of he/ she skipping the directory. At the very least, someone is sniffing your tranfers might not suspect your moving them into an executable dir. Just a thought. MB' I don't fully understand this advice. If the casual hacker has broken in, then it seems that they already have more or equal power than they would be able to gain through hacking a scripts directory. As for sniffing file transfers. I suppose that is a valid issue, although it seems to me that someone sniffing an FTP session would sooner be able to get your plaintext password and be able to search around themselves. Even if the directory in this case was renamed, the script itself is not. So something like formmail.pl would still be formmail.pl even if it is in an oddly named directory. I am not saying there is no case for it at all. But it doesn't seem that strong for the annoyance of dealing with an obfuscation in your own setup. I think a human reading the directories would be able to figure out where things are. However, I also think that script kiddies are certainly something to watch out for if you are afraid you might miss a Microsoft security patch one day. One thing to consider then is that renaming the scripts directory may prevent an automated hacking script from putting something in the defeault c:\inetpub\scripts directory. So perhaps if this directory were renamed to something that is not obfuscated to make it hard to manage, but still different (eg maybe call it scriptstuff) then the automated scriptkiddle script will be thwarted. This is similar in concept to the idea of renaming root (which seemed to be advocated at SANS even several years back, don't know if it still is) just to prevent some scripted attacks from being able to log on as root. But they didn't precisely advocate renaming root to something that is obfuscated -- just renamed enough to fool the scripts of that day. Anyway, I'd like to hear more evidence of how strong renaming the scripts directory really is against attacks as I could be wrong in my assumptions. Thanks, Gunther -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: active perl on IIS
At 02:59 PM 9/2/2001 -0700, Lynn Glessner wrote: I haven't had a chance to work on it recently, but I think it will turn out to be the .cgi extension (I'll have to go back and see who suggested that). I have my scripts in a directory which was created automatically called scripts a subdirecctory of c:\inetpub - IIS has it configured for executables. However, all my perl scripts in this directory have the Yeah, Joel was correct in his previous mail. There is no cgi-bin directory created in IIS. My poor memory was really referring to this directory, which should have worked. extension .cgi. Double-clicking one of the example files installed by ActivePerl (those files have a .pl extension) executes fine, but my .cgi files have a generic icon - can't believe I didn't think to check that. Yes, this would have been a clue, but don't feel bad. This is deceptive because IIS actually pays little attention to the file manager associations. So .cgi could have been associated in IIS but the Windows Explorer still gives no icon if they were set up differently. I am not sure about Microsoft's motivation of separating Explorer from IIS file ending associations. It possible this was done for security reasons so that not all files become executables in IIS unless configured for IIS. I have the O'Reilly CGI book, with the rat/mouse on the cover, it is very helpful for CGI and Perl. I have the working version at work, it's just the implementation at home on IIS that I'm struggling with after doing my development at work. :( Well if this is just a home machine, I think someone else had also suggested using Win32/Apache. This might also be easier unless you are familiar with using IIS for everything else you are experimenting with. If you do get the simple .cgi works in the scripts directory, then also note that if you dump your .cgi inside of c:\inetpub\scripts (if thats your directory) then the program will work when you use relative paths. But your relative paths won't work if you put it in a subdirectory of c:\inetpub\scripts because IIS always does the equivalent of chdir back to the root of the c:\inetpub\scripts directory itself. So you need to make all paths relative to c:\inetpub\scripts rather than, say, c:\inetpub\scripts\myScriptArea if you put myscript.cgi in there. Although you haven't run into this problem yet, I mention it in advance because it's the next most common complaint I see next to the file association one with regards to how to make an application work. Thanks very much for the suggestions, I hope to be able to tackle this tonight (after my 2 year old goes to bed - she doesn't have much patience for programming yet!). :) -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Win32 Apache and Perl
At 03:59 PM 9/1/2001 -0400, Brett W. McCoy wrote: On Fri, 31 Aug 2001, Shannon Murdoch wrote: Is there any way (I'm sure there is) to make my perl scripts run with the standard unix shebang instead? Yes, use Unix. :-) So helpful for the Operating System challenged. :) If you are usig ActiveState, you have to use the Windows way of using pathnames. If you are using CygWin (which is a POSIX emulation layer for Win32), you can use the Unix-style shebang line with CygWin's version of Perl. Brett, are you sure that this is the end of the story? The parsing of the shebang line is not purely a function of the Operating System layer (as you suggest using CygWin) but is also a function of Apache (specificially on Win32). I have tried and was successful with the following technique 3 years ago, but I do not know whether such a technique will still work. The premise is that Apache (on Win32 -- this is a special feature of Win32 Apache) already understands #!c:\perl\bin\perl.exe. It's actually a *really nice* feature because it allows you to enable warnings and taintmode without mucking about with the the file association registry stuff -- I could go off on a soapbox now about this but I won't. But, when I experimented with different things I found that Apache could interpret and understand by itself, the following things in Win32: a) #!c:\perl\bin\perl Taking of .exe works b) #!c:/perl/bin/perl switching the backslashes representation works. c) and a final experiment #!/perl/bin/perl Shows that Apache understood that it was also installed on the C: drive and therefore did not need the pointer to let it know to find Perl there. So this would lead us to figuring that #!/perl/bin/perl could be made to look like /usr/bin/perl. How? Easy enough I think. I basically installed Perl into c:\usr instead of c:\perl so that bin was under c:\usr\bin. And that worked for me. I can't say if this still works but if Apache is doing the interpretation I don't see why not. Note that this is an Apache feature -- this won't help you with brain dead web servers like IIS that make it really hard to set up CGI/Perl. But since the question was specifically about Win32 Apache, I've obliged to talk about it. One other note is that rather than going through another ActiveState Perl install into \usr, I think that you can simply make a copy of perl.exe in c:\usr\bin\ and keep your perl distro where it is as the registry or some other setting in windows actually knows that the Perl distro for that binary is in c:\perl and so this technique can be tried out in an even *easier* fashion than my first suggestion. Shannon, if you would be so kind, I would be interested to know this technique still works if you end up trying it. Good Luck, Gunther -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Is it a security risk to use identical names for database fields and html forms?
At 02:29 PM 8/31/2001 +0100, yahoo wrote: nah! what difference does it make? I mean, if they guy gets access to your DB server then he's gonna find out the fieldnames anyway! If he can't get access to your DB then what has he got?, a few POSSIBLE DB field names (i mean, how does HE know the names are real?) for him to attempt to recreate fragments of the data model pah! best of luck... joel Joel, while I do think that this is a nice succinct reply to the thread, I am not sure that it really uncovers the entire problem. It's a bit hard to understand what you mean in your post as you don't really qualify the phrase access to the DB. Sure, if I have a TCP stream to mySQL, it's possible to get anything. But access to a database through exploiting CGI is not always perfect and therefore being able to glean extra information is helpful to any cracker on the system. I do firmly believe that restricting the information you give the user about your system will help security, but I also think it is a matter of diminishing returns and would rather the user who asked the question focus on the things I highlighted in my post yesterday (eg quoting issues, data validation, etc). If the SQL is exploitable, then mucking about with the fields whose values are obvious candidates for being sent to the database makes a difference. But further, it does make a difference to know about the field naming when it comes to extrapolating how to generate the rest of the query. Do you really think that this is inconceivable? The following URL is a well-written account of rain forest puppy hacking into a BBS forum software by exploiting it's error handling routines to gather some bits of information about how the queries are being created and exploiting that information through the CGI script. http://www.wiretrip.net/rfp/p/doc.asp?id=42iface=2 Since I read this article and then in reviewing the security of other CGI scripts, I have found exploitable SQL code in at least several places. I guarantee that bad SQL coding is a problem for sure in the latest CGI scripts. But the degree varies from application to application. Just as seeing one cockroach in a kitchen actually entails a million more behind the walls, since reviewing CGI security is not a full time job for me (just an occasional if someone asks me), the fact I have seen this much exploitable code is an indicator to me that the problem is currently quite huge. In summary, I would heartily encourage careful best practices for SQL coding in Perl as I indicated yesterday and as RFP describes in the URL I gave above. And I would agree that the form variable changing names is probably not that useful to avoid attack, but I would not agree that it's entirely useless. I think risk assessment is a reasonable thing for this person to have asked about on this list, and shows a smart attitude towards security. Especially this person questioning why his colleague suggested doing this. Implementing old wive's tales of security (eg knock on wood, don't walk under ladders, untaint all your form input) without understanding the why behind it is sometimes just as bad as not having implemented the solution at all. For example, as I pointed out yesterday, if you obfuscate your form, you'll make creation and subsequent maintenance of the program much harder because it will be yucky to constantly convert from obfuscated form variable to real database field. Unclear code leads to bugs, and by probability some bugs are security bugs. Anyway, I apologize if I misunderstood the intent of your reply to the thread, but I personally had found it sufficiently vague that I wasn't sure what you were really advocating or thinking was the risk here. Later, Gunther -Original Message- From: Michael R. Fahey [mailto:[EMAIL PROTECTED]] Sent: 31 August 2001 13:33 To: [EMAIL PROTECTED] Subject: Is it a security risk to use identical names for database fields and html forms? Hi, I was looking at a perl script where the developer used different names for the incoming parameters and the database field names. He told me that this was done for security reasons-- to ensure that malicious users would not be able to discover the field names in the database being updated or queried. How dangerous is this? I think it would be easier to work with a hash of parameters from the input form. I'm using cg.pm, DBI, and postgresql. Thanks. Michael Fahey -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- 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
Re: Is it a security risk to use identical names for database fields and html forms?
At 01:55 PM 8/31/2001 -0700, Curtis Poe wrote:
--- Michael R. Fahey [EMAIL PROTECTED] wrote:
Hi,
I was looking at a perl script where the developer used different names
for the incoming parameters and the database field names. He told me
that this was done for security reasons-- to ensure that malicious users
would not be able to discover the field names in the database being
updated or queried. How dangerous is this? I think it would be easier to
work with a hash of parameters from the input form.
I'm using cg.pm, DBI, and postgresql.
Thanks.
Michael Fahey
Hi Michael,
Great question! This raises some security issues that many people just
don't consider.
This is true. Kudos to any beginner asking about security at all!
Wether or not this is a security risk depends upon exactly how you use the
incoming data. Let's
look at a short script that does this horribly, horribly wrong:
#!/usr/bin/perl -w
use warnings;
use strict;
use CGI qw/:standard/;
use DBI;
my $dbh = DBI-connect( 'dbi:ODBC:stuff', 'name', 'password',
{ RaiseError = 1} ) or die DBI-errstr;
my %data = map { $_, param( $_ ) } param();
my ( @fields, @values, $name, $value );
while ( ($name, $value) = each %data ) {
push @fields, $name;
push @values, $dbh-quote( $value );
}
my $sql = INSERT INTO theTable ( .
join ( ,,@fields) .
) VALUES ( .
join ( ,,@values ) .
);
print header,
start_html,
p( $sql ),
end_html;
So far, everything might look okay. The developer was even security
conscious and quoted the
values. Imagine what happens if this script is called with the following URL:
http://www.somehost.com/cgi-bin/db.cgi?name=Ovidcolor=red
You get back a nice Web page with the following SQL:
INSERT into theTable ( name,color) VALUES (Ovid,red)
That's all well and good. Now, let's alter the URL slightly:
http://www.somehost.com/cgi-bin/db.cgi?name%29%20VALUES%20%28%20%27Ovid%27%20%29%3BDROP%20TABLE%20theTable%3BINSERT%20INTO%20theTable%20%28name=Ovid
Hmm, that's a bit more complicated. I wonder what the SQL is?
INSERT INTO theTable (name) VALUES ( 'Ovid' );DROP TABLE
theTable;INSERT INTO theTable (name)
VALUES ('Ovid')
Oops. We might lose that table. Now, by crafting a good query string, we
can attempt to execute
arbitrary SQL against the database (there are many, many variations of
this attack). These
attacks are kind of tricky because you usually need to craft the URL in
such a way as to ensure
that *all* of the SQL is valid at the time it's evaluated, but it's still
a possible exploit.
There are ways to make this secure and still use the field names, but I
wouldn't suggest it. While
I am not an advocate of Security by Obscurity, I do advocate not revealing
information that you
don't need to reveal.
An important additional point is that simply renaming your form parameters
to be different from the database, you would still usually have a 1 to 1
mapping from the form to the database field name somewhere in your code.
So the above code that was given as an example could possible screw things
over for you even if you renamed the variables. And conceivably, you could
play tricks if you knew more about the database to issue alternative
queries in-line if a section of the CGI script is issuing queries itself.
While it is conceivable that security through obscurity has SOME value, I
am not sure that in what might be a large program that such a mapping helps
your programmer's thinking process in terms of writing and maintaining the
code later.
If the form vars are renamed with an obvious prefix like fname in the
database becomes form_fname then it should be obvious to a cracker that
form_ is a standard prefix. So the best way to rename the variables is
fairly randomly. But this will suck for your maintenance of the code. I
suppose you could have a filter function that takes CGI.pm and remaps the
form values inside of it, but it's still harsh on the forms developer for
debugging and always remembering the mapping. What a yucky thing to have to
work on then!
I would tend, therefore, to shy away from security through obscurity in
this case and focus more on how to make the SQL secure itself. As has been
pointed out in the last post well, validation of input is very important.
For an introduction of the basic issues, any documentation having to do
with taintmode is quite reasonable to read. eg
http://www.gunther.web66.com/FAQS/taintmode.html
Also, if you are writing SQL code, you should definitely consider the
following three issues:
1) The quoting issue was discussed by the previous poster.
But there was no solution presented. Here are two reasonable ones:
a) Use DBI's quote() method and run it through all the values to be set in
