I am still unable to figure out the following which are related to Oracle padding security issue. The no. 1 point is in general which I wanted to know the easy way to change the Machine key. The no. 2 point is related to Security issue.
If I change the machine key then how easily I can change the user passwords stored in the DB. User passwords are also encrypted with same machine key. Changing the key will make passwords to become invalid. Please correct me if I am mistaken.
In webresource.axd?d=..., What is the data type stored in 'd' parameter. How it will allow to download any arbitrary file. I know only that it can allow embedded resources to download. But can someone show an example to download web.config file using webresource.axd. Everybody talks that web.config can be downloaded but I did not find an example of doing that.
I will be glad to know if someone can answer with simple example. Please do not point me to ScotGu blog and after reading his blog and recommendation I do not want to visit his blog again and am surprised to know how he is leading asp.net team.
I'll try to answer your questions from what I have learned about the issue so far.
User passwords in the DB are not at all related to the machine key of the app. The ASP.NET worker process by default generates a new machine key every time your app is restarted.
(Thus, if the DB passwords were dependent on the machine key, they would become invalid in every few days.)
About downloading Web.config, we don't really know. Some people think that it is dependent on another security hole. If you use MVC (or WebForms without these), it is the safest if you disable the .axd requests. (Handle *.axd with HttpForbiddenHandler)
For example:
<httpHandlers>
...
<remove verb="*" path="*.axd"/>
<add validate="false" verb="*" path="*.axd" type="System.Web.HttpForbiddenHandler, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</httpHandlers>
Or do the same in the system.webServer section if you are using IIS 7.
Related
I'm trying to find all the locations in which a connectionString can be defined for an iis site (to write a script to extract them all).
I know it can be part of a web.config. I would like to have a complete list of files it can be configured in.
Does it make sense for it to be configured in the site code?
Which other configuration files can define a site's connectionStrings?
And a bonus question - how do I know the order of the files in which the connectionString is searched in ?
Thanks,
EDIT:
Additional info - all IIS sites are pure dotnet sites.
Also, specifying the general location of files, rather then file names, is also helpful.
E.g. - connectionStings can be located in external configuration files, whose location is defined at a in an appSettings element in the "%runtime install path%\config\machine.config" file.
Another option is to just link to the relevant docs.
My issue is that I haven't found anything conclusive.
As far as I know, there are several ways to configure connectionstring in ASP.NET applications.
Define it in code. This is the method used by many beginners. Because at this time they focus on code learning and logical understanding. But some people are accustomed to using it if the database is fixed, it does not need to be modified.
SqlConnection connection = new SqlConnection("Data Source=.\\SQLEXPRESS;Initial Catalog=mytest;Integrated Security=True");
Define it in web.config or App.config. The benefit of it is easy to modified connectionstring after publishing application. Developers can change web.config, no need to change code and deploy application again.
<connectionStrings>
<add name="mytest" connectionString="Data Source=.\SQLEXPRESS;Initial Catalog=mytest;Integrated Security=True;" providerName="System.Data.SqlClient" />
</connectionStrings>
Using External Configuration Files. ConnectionString is stored in a independent file for example connections.config. The benefit of it is modifying an external configuration file does not cause an application restart.
<?xml version='1.0' encoding='utf-8'?>
<configuration>
<connectionStrings configSource="connections.config"/>
</configuration>
About list all connectionstrings, you can use ConnectionStringSettingsCollection. It can get a connection by name and provider name.
I found a pretty good source for the locations of the IIS dotnet Framework configuration files - https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc754617(v=ws.10)?redirectedfrom=MSDN#inheritance
You could define additional connectionStrings
In dotnet code.
In env.
In external config files.
For non-IIS scopes - such as user scopes and role scopes.
These 4 options are not specific to IIS.
I don't know where options (3) and (4) are defined, and I'm not sure if this list is complete. But by combing this list and the one in the doc, I think we have 99% coverage of defined connectionStrings.
Since about a week when I publish a new version of our Web App and do a Swap from Staging to Production, it actually seems to swap before the warmup initialization is done.
As it is a large application it will takes more then five minutes to warmup the site, making the application unresponsive.
I have official Azure support, but it is taking a long time to respond to this request and I still have no answer that works.
I can't fix any issues on our platform or publish a new version without bringing the whole site down for eight minutes. This is a highly visited website, with paying clients.
Does anyone know:
anything that I could investigate myself?
a workaround or any tips that I can take a look at myself to try to fix or work around this issue?
Extra information
I do use applicationInitialization, and I see that Azure is hitting the pages - it just happens after the swap instead of before.
<system.webServer>
<applicationInitialization>
<add initializationPage="/nl" hostName="mydomain.com" />
<add initializationPage="/warmup-application-for-azure" hostName="mydomain.com" /> (special page just for warming up services)
<add initializationPage="/deeplink1" hostName="mydomain.com" />
<add initializationPage="/deeplink2" hostName="mydomain.com" />
[etc]
</applicationInitialization>
</system.webServer>
Maybe not 100% relative to this question but since I had similar issue with warm up I want to share how I solved it.
I used to have issue with auto-scaling because my nodes were not warmed up due to url rewrite module. So what if you have url rewrites in your app make sure that you are checking for
<add input="{WARMUP_REQUEST}" pattern="1" negate="true" />
Now this is in official documentation and it has link to common problems
This was an Azure bug, confirmed by the Microsoft Azure team.
Sometimes hitting the site’s root URL is not enough to completely warm up the application. For example it maybe necessary to hit all important routes in an ASP.NET MVC app or to pre-populate the in-memory cache. That is where the Application Initialization Module can help.
When you use the warmup-functionality provided by IIS (and Azure) instead of those old-fashioned methods and if deploying to an App Service, just add a slot setting to make sure it always triggers such as below:
This tutorial explains how you can use the recently enabled Application Initialization Module to completely warm up your application prior to swapping it into production.
So here is the important thing you should consider:
Unless you specify which url address azure needs to request to your website, how can it knows. If you don't do that, it only calls the root of the application
Even if you specify the url and your url needs to authorisation/authentication, how can azure sign in your website automatically and call the url that you specify.
You have got two option to deal with it.
1) Write your own warming up api to call your web application with authorisation/authentication. Then create a scheduler to call the application every hour or half an hour. It also allows you to keep the entire application up & running & warm. You can also set AlwaysOn feature under the Application Settings. You can also trigger this api on your CI/CD pipeline after the staging slot deployed successfully.
2) If you don't want to touch your CI/CD pipeline or whatever reason and don't want to write api, you should sign in to your web application, go through each page and warm it up manually. Then you can swap without any problem.
My application has a virtual directory that points to a shared folder of images on a remote file server. When trying to access the images via the browser (like http://webserver/app/VD-alias/image.png) I get a "configuration error":
An error occurred loading a configuration file: Failed to start monitoring changes to '\\fileserver\sharedfolder\web.config'.
After a lot of investigating I suspect this is a security issue. However:
The AppPool uses Integrated pipeline identity is NETWORK SERVICE.
The file server only allows user domain access not machine account access (which is what the web server would use for this AppPool identity).
But in IIS, the virtual directory is configured to use specific domain account credentials to access the shared folder, so everything should be fine regarding access.
After a lot of investigation I realized that this had to do with the Glimpse defaultRuntimePolicy being On. When I turn it off, everything works fine. At the moment this is my Glimpse settings in web.config:
<glimpse defaultRuntimePolicy="On" endpointBaseUri="~/Glimpse.axd">
<runtimePolicies>
<ignoredTypes>
<add type="Glimpse.AspNet.Policy.LocalPolicy, Glimpse.AspNet" />
</ignoredTypes>
</runtimePolicies>
</glimpse>
So I'm wondering if Glimpse is not using the virtual directory credentials set by IIS? Or what else could Glimpse be doing differently that would prevent access to the images?
In any case, I was wondering if there was a way to prevent glimpse from interfering with that specific path or with images in general?
I've tried using:
<uris>
<add regex=".*uploads.*" />
</uris>
and
<uris>
<add regex=".*/.*\.png" />
</uris>
and
<contentTypes>
<add contentType="image/png" />
</contentTypes>
I've also tried changing the runAllManagedModulesForAllRequests. I've tried different IIS versions and the latest Glimpse version.
But none of them seem to make any difference except when I turn off Glimpse.
Has anyone faced this issue? I'm pretty sure it's reproduceable. How can I get Glimpse and my virtual directory to play nice?
Thanks in advance.
I am working on a cloud application. When I test out the application on my computer I want to have my connection string set as follows in ServiceConfiguration.cscfg:
<Setting name="DataConnectionString" value="UseDevelopmentStorage=true" />
When I publish to the cloud I need to have it set as follows:
<Setting name="DataConnectionString" value="DefaultEndpointsProtocol=https;AccountName=xxxx;AccountKey=yyy" />
I keep going from one environment to the other and keep having to change the DataConnectionString.
Is there a way that I can automate this? I looked around and can't see any examples but I'm sure some others have the same problem as me.
Thanks,
Nancy
I've answered a similar question here:
Visual Studio 2010 can apply Debug or Release transformations to Web.config, but what about the Azure settings?
While Igorek's approach works perfectly we prefer to make such kind of transformations on our CI server which is also responsible for automatic deployment. The main reason is to restrict access to sensitive data, since only limited number of trusted developers have access to CI server. Also, it helps to keep our code cleaner, since it doesn't include redundant config project. In our case we use Hudson-CI (Jenkins-CI) and MSBuild.ExtensionPack.FileSystem.File (replace action) to transform config files.
In the part of your code that gets the connection string, you can use the #if(DEGUG) preprocessor directive in order to use something or not depending if the compilation is Debug or not, or the if(Debugger.IsAttached) (MSDN) in order to know if the debugger is attached.
You can use CloudConfigurationManager in Azure SDK 1.7 http://msdn.microsoft.com/en-us/LIBRARY/microsoft.windowsazure.cloudconfigurationmanager
This starts by looking in the ServiceConfiguration.cscfg e.g. ServiceConfiguration.Cloud.cscfg for config setting. If it isn't there it falls back to web.config and app.config
For example
CloudConfigurationManager.GetSetting("StorageConnectionString")
Will look in the appropriate cscfgfile for StorageConnectionString setting, then it will search the web.config and then app.config.
I'm using SEO-friendly URLs, and I can process most of them with ASP.NET, by mapping aspnet_isapi.dll to all URLs. (I set up an Handler Mapping in IIS that uses the dll for all paths. (path = *))
However, that doesn't seem to work when the last character of a "subfolder" is a period. E.g., I have a URL of /brakes/A.B.S./, and that won't trigger the mapping. So I end up with 404s for such URLs. Does anybody know how I should setup the mapping to trigger this? (I've tried *. and that doesn't work either.)
Try changing this setting in your web.config:
<httpRuntime relaxedUrlToFileSystemMapping="true" />
http://haacked.com/archive/2010/04/29/allowing-reserved-filenames-in-URLs.aspx
As Matthew already pointed out, this is resolvable in .NET 4.0, but not in .NET 2.0. The problem lies in the underlying system: Microsoft forbids names to end with a dot (or a space, for that matter), because Windows Explorer cannot handle them (the underlying NTFS system can handle them, however).
What's the cause
Internally, and this is true for .NET 2.0 and .NET 4.0, a web request is passed, at some point, to the method IsSuspiciousPhysicalPath. Among other things, this method calls a standard API to create an "official" path based on the path given. It doesn't create this path. Then it compares this correct path with the given path. If they are different (i.e., if the given path does not exist in the corrected path) it is considered suspicious.
You can try this yourself: use File.CreateFile to create the file "test.txt....". This will succeed, but the resulting file is "test.txt". In the scenario above, the given file "text.txt...." does not fit the created file, hence it is suspicious and never even reaches the web request handler.
Even a 404-handler in the base IIS settings won't work here!
A far-fetched workaround
A workaround which I've used for years in many setups (for reasons not related to this issue): install Apache in front of IIS and configure it for proxying. That's relatively easy to setup (lost of examples on the internet) and this can act as a buffer for handling these kind of "illegal requests", rewriting them to something IIS can handle.
But it is probably easier to simply move from .NET 2.0 to .NET 4.0
I'm using Web API attribute routing
The selected answer did not work for me, it is only a partial solution.
to make sure the Web API gets the first crack at it, not only will you need to have
<configuration>
<system.web>
<httpRuntime relaxedUrlToFileSystemMapping="true"/>
</system.web>
</configuration>
you also need to have
<system.webServer>
<modules runAllManagedModulesForAllRequests="true"></modules>
</system.webServer>
I found the answer here at this blog:
ALLOW A DOT IN ASP.NET MVC APPLICATION (SPECIFICALLY IIS 7+)
In my case, I couldn't do it using the URL Rewrite while there was another reason which is the URL Scan.
I opened windows\system32\inetsrv\urlscan\urlscan.ini in a text editor and enabled AllowDotInPath by changing its value to 1