I think this is a server setting issue, but when image are uploaded, the file length ends up being 0kb. I don't get any errors in the event log. I can see the file written to the server, it just has no data. I don't know where to look for a fix.
First step i would do is make sure the IIS Application pool has full security control over your CMS folder. If you don't have this set, it may not allow it to write files/modify. You can do this by right clicking on your CMS folder and going to Properties, Security, add user, and search for the user "IIS APPPOOL\TheAppPoolName" on the local machine.
If you're hosted, they may have tools in their file editor to do the same.
Related
I am working on a project that has us deploying to an Azure Web Site.
The code is overall working and now we are focusing more on security.
Right now we are having an issue that back end configuration files are visible with the direct URL.
Examples (Link won't work):
https://myapplication.azurewebsite.net/foldername/FileName.xml (this
file is in a folder that is contained within the root application)
https://myapplication.azurewebsite.net/vApp/FileName.css (this file
is a part of virtual application sub folder)
I have found this to be true with multiple extensions and locations.
Extensions like:
.css
.htm
.xml
.html
the list likely goes on
I understand that certain files are downloaded to the client side and that those can't be stopped. However backend XML files are something we don't pass to the client (especially if has connection strings).
I did read a similar article, Azure App Service Instrumentation Profiling?
However this didn't directly relate to my issue.
Any insight would extremely helpful.
Do not store sensitive information in flat files, especially under your site root. Even if you web.config it just right you're still one botched commit away from disaster.
Use Application Settings instead, that's what they're for.
https://learn.microsoft.com/en-us/azure/app-service-web/web-sites-configure
Using Kentico 9, while I was away it appeared that something changed! While our production site appears to be working fine our staging site is not. When I try to access the staging site it is unable to "find" any of the related CSS or JS files and therefore displays the site without any of those files. Another part of the problem is that the same thing is happening in the admin portal and since the admin portal relies on those CSS and JS files to work I can't troubleshoot there.
When I try to get to the resource directly in a browser: e.g. iddba-staging.azurewebsites.net/CMSPages/GetResource.ashx?stylesheetfile=/App_Themes/Default/bootstrap.css it fails.
When I try to access it directly at the prod site: www.iddba.org/CMSPages/GetResource.ashx?stylesheetfile=/App_Themes/Default/bootstrap.css as I would expect it provides me the opportunity to save the file.
Our site(s) are hosted in Azure.
Any idea of where to turn next? Thanks.
Also on a possibly unrelated note, I have also noticed an error in the logs on staging that is not on prod:
.NET Runtime version 4.0.30319.0 - Loading profiler failed. Failed trying to receive from out of process a request to attach a profiler.
Not sure if this might be related. Thanks.
Once I realized that getresource.aspx was a dynamic file and the css and js files were either already in the database or were in respective directories it looked at the dlls that power Kentico. In this case I decided to see if there were any differences in the bin directories of prod and staging. I don't know how they became out of sync but they had. Since the problems I had appeared to be serving up CSS files I noted that one file CMS.LessCss.dll was in prod and not in staging so I copied that file in. As soon as that file was copied Kentico threw an error with the word Jurassic in it (odd!). I found a file Jurassic.dll that was in Prod and not in Staging so I moved it.
Voila! The site was back, serving CSS and JS files on the front end and in administration. We are still clicking through all our pages to see if anything else is not working but for now we are good and if I have any further questions I will look in bin first since there are still files that live in prod that are not in staging and I don't want to re-populate unnecessary files. I am just not sure how the directories got out of sync in the first place... or at least no one here has admitted to having messed around! Yet.
Thanks for all your help.
We have to fix some security vulnerability in our system, and one of the items is to: disable execution of uploaded scripts/exe's through file upload control.
We have excel upload facility. Lets say hypothetically hacker changes the .exe to .xls and uploads it (there are ways to block that, but ignore that for now). Also assume that
the upload folder is within pubilc directory from where the website is installed in IIS. OR
Someone can access that file by specifying a full path of file thru some api endpoint of which hacker is aware of
Now given that there is an exe or a script which is accessible to the hacker through above means, is it possible for hacker to run that script/exe in someway, so that it can cause harm to the server where the site is hosted?
I am not really security expert hence cant think ways how that can be possible? How a hacker can remotely run exe/script on server, given that they does not have any access to the server.
One of the things that you should definitely do is to remove IIS handlers permissions from running scripts, otherwise anybody can upload a ".asp" or a ".aspx" or any other script engine file and then execute it by requesting it. One simple way to test that is just create a "test.asp" file with "<%= Now() >" and if that returns you the date, then anybody can upload scripts and run them in your server.
The way to disable that in IIS 7+ would be to add a configuration file in a parent directory and edit the permission for handlers, for example assuming a child folder called "public" you can drop the following web.config to disable that:
<configuration>
<location path="public">
<system.webServer>
<handlers accessPolicy="Read" />
</system.webServer>
</location>
</configuration>
You can test then that it should no longer execute the file and instead block it. If you want to allow download of them, then you'll need to configure the static file handler (and request filtering) to handle everything instead, but make sure you do that for that folder only since you don't want people downloading your source code.
Running the script would require remote access to the server, either directly or by exploiting some bug in the website code (similar to SQL injection). The risk here is mostly in hosting malware, especially if you allow user uploads to be downloaded by other users. While getting malware onto a machine is not as simple as just renaming an executable to another file type (it still has to be run as an executable rather than an Excel spreadsheet, for instance, to be able to function), it is possible to embed malware in various types of files, such that the act of opening that file causes execution of the malware. In that sense, you really can't tell at a glance whether a file is malware or not. It could look like an Excel file even open up properly in Excel, but still wreck havoc. The only way to be safe is scan all user uploaded files with a good antimalware application.
As far as running something remotely goes, though, the access to the server required to run the script would provide a much better avenue for mischief that your upload form, anyways. So anyone who could manage that kind of access isn't going to be trying to exploit you through your upload form, and anyone who uploads something malicious without that access can't really do anything.
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.
I'm using multiple computers for development and I want to be able to store my files in my dropbox folder. I went to change the physical path in IIS from c:\inetpup\wwwroot to the dropbox folder but I get this error:
The requested page cannot be accessed
because the related configuration data
for the page is invalid.
I couldn't find the config file so I was wondering if anyone had done this before or whether there a better way to sync everything nicely across several PCs?
I tried it (IIS 7.5, Win 7) and it should work just fine to let your physical path of your web look at your dropfox folder. I would guess your web.config file generally contains malformed XML (see KB942055).
I'd suggest, try to map it to an empty folder just with an index.html file and see if this error still occurs.
As a workaround, I guess you can put Dropbox in your wwwroot folder and set up a virtual directory that points to Dropbox. However, there are some security issues that may hinder you from doing so. I come across a nice tutorial on how to set up Dropbox to IIS as FTP Publishing. Hope it helps.
Hodgin's guide on using Dropbox as FTP publishing.