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]
Extened - Re: securing sensitive information in CGI scripts
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]
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: securing sensitive information in CGI scripts
At 04:49 PM 09/04/2001 -0400, Lisa Nyman wrote: >Hi, > >One thing to do is to be sure that the db user who accesses the db >from a web page has properly restricted rights within the database. > >For example, in mysql, you can set table and column priveledges for each >user and table. This is a very good point. I see far too many people setting *global* user access privledges within the 'user' grant table in MySQL, instead of giving that user all "N"'s in the user table, and only giving them specific database level access in the 'db' table. So if someone does happen to get in, they can only muck up that database. mel -- mel matsuokaHawaiian Image Productions Chief Executive Alphageek (vox)1.808.531.5474 [EMAIL PROTECTED] (fax)1.808.526.4040 -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: securing sensitive information in CGI scripts
Hi, One thing to do is to be sure that the db user who accesses the db from a web page has properly restricted rights within the database. For example, in mysql, you can set table and column priveledges for each user and table. Lisa Wolfisch Nyman <[EMAIL PROTECTED]> IT Warrior Princess "Life is too short to wear ugly underwear." Get the facts at http://quickfacts.census.gov/ On Tue, 4 Sep 2001, yahoo wrote: > 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 -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: securing sensitive information in CGI scripts
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 ;) Aloha, mel -- mel matsuokaHawaiian Image Productions Chief Executive Alphageek (vox)1.808.531.5474 [EMAIL PROTECTED] (fax)1.808.526.4040 -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
postie (command line mailer for windows)
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]
securing sensitive information in CGI scripts
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?)? What do you think? regards Joel _ 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]
Access Denied When Trying to Create Directory?
Hey all, I'm simply trying to create a directory on a mapped (remote) drive from a CGI script using the mkdir() function. I keep on getting "Access Denied" errors or the like every time I try to create a new directory. What do I need to do to assign the proper rights to my script so it can work??? I suppose it should be a simple fix, but my brain is presently in stealth mode and hiding. Running on Windows NT 4.0 system with IIS 4 running ActiveState Perl (recent build). Thanks! DTS -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]