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]
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]
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]
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]
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]
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: 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]
