OpenSSL: The remote certificate is invalid according to the validation procedure

16. August 2010
Comments (0)

I was playing around, trying to enable self signed SSL certificates in our development environment to simulate the production SSL setup and encountered the following error, after creating the certificates using SelfSSL tool

 

[AuthenticationException: The remote certificate is invalid
 according to the validation procedure.]


 

We have a application server that hosts our BL webservices. I installed a certificate using the above mentioned tool. Since, the .NET code can not validate this self-signed certificate it throws the above error.

This is easy to fix. All you need to do is install the CA root certificate on the web server. I used the MMC certificates tool to do that. You can use the following steps to install the CA root certificate

First step is to save the problematic certificate onto hard disk. Open IE and type the url of the app server or whatever server you are trying to access through the code. Click on Continue, if it shows a warning message, saying the certificate is not trusted and blah.. blah.. Then click on the Lock icon in the IE address bar. Then, you can export the certificate as shown below, by clicking on Copy to File

 

  1. Open MMC using mmc command.

  2. Click on File menu and click on Add/Remove snapin.

  3. Now in the opened dailog, click Add and select Certificates
  4. Make sure you select "Computer Account" in the certificates Snap-in dialog box
  5. Select the Local Computer
  6. Then import the saved certificates onto the "Trusted Root Certification Authorities"  node. See the screenshot below

    7. After this browse to the saved certificate and import the certificate. Thats it. Your code should be able to validate this certificate after this step

The most common Security attacks in web applications

11. December 2009
Comments (0)

Recently I was reading a whitepaper from Microsoft about how the Windows Live team used ASP.NET MVC to build its Windows Live applications.

 

Here is a snippet from that article which explains various types of security attacks and their recommendations about how to deal with them or preventing the common mistakes developers make while designing the applications which make their apps more vulnerable

Possible attack

Mitigations

Cross-Site Scripting

Cross-site scripting, also known as XSS, is a specialized version of an HTML injection attack. XSS vulnerability enables an attacker to execute script in the user's browser. By running with the identity of the user on the Web site, this script can hijack the user's session, attempt to deface Web sites, insert hostile content, conduct phishing attacks, or even take control of the user's browser.

·   Encode output by using the Anti-XSS library. This library is available from the CodePlex Web site at http://www.codeplex.com/AntiXSS.

·   Perform input validation by using the ValidateRequest attribute.

·   In addition, the SDL also recommends the following two defense-in-depth practices:

1.   Do not use the JavaScript eval() function of any similar functions that can evaluate and execute a string as though it was script code.

2.   Do not set the domain property of a document to the top-level domain of the Web site.

Open Redirects

An open redirect, also known as a cross-site redirect or XSR, enables an attacker to redirect a user request to an arbitrary site through a URL on your Web site. Attackers could use this for phishing attacks, spam, and serving malicious software (also called malware).

·   Verify all redirections against a list of allowed URLs.

Cross-Site Request Forgery

A cross-site request forgery attack, or XSRF, forces the browser for a logged-on user to send a request to a vulnerable Web application. The vulnerable Web application performs the request with the identity of the user.

·   Set the ViewStateUserKey property on pages accessed by an authenticated user.

·   Alternatively, use a custom-built dynamic canary library (described below).

JS/JSON Hijacking

JavaScript (JS) or JavaScript object notation (JSON) hijacking enables an attacker to read a JavaScript or JSON response from another site. Web sites typically return personally identifiable information (PII) about users in JSON responses, so this attack could allow an attacker to steal users’ PII just by visiting the attacker’s Web site. When the vulnerable Web site receives the request, it runs the script with the identity of the user.

·   Use a custom-built dynamic canary library.

·   As a defense-in-depth option, consider returning PII in JSON responses only to POST requests.

Note: The option of using ViewStateUserKey or a custom-built dynamic canary library warrants a little more explanation. Some teams at Microsoft do not use the ViewState property of a page for several reasons. This means that the corresponding pages cannot set the ViewStateUserKey property either. Consequently, these teams have built a library with application-level logic that incorporates anti-forgery validation tokens, referred to as canaries. A canary is an unpredictable, unguessable string of characters that the Windows Live Web applications can validate. A canary has a short period of time during which it is valid. A method in the library generates a canary, inserts the canary into the page, and then verifies that subsequent HTTP requests include the same canary. This challenge response sequence is similar to the ViewStateUserKey functionality.

 

Another snippet from the whitepaper

" Regardless of the application being developed, a fundamental tenet of SDL (Security Development lifecycle)  is the principle of "security by default." This means that software should be designed and implemented in such a way that a user or developer has to explicitly enable functionality that could possibly increase the attack surface, rather than disable functionality to make the application more secure."

 

This whitepaper has some excellent ideas about how they used various MVC Actions Filters to create a framework based on the above principle

 

 

 

,