We have a few sections of our application that are using AJAX.NET 5.7.25.1. Our server administrators have enabled FIPS and we are running into the following error:
This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms.
Call stack:
at System.Security.Cryptography.MD5CryptoServiceProvider..ctor()
at MS.Utilities.MD5Helper.GetHash(Byte[] data)
at Ajax.AjaxRequestProcessor.Run()
at Ajax.AjaxHandler.ProcessRequest(HttpContext context)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
Are the newer versions of the AJAX.NET libraries FIPS compliant?
The fastest way to done here may be to just modify the AJAX.Net pro source directly to remove the offending call that uses the MD5 algorithm. Go get the source for the version of AJax.NET pro you're using from Codeplex. In AjaxPro/Utilities/MD5Helper.cs:
Replace the line...
MD5 md5 = new MD5CryptoServiceProvider();
with the line...
SHA1 md5 = new SHA1CryptoServiceProvider();
That should fix it. SHA1 is FIPS compliant per this page
In this case... the only API that is being used is the ComputeHash() method, which both providers implement so...
Just by switching the crypto providers you should be able to compile and use the code without any other changes and without any annoying FIPS policy violation flags.
Use of ANY MD5 hash algorithm in .NET is considered NON-FIPS compliant so this will always give that error. I'm not sure if the AjaxRequestProcessor might be doing with MD5, it might be some kind of viewstate operation. Altering your viewstate encryption algorithm to use 3DES instead of MD5 may help.
Try adding this key in your system.web section of the web.config file:
<machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" validation="3DES" decryption="3DES"/>
Full article about the workaround HERE.
Also, just having debug="true" in your webconfig can cause this error to crop up as .NET uses MD5 for some debugging operations. Is debug="false" in your web.config?
<system.web>
<compilation debug="false">
</system.web>
Related
I need to encrypt a block of data using AES-128-ECB and would like to do so with libsodium and Ruby. I have prototyped a solution in Ruby using OpenSSL APIs as shown below:
aes = OpenSSL::Cipher::Cipher.new("AES-128-ECB")
aes.encrypt
aes.key = key
aes.update(data) + aes.final
This works, but I need other features from libsodium, so I would like to use it instead and get rid of my dependency on OpenSSL. Unfortunately, I don't see any APIs for ECB mode. I am also using the ruby wrapper RbNaCl, but I don't even see any way to do this using the base libsodium APIs. I do see ones for AES-128-CTR.
Is it possible to encrypt AES-128-ECB with libsodium?
libsodium intentionally doesn't support the ECB mode.
In this mode, the same block encrypted twice produces the same ciphertext twice.
A classic illustration of why this is terrible from a security perspective is the ECB penguin.
Instead of providing many primitives, modes and parameters to choose from, with many combinations actually being insecure, libsodium provides a cherry-picked set of secure constructions.
AES-ECB is not one of them, and will never be for the reasons stated above.
You really should switch to a different construction.
I integrated active directory with sitecore and it works perfect, now i am trying to write patches for the config changes. Sections <membership defaultProvider="sitecore" hashAlgorithmType="SHA1"> and <roleManager defaultProvider="sitecore" enabled="true"> are changed for connection setting to AD. When i try to write config patch for this section, this section is not built at run time. But the domains section works, i mean the patch i created for this section works and writes to web.config at runtime. I observed a difference here Domains section is under <Sitecore>, <membership> and <roleManager > are in <system.web> section. Is this the reason that these are not included in web.config? can we write patches for those sections only under <sitecore>?
Any ideas are appreciated.
Thanks.
You can only patch elements within the /configuration/sitecore element.
Refer this post:
http://www.sitecore.net/Learn/Blogs/Technical-Blogs/John-West-Sitecore-Blog/Posts/2011/05/All-About-Web-config-Include-Files-with-the-Sitecore-ASPNET-CMS.aspx
I think you have to use config transforms as mentioned by leandro.
I assumming you are using Visual Studio ¿? You must specify in what are you working.
If so, you need create a transform file for the build configuration that you need, for example, one config for every environment or publish type.
Try a look at this:
http://msdn.microsoft.com/en-us/library/vstudio/dd465318%28v=vs.100%29.aspx
On my site every text is served as UTF-8.
Since nowadays every browser supports unicode characters, I would like to use them as-is.
The asp.net framework is very helpful by replacing any unicode with a Numeric Character Reference, like á. For reference check: http://en.wikipedia.org/wiki/Unicode_and_HTML#HTML_document_characters
Sure, this way the webpage renders correctly in the oldest netscape possible, but for example the google analytics ecommerce module has some trouble understanding these specially coded characters.
Is there a way to globally disable the Numeric Character Reference encoding?
For example I want to write in razor:
<span class="title">#ViewBag.Title</span>
I would want this to show on the output:
<span class="title">Számítástechnika</span>
Not this:
<span class="title">Számítástechnika</span>
I'm not trying to disable the html encoding, so Html.Raw is not a solution, as for example I'm not able to ensure that the #ViewBag.Title will not content something like this:
<span class="title"><script>alert('injected hahahah');</script></span>
So I'm content with the automatic encoding of special html characters. That is not what I want to disable.
I wouldn't want to restructure all the code, and I thought that there should be a "global switch" to disable this kind of behavior in using string parameters in razor. Is there a way to do this?
Also can I explicitly forbid the numeric character references, for example with something like new MvcHtmlString(myString, some parameters) ?
I'm afraid that you cannot turn this encoding feature off. This "nice" feature is provided by the WebUtility.HtmlEncode and you cannot influence the encoding.
However with starting .net 4.0 you can customize the encoding behavior, with creating a class that inherits from the HttpEncoder and configure it in the web.cofig HttpRuntimeSection.EncoderType. But you need to implement your own custom encoding logic.
Luckily .net 4.5 ships with a new HttpEncoder which encodes the bad stuff (like <script>) however handles the Unicode characters correctly called AntiXssEncoder
So you just need to add this in your web.config:
<system.web>
<httpRuntime encoderType="System.Web.Security.AntiXss.AntiXssEncoder,
System.Web, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a"/>
</system.web>
If you are not yet on .net 4.5 you can implement your AntiXssEncoder with the help of
Microsoft Web Protection Library
Here is an article how to set it up: Using AntiXss As The Default Encoder For ASP.NET (although it might be outdated)
You can also use the #Html.Raw method of mvc.This is useful where you don't want to do it at global level sometimes on already built project.
#Html.Raw(#ViewBag.Title)
For .Net Core web application you can configure default encoding behaviour in your ConfigureServices method:
public void ConfigureServices(IServiceCollection services)
{
services.Configure<WebEncoderOptions>(options =>
{
options.TextEncoderSettings = new TextEncoderSettings(UnicodeRanges.All);
});
}
This will render non-encoded unicode characters on the html page.
Source https://github.com/aspnet/HttpAbstractions/issues/315
I am fairly green at ASP.NET coding, even though I have done very basic tasks for a while.
Recently, I have been assigned our company's website, so I am learning more of the details.
I downloaded the project from Source Safe, and I am making changes in the code.
A co-worker and I were looking at the Web.config file, and noticed this under the <configuration> section:
<appSettings>
<add key="HR_EMAIL" value="myEmailAddress#work.com"/>
<add key="APP_MODE" value="TEST"/>
<!-- PROD is the production value for ssl pages -->
<add key="HR_EMAIL_SITE_A" value="myEmailAddress#work.com"/>
<add key="HR_EMAIL_SITE_B" value="myEmailAddress#work.com"/>
</appSettings>
where myEmailAddress#work.com used to list my actual email address.
My co-worker said, "Oh, you've changed it and removed my email address."
Uh, no I have not! I could care less if these people email me!
I'm guessing something configured on my local machine (maybe in machine.config) went in and updated these values whenever I rebuilt the project.
I have used a walkthrough recently published by Microsoft (Walkthrough: Creating a Web Site with Membership and User Login), but it was in a different project.
What changed these values? Surely I did not do this in my sleep!
Chances are that someone committed these values to source control.
You got the latest value - possibly your workmate has not updated this file in a while.
Take a look at the file history in Source Safe to see what happened with this value.
section, as the name suggests, is specific to application to store custom settings. Before ASP .NET 2, this section was used to store things like connection string used by the web application.
In you case, I am guessing that, you have an admin site/system that is writing out your email adress to app.config.
I have seen another scenario, where setting will be updated by the build/release script.
You'll likely find that due to differences in enviroments, in most cases you don't deploy a web.config from enviroment to enviroment. You wouldn't want test settings, like connection strings, emails, etc getting propigated to production.
When you're likely finiding is the config in VSS is a local testing copy and the production copy has different values.
I have created a self generated certificate to sign a DLL. When I load this DLL into my C++ application I am able to validate if the code signing certificate is valid or not by using the WinVerifyTrust api.
But I am not able to find a way to detect that the DLL has been signed by one of my certificates. Even by using the CryptQueryObject api I do not find any useful information.
Does anyone have a idea on how to do this? Or is it event possible?
Thank you
CryptVerifyCertificateSignature isn't what you want?
If you sign a certificate using your private key, it can only be verified with your public key. That's how public-key cryptography works. If you can use a public key to verify the signature, then you know that the corresponding private key must have been used to sign it.
In case you need a version that also works on earlier versions of Windows than the one Bill Zeller showed you, you can use the following:
Use CryptQueryObject with CERT_QUERY_OBJECT_FILE
Use CryptMsgGetParam with CMSG_SIGNER_CERT_INFO_PARAM on the HCRYPTMSG you received from the previous call
Now use CertCompareIntegerBlob to compare your known (certificate) serial number (or numbers, in a loop) against the one in the file
If any of the known serial numbers matches, you're done. If all comparisons fail, it's not your cert.
Note: when looking at the serial number of the certificate in the file properties dialog, the bytes shown there appear in the reverse order when compared with the contents of the PCERT_INFO (CERT_INFO::SerialNumber) you get from the CryptMsgGetParam. So make sure that you store your own serial numbers reversed or reverse them before comparison.
Also note: you'll still need to have the certificate installed as trusted, in order for WinVerifyTrust (not mentioned above) to consider the code signature trusted at all. I just described the part about how to find out it's your own certificate that was used.