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
Related
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.
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.
I am getting started with Office Add-ins through the Java script API. I am going through this tutorial. When I proceed with the Try It Out section. I get this error. I am getting the add-in to run fine when I give the absolute path in the source location node of the manifest for example E:\Excel-Add-in-Javascript\first-excel-addin\Home.html but its the relative path that is not working for example \\SAAD\Excel-Add-in-Javascript\first-excel-addin\Home.html Kindly let me know if you a solution.
The source location node should not contain a relative path. It should use a complete path, either on the internet or on a network share.
In your case, you need to make \\SAAD a network share, not just a folder.
I don't think that serving from the file path (file:///C:/Users/username/Desktop/something.html) or share is a supported scenario. It may work, but note that it will run differently (and sometimes not run, or be overly permissive) than when you deploy the app for real.
To be clear, you can have a manifest file on a network share for ease of testing the add-in -- and in fact, it's the easiest way to get your add-in registered with Office desktop. But the web content should be served off of a web server (anything from hosting via an IIS local-host web server, to using an Azure Website, to putting your content on github and serving it via https://rawgit.com/).
Background
I work in QA at a software company.
We have about a half a dozen different web applications, each of which may require, at any given site, some customised settings added to its web.config file.
These can range from which Oracle database/schema(s) the app connects to, to how many search results to cache, to which hierarchy to use when sorting items on a web page.
We make use of Microsoft's Deploy package, to get the new releases installed/updated on client sites.
When we put out a new release, some of these customised settings may have been added to or removed from the given web app's web.config file, but using Deploy to import the new release over the top of the old one will clobber any customisations that may have been made.
Alternatives
There are ways of handling this manually, such as merging via a plain text comparison of the old and new web.config files, but these are cumbersome and prone to human error.
I was reading about transformations and thought they could be of some use.
There is also the capability to use external files (tip #8) which seems like a good way to go.
Improvement?
Should our programmers be providing some sort of semi-automated merge facility for this web.config file? Does the Deploy package provide this somehow?
Should we be making use of the external config files, as a best practice?
Is the concept of customising this web.config file at each site so fundamentally flawed that the whole thing needs to be re-thought?
Microsoft provides Web.config transformations as the de-facto way to do this. You can create different deployment configurations within Visual Studio and the web projects. Then when you build or your build server builds with that particular configuration the web.config is transformed to contain the settings you want to see.
View more about web.config transforms here.
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.