I working on a MVC 4 site which has uses Authentication. The site requires that I specify the Machine Key values. I did this via the IIS interface having deselected the "automatically generate at runtime", generated the key values and having selected "generate a unique key for each application"
The web.config entry looks something like this:
<machineKey decryption="DES" decryptionKey="{hex-key value},IsolateApps"
validationKey="{hex-key value},IsolateApps" />;
While this seems to work fine on another web project it causes the "Decryption key specified has invalid hex characters" error on the dev machine I am working on now (both in IIS-Express and IIS 7.5).
Removing ",IsolateApps" from the key values solves the issue but since I need this option on in production I dont want to be removing it now only to have this issue when deploying.
What gives? The dev box is a SQL 2008 R2 box with .net 2.0 and .net 4.0.
The IsolateApps modifier causes ASP.NET to generate a unique key for each application on your server. This is only applicable if you are getting ASP.NET to auto-generate keys at runtime.
If you are not getting ASP.NET to auto-generate keys, and are instead specifying the keys using decryptionKey="{hex-key value}", then the way to get ASP.NET to use a different key for each application is to simply specify a different key in each application's Web.config.
The IIS config GUI allows you to create a Web.config with an explicit key together with the IsolateApps modifier, which is invalid, and in my opinion is a bug in the config GUI.
You can fix the issue by adding the following to the machineKey element (compatibilityMode="Framework20SP1") in the web.config See Link
This can be fixed by adding the machineKey line into your web.config, and specifying your keys as shown below (use your own key though of course, this one is easily guessable):
<configuration>
<system.web>
<machineKey decryptionKey="0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0" validationKey="0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF00123456789ABCDEF0123456789ABCDEF0123456789ABCDEF00123456789ABCDEF0123456789ABCD" />
</system.web>
</configuration>
Related
Our .Net Framework 4.8 web application suddenly began to generate the following build-time error on our team city build server:
error ASPCONFIG: Unable to open configSource file ‘sessionState.config’.
Our web.config references an external session state file:
<sessionState configSource="sessionState.config" />
The project is under active development, however no related changes have been recently made to the application. We initially thought it was a configuration issue on the build server, however we realised that we could replicate the same issue on our development machines if we "Published" the project and ticked the option to "merge all outputs into a single assembly". We published to a local file to replicate what was happening on our build server.
Modifying the Build Action of the sessionState.config file from None to Content removed the problem, but this had the effect of copying our sessionState.config file to the deployment package, which we didn't want.
We spent many hours trying to investigate this problem and finally decided to try uninstalling recent Microsoft Updates. This resolved it! I'm posting this here in the hope that it will save at least one other person the time we spent.
This specific October 13, 2020 update was the cause, however, it didn't come up for us when we searched https://support.microsoft.com/en-us/help/4578974/kb4578974-cumulative-update-for-net-framework
After you apply this October 13,
2020 Security and Quality Rollup for .NET Framework 4.8, some ASP.Net
applications fail during precompilation. The error message that you
receive will likely contain the words “Error ASPCONFIG.”
An invalid configuration state in either the "sessionState,"
"anonymouseIdentification," or "authentication/forms" sections of
"System.web" configuration. This might occur during build-and-publish
routines if configuration transformations leave the Web.config file in
an intermediate state for precompilation.
Note their spelling error in anonymousIdentification
The solution is to add this appSettings key to your web.config
<configuration>
<appSettings>
<add key="aspnet:DisableAppPathModifier" value="true" />
</appSettings>
</configuration>
The article notes that setting the value to either "true" or "false" will avoid the issue. It was recommended to set this value to "true" for sites that use cookies for the session state id.
We use cookies, so added this to our web.config with a true value, and it resolved the problem.
i came to know : Under the covers, the MVC AntiForgeryToken attribute uses the machinekey for encryption. If you don't specify a machinekey in the web.config , one is automatically generated for you by ASP.NET.
If the ASP.NET application is restarted (e.g. do an iisreset), the AntiForgeryToken within the browser cookie will still be encrypted with an old machine key, hence why it crashes with the above error.
My concern is
before write the machine key in web.config i like to know where i should look for the machine key to copy & paste in web.config. when we are testing in local pc then we can copy & paste the machine key in web.config but when we will host our site in godady or ORCSWEB in shared environment then those company may not give machine key of the pc where our site will be hosted. so i need to know how to handle this situation. thanks
EDIT
<configuration>
<system.web>
<machineKey
validationKey="21F090935F6E49C2C797F69BBAAD8402ABD2EE0B667A8B44EA7DD4374267A75D7AD972A119482D15A4127461DB1DC347C1A63AE5F1CCFAACFF1B72A7F0A281B"
decryptionKey="ABAA84D7EC4BB56D75D217CECFFB9628809BDB8BF91CFCD64568A145BE59719F"
validation="SHA1"
decryption="AES"
/>
how to get or generate validationKey & decryptionKey separately ? any idea?
If the ASP.NET application is restarted (e.g. do an iisreset), the
AntiForgeryToken within the browser cookie will still be encrypted
with an old machine key???
I don't think machine key changes with iisreset.
You can generate machine key (validation and decryption key) yourself and specify it in web.config. The same key will be used in all cases where encryption is performed e.g. Auth tickets, AF Token.
A good introduction link.
UPDATE:
How to generate machine key?
There are various way, this msdn blog suggest using IIS which looks more secure to me as Microsoft tool being used. However, it seems this feature is only supported until IIS 7. I don't find it on my box IIS 8.5. I checked on IIS 7.5 and its not present there either. However, I found it in IIS 6.1 on a coworker box.
Second option is to use custom key generators
a. Machine Key Generator (online)
b. ASP.NET machineKey Generator (tool you can modify)
Is it possible to do away with the web.config file in the Views folders of an MVC application?
Due to a bug in the encryption feature of Web Deploy I need to just use a single web.config file in the root of the site.
see: MSDeploy automatic encryption of connection strings, key not found in dictionary
I have an ASP.NET MVC 4 project which is to be deployed to Azure for production, in production I use a SQL Azure database. My problem is that I want to connect to the SQL Azure database only in the production deployment, and not when developing, and that the SQL Azure connection string should be encrypted.
Now, I can solve the first requirement through a Web.config transform, so that the database connection string gets substituted upon deployment to Azure. However, I don't see how to combine this with connection string encryption? How can one both encrypt the SQL Azure connection string and substitute it for the development connection string when deploying? Best practices for this scenario would be most welcome :)
I think a good solution here is to type the production <connectionStrings> section into Web.config and encrypt it, and then move the encrypted <connectionStrings> section into the transform file (e.g. Web.Release.config) and annotate it so that it replaces the whole <connectionStrings> section upon transformation. This accomplishes the goal of deploying Web.config with production connection strings that are also encrypted.
I've followed the guide in "Securing Your Connection String in Windows Azure", parts 1, 2, 3 and 4 to understand how to encrypt Web.config. I suggest that for a full reference, others do the same. I will outline the main steps I've performed to solve my scenario.
After updating the <connectionStrings> section in Web.config with production settings, I installed the Pkcs12 Protected Configuration Provider and ran aspnet_regiis.exe to encrypt the section (in a Visual Studio command prompt, situated in the project directory):
aspnet_regiis -pef "connectionStrings" "." -prov "CustomProvider"
I also added a definition of CustomProvider to Web.config:
<configProtectedData>
<providers>
<add name="CustomProvider" thumbprint="<your thumbprint here>"
type="Pkcs12ProtectedConfigurationProvider.Pkcs12ProtectedConfigurationProvider, PKCS12ProtectedConfigurationProvider, Version=1.0.0.0, Culture=neutral, PublicKeyToken=34da007ac91f901d"/>
</providers>
</configProtectedData>
Afterwards I moved the encrypted <connectionStrings> section into Web.Release.config (which is used to transform Web.config upon deployment to Azure), and annotated the section so that it replaces the corresponding section in Web.config:
connectionStrings configProtectionProvider="CustomProvider" xdt:Transform="Replace">
...
</connectionStrings>
Finally I restored the development <connectionStrings> section in Web.config. I have tested this solution and found that the deployed Web.config contains the encrypted <connectionStrings> section, just as I was after.
You would encrypt the section within the web.config file.
See MSDN about how to encrypt sections of your web.config file.
http://msdn.microsoft.com/en-us/library/zhhddkxy.aspx
What I would setup in your case is a POST build event that runs that command line option, conditionally only for that specific build configuration.
For example:
if $(ConfigurationName) == Release_Production {path-to-.net-framework}\aspnet_regiis\Aspnet_regiis.exe {your options here}
Remember, post build events are just simple DOS commands. You can even use () to scope several commands. The if only works on that 1 line unless you scope it. Standard command-line restrictions. Comment back here if you have problems setting it up, but post ur command line.
After publishing a new build of my ASP.NET MVC web application, I often see this exception thrown when browsing to the site:
System.Web.Mvc.HttpAntiForgeryException: A required anti-forgery token was not supplied or was invalid. ---> System.Web.HttpException: Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster. ---> System.Web.UI.ViewStateException: Invalid viewstate.
This exception will continue to occur on each page I visit in my web application until I close out of Firefox. After reopening Firefox, the site works perfectly. Any idea what's going on?
Additional notes:
I am not using any ASP.NET web controls (there are no instances of runat="server" in my application)
If I take out the <%= Html.AntiForgeryToken %> from my pages, this problem seems to go away
Under the covers, the MVC AntiForgeryToken attribute uses the machinekey for encryption. If you don't specify a machinekey in the web.config (see here), one is automatically generated for you by ASP.NET (full description).
If the ASP.NET application is restarted (e.g. do an iisreset), the AntiForgeryToken within the browser cookie will still be encrypted with an old machine key, hence why it crashes with the above error.
So you should always specify a machinekey in your web.config when using MVC, e.g.
<configuration>
<system.web>
<machineKey
validationKey="21F090935F6E49C2C797F69BBAAD8402ABD2EE0B667A8B44EA7DD4374267A75D7AD972A119482D15A4127461DB1DC347C1A63AE5F1CCFAACFF1B72A7F0A281B"
decryptionKey="ABAA84D7EC4BB56D75D217CECFFB9628809BDB8BF91CFCD64568A145BE59719F"
validation="SHA1"
decryption="AES"
/>
...
If you're on a server farm, make sure your machine key on every server is the same.
I too had this problem, and expecting the users to clear their cache, cookies or refreshing the page isn't acceptable.
Adding a machinekey to web.config is will fix this. I used this tool to quickly generate a key so I don't see these errors in development and then I generate one properly when the site goes into production.
http://aspnetresources.com/tools/machineKey