Re: securing sensitive information in CGI scripts
Hi all, I actually combine both of these suggestions. I have my passwords stored seperately. In fact, I tend to put ALL database functions in one perl module or PHP include file outsite the docroot. It adds an extra level of abstraction when I'm writing my CGI/PHP code. It also means that if I change anything in the database - move machines, change the schema, move to mysql (god forbid) - I only have two files to edit. I then use the firewall approach too. Most firewalls have three zones; green trusted, amber DMZ, and red public. I have my firewall configured so that I only allow port 80 from red to amber, and 5432 from amber to green. Gary On Wednesday 05 September 2001 3:13 am, Gunther Birznieks wrote: 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 -- Gary Stainburn This email does not contain private or confidential material as it may be snooped on by interested government parties for unknown and undisclosed purposes - Regulation of Investigatory Powers Act, 2000 -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: active perl on IIS
Has your set-up defined Perl extension types within IIS? I haven't done this manually on 2K but in IIS 3 you can update it through the system registry under HKEY_LOCAL_SYSTEM \system\CurrentControlSet\Services\W3SVC\Parameters\Script Map. On IIS 4 you can use the 'Internet service manager'. This is a 'Microsoft Management console' application that comes with the 'Windows NT 4.0 Option Pack'. The default extensions are .pl for standard Perl script (map this to the perl.exe file) and .plx this should be mapped to the PerlIS.dll file. This file type will be interpreted by the ISAPI (Internet Server Application Programming Interface) for use by the IIS web server. A .pl file will attempt to run under the operating system not the browser. I believe what you can see working is Perl script (held within the html page) what you want is to run a Perl program from a html page. Check your .plx directories have sufficient execute rights and are attached to the IIS properly. This should be enough to make theme run. I don't know if I've explained this very well but it's relatively straightforward, honest! -- 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: Extened - Re: securing sensitive information in CGI scripts
--- Rajeev Rumale [EMAIL PROTECTED] wrote: I need to store some uploaded files from the visitors into some directories which are inside website root. Rajeev, Why do you need to store them there? If you can answer that for us, we can give you much better advice on how to secure it. Cheers, Curtis Ovid Poe = Senior Programmer Onsite! Technology (http://www.onsitetech.com/) Ovid on http://www.perlmonks.org/ __ 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]
Help me !
Hi People, I need to remove all new line character from a string. Can you please let me know. This is to use for a flat file. When i try to store from a textarea input to a flat file, it has many new line character from the input. Therefor, when retrieve them back from the flat file the data order are messed up. So please help me with this. Thanks. Piraba -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Extened - Re: securing sensitive information in CGI scripts
Why do you need to store them there? If you can answer that for us, we can give you much better advice on how to secure it. Good point I should have included in the question itself. Well many time we don't get acess to directries outside the website root. Expecially in case of shared servers. Regards Rajeev - Original Message - From: Curtis Poe [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 05, 2001 11:53 PM Subject: Re: Extened - Re: securing sensitive information in CGI scripts --- Rajeev Rumale [EMAIL PROTECTED] wrote: I need to store some uploaded files from the visitors into some directories which are inside website root. Rajeev, Why do you need to store them there? If you can answer that for us, we can give you much better advice on how to secure it. Cheers, Curtis Ovid Poe = Senior Programmer Onsite! Technology (http://www.onsitetech.com/) Ovid on http://www.perlmonks.org/ __ 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] -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
