cancel
Showing results for 
Search instead for 
Did you mean: 

Protecting data from direct access on CGI server

kdl
Dabbler
Posts: 13
Registered: ‎11-09-2008

Protecting data from direct access on CGI server

Hi. I'm moving some CGI stuff across to plusnet and it seems to have a slightly strange setup in that the root of the login directory on cshell.plus.net is mapped to ccgi/domain.plus.com/. So, this means that _any_ data (and the source of any scripts themselves) could potentially be served directly to a browser. I'm used to the setup where cgi-bin/-prefixed paths are mapped in the server configuration to a directory (say, cgi-bin/) so that data and scripts can be kept under a different path and are not directly addressable with a browser.
So, how do I secure my data with the plusnet setup? I've looked around and it seems like I might need a .htaccess URL rewriter rule. As this is hopefully a very simple thing to do (map all paths so that they are prefixed with a directory name), does anyone have something prepared that they could share? If not, I'll dive into the whole .htaccess thing a bit more ...
Thanks.
2 REPLIES 2
Ben_Brown
Grafter
Posts: 2,839
Registered: ‎13-06-2007

Re: Protecting data from direct access on CGI server

Hi there,
Although the root directory for our CGI platform is your home directory, this does not necessarily make it any less secure. Any php scripts within it will be parsed as PHP and the results spat out to the browser, not the script source. Any perl/python/bash scripts there will be served up as the source of the script, however this only applies to scripts in your home directory, not those in ~/cgi-bin/ which is where perl/python/bash scripts (as well as compiled binaries) should be stored.
HTH
kdl
Dabbler
Posts: 13
Registered: ‎11-09-2008

Re: Protecting data from direct access on CGI server

Quote from: Ben
Although the root directory for our CGI platform is your home directory, this does not necessarily make it any less secure. Any php scripts within it will be parsed as PHP and the results spat out to the browser, not the script source. Any perl/python/bash scripts there will be served up as the source of the script, however this only applies to scripts in your home directory, not those in ~/cgi-bin/ which is where perl/python/bash scripts (as well as compiled binaries) should be stored

Hi Ben. Hmmm. OK, so you're saying that I should put my "access" scripts in cgi-bin/ and publicise a "/cgi-bin/scriptname.cgi" URL tail even though the domain is prefixed "ccgi."? I guess I can live with that, but it doesn't get around the problem that files in the home directory _can_ be served if the names are known or can be guessed (yes, on the face of it unlikely, but with a lot of these scripting languages, a traceback might be produced when an error occurs - normally this won't be a problem, but in this case, it may divulge the directory structure and filenames of the script code and data files which could then be downloaded). The usual setup is that the URL "root" dir is mapped to some subdirectory of the home directory (say, htdocs) and the cgi-bin/ path prefix mapped to another (say, cgi-bin). In both cases, all access to script source or data files can only be made through the documents and scripts specifically published at those locations. The rest of the directory is data-caged from prying eyes.
To my mind, that does indeed make it "less secure" unless I can state in a config file somewhere that only certain paths and/or files should be served - which was what I was asking. Any idea on how I solve that problem and secure my data?
Thanks and regards.
PS. FWIW, these are python scripts and settings files which will, amongst other things, contain my SQL database address and login details. That database will contain certain personal information about myself and others and therefore I need to take this seriously.