So, I decided to try to break my website...I googled my site by typing in site:mysite.com/whatever and behold, all of the users uploaded files were available for view under a specific directory.
What kind of script/ counter measure should I use to block these files from being viewed? I already have a script that checks the path and the logged in status, however this doesn't seem to be working. I've looked all over for solutions...but I can't quite find one. I'm using ColdFusion 8.
This isn't a ColdFusion issue so much as a web server configuration issue.
You should either:
configure your web server not to show a directory of files when using a URL without a filename (e.g., http://www.example.com/files/)
drop a blank default web document (index.html, index.htm, default.htm, index.cfm, whatever) into that directory so that it displays that document rather than the list of files. If you use index.cfm, it'll fire your Application.cfm/cfc in your file path and use whatever other security you've built.
(or, better, do both)
The best way to secure your file listings and the files themselves is to store them in another folder outside of the Web site root folder. You can then serve them up using CFDIRECTORY and CFCONTENT. The pages that display the files can check your access controls and only serve the files to those allowed to see them.
Related
Bit of a loose question so if it gets marked down I'll remove it.. but..
I'm using Primefaces/Spring/Hibernate for Java server.
My application knows a load of file names I need to upload. Those files are on my local computer. Is it possible to tell the application the root directory of these files, for it to then setup uploads for each of these files without me needing to browse for each file individually?
I assume this is a browser security issue, i.e. the user needs to explicitly state which file the application is allowed to know about etc?
If not I'll have to do it in a local application but I was hoping there was a way a mass upload could be kicked off from the browser by just setting the local directory of the files.
I decided to use the Primefaces uploader, upload all the files in the directory and let the application sort them out once it has them on the server.
I have an asp.net project that I use for a couple different purposes. We have addresses that access the same virtual directory via different paths (use1.company.com and use2.company.com) I do not want to break the project up as they use similar functionality that seems redundant to have in two places. None the less as it stands use1.company.com/default.aspx and use2.company.com/default.aspx both are the same. I want to make it so that use2.company.aspx/default.aspx is not accessible. Is there a way to do that from the App Pool/Virtual Directory settings or do I just have to hope that external users dont type /default.aspx?
I know I can set the default document to like survey.aspx (purpose of the second url) but that does not prevent some savvy users from typing in default.aspx just to see what it does. Any assistance here would be great.
Since they point to the same .aspx file could you not include an if statement at the start of the file to grab the URL and if it includes use2 then go back?
Just getting my head around the new Azure web sites feature and hitting my first obstacle. I'm deploying a PHP site which writes cache data to the file system, but the app is throwing an error because the folder it wants to write to does not have write permission. Is it possible to set permissions on folders or is this a no-no?
I can probably work round this but would like to know if it's possible.
Folder permissions cannot be set/customized. This means whatever location your app writes to should be under your site root.
Your site can only write to locations under C:\DWASFiles\Sites\[siteName]\VirtualDirectory0 and to the %TEMP% folder.
Two caveats here:
Stuff can't be written directly under VirtualDirectory0, you have to create a subfolder under there and place your files in that subfolder
The %TEMP% folder really is temporary! If your site instance goes down for any reason and is brought back up somewhere else then everything in your %TEMP% folder will be gone. Use it only for files that really are temporary.
Is the folder that the app is trying to write to under the site's folder?
It's my understanding that folder permissions cannot be set/changed. But I haven't seen anything from Microsoft that definitively says "yes" or "no" to that.
It should be possible using webdeploy.
However I don't think there is a way do it without manually setting up the webdeploy package - as described in the post http://blogs.msdn.com/b/azureappgallery/archive/2013/04/03/set-file-folder-permissions-for-your-content-on-azure-website-using-web-deployable-package.aspx.
Our site is currently set to pass all files with the xml file extension through the asp.net worker process because all the xml files on the site at the moment are generated dynamically on being hit, by writing the output directly into the response stream.
However we now have a requirement to add a file which is much larger and takes several minutes to generate in this way. I wrote a console app to generate the file and set it to run nightly, but because of the global IIS setting directing xml files to run through asp_wp, it's not being served properly.
I can't seem to find a way to make an exemption for the treatment of a single file in the IIS settings. Is there any other way we can do it?
Cheers,
Matt
As far as I know, this is not possible for a single file, but you can do it for a whole folder.
You simply place a web.config file in the folder in question and configure the settings you need there.
What files should/should not be stored in the cgi-bin folder/directory on a web server?
Obviously, executable scripts/files that make up a web application, called from a web browser can be stored there.
But is there a common industry opinion about what else can be stored there?
Is there a very strong reason why nothing else apart than the scripts/executables is allowed there?
My preference is to store all files belonging to an application in the cgi-bin directory/folder, as a subfolder off it - for each application.
For example directory cgi-bin/myapplication would contain:
the cgi scripts/executables
datafiles
configuration files
This simplifies installation and also simplifies the steps to run different versions of a application in parallel, e.g. for trialling a new version.
Concerns about security access to non-script files can be addressed by using the correct user permissions and also Apache .htaccess to control access to the directory and files.
It would seem that popular free applications are in favour of this everything-under-one-directory approach: The versions of bugzilla, the free defect and feature tracking tool, e.g. 3.4.4 are offered in this structure, while earlier versions, e.g. 2.x installed bugzilla components to at least three folders.
Drupal, the powerful and popular free content management system also takes this approach of everything-under-one-directory, albeit doesn't use the cgi-bin folder but the approach is the same.
What are your thoughts?
There is nothing special about the cgi-bin folder. It is like any publicly-accessible web folder that has the "allow-script" flag set (or the equivalent for your web server) - something that has become almost meaningless in the world of PHP/JSP and the likes.
You should only store files that you wish to be public in any folder under your webroot. You probably don't want your data and configuration to be downloadable by any user on the internet, so don't keep them in /cgi-bin
Certain servers may try and execute any file in /cgi-bin if requested. This could cause problems, especially if text or data files are executed as shell script.
Applications like Drupal are intended to be easy for anyone to install, regardless of what permissions they may have on their web-host. This is the main reason it keeps everything together. If you have the ability to put files where you want, it is always a good practise to keep non-public files outside of the webroot. If you must keep them under the webroot, then ensure that you use your server's configuration to deny public access to the non-public files.