Click here to Skip to main content
13,145,774 members (72,664 online)
Click here to Skip to main content
Add your own
alternative version


28 bookmarked
Posted 4 Mar 2009

How To Make Your Website More (McAfee) Secure

, 4 Mar 2009
Rate this:
Please Sign up or sign in to vote.
Learn how to make your website more secure so that McAfee recognizes it 100% mcAfee Secured and PCI Compliant


Recently one of my clients requested, after a critical attack on the server where an application was running, to make sure that the application is secured in all perspectives. We chose McAfee to ensure that the website is 100% hacker proof. After a thorough Application Scan, Network Scan, and PCI Scan, McAfee found out several vulnerabilities in the Website, and I thought some of them exist in most of the websites we make. So here is a brief list and solutions we have found out to make a website 100% McAfee Secured and PCI Compliant.

Before we delve into the technical details, I want to clarify what this article covers and what it does not, better not to create any false expectations. This article is solely based on my experience while solving the vulnerabilities, and I have presented them likewise. As several of the fixes require tweaks in registry, make sure to back the registry up, and change anything at your own risk.

Following are the most important vulnerabilities that were reported by McAfee:

Vulnerability 1

Vulnerability Name:  Microsoft .NET Custom Errors Not Set


This is when the custom error page is not set for an application. We generally use the web.config to specify the Error Page. But McAfee requires it to be done both ways.


In order to fix this vulnerability the error pages must be set from the IIS. The steps are as follows:

  • Go to IIS Manager
  • Right click on the project name that has to be McAfee Secured
  • Click Properties
  • In the Properties Box, click on the “Custom Errors” tab and the following window appears:


  • Highlight any one of the error types and click on edit properties and a small window appears where the custom error page can be specified.


  • Click on OK button in both this and its parent window.
  • If even one error page is specified for any one error, McAfee considers this a vulnerability no more.

Vulnerability 2

Vulnerability Name: Allow All Policy in crossdomain.xml


If a website uses several flash videos and content and other websites use them in their websites, the crossdomain.xml comes into play. This XML file sets the policy about who can use the content in their websites in terms of domain name. It has a key called –

<allow-access-from domain="*"/>

According to McAfee, this poses a serious threat of hack attack to the website.


It is very confusing how McAfee scans the file, because even if the file is removed from the root (wwwroot), and a copy of the file still exists in any place of the whole server, McAfee still finds that and gives an alert. The best solution is to Edit each and every occurrence of that file in the whole server and remove all stars (*) and give specific domain names from which the videos will be accessed. If not required, it is best to completely delete the file.
So the edited file will look like: 

<allow-access-from domain="*"/>

(* denotes anything that prepends the domain name e.g. in also all protocols: HTTP or HTTPS)

Vulnerability 3

Vulnerability Name:  Using SSL v2 in Secure Communications 


The remote service appears to encrypt traffic using SSL protocol version 2.

Netscape Communications Corporation introduced SSL 2.0 with the launch of Netscape Navigator 1.0 in 1994 and it contains several well-known weaknesses. For example, SSLv2 doesn't provide any protection against man-in-the-middle attacks during the handshake, and uses the same cryptographic keys for message authentication and for encryption.

In Internet Explorer 7, the default HTTPS protocol settings are changed to disable the weaker SSLv2 protocol and to enable the stronger TLSv1 protocol. By default, Internet Explorer 7 users will only negotiate HTTPS connections using SSLv3 or TLSv1. Mozilla Firefox is expected to drop support for SSLv2 in its upcoming versions.

As almost all modern browsers support SSLv3, disabling support for the weaker SSL method should have minimal impact. The following browsers support SSLv3:

  • Internet Explorer 5.5 or higher (PC)
  • Internet Explorer 5.0 or higher (Mac)
  • Netscape 2.0 (Domestic) or higher (PC/Mac)
  • Firefox 0.8 or higher (PC/Mac/Linux)
  • Mozilla 1.7 or higher (PC/Mac/Linux)
  • Camino 0.8 or higher (Mac)
  • Safari 1.0 or higher (Mac)
  • Opera 1.7 or higher (PC/Mac)
  • Omniweb 3.0 or higher (Mac)
  • Konqueror 2.0 or higher (Linux)

According to, an Assessor's update report, " is imperative that an ASV identify the use of SSL 2.0 to transmit cardholder data as a failure."


SSL related protocols can run on other service ports as well. Typical ports include: 465, 993, 995, 2078, 2083, 2087, 2096, 8443, etc. Each application will have its own configuration options to handle SSL protocols.
To solve this problem, one needs to open Registry Editor.

  • Click Start, click Run, type regedt32 or type regedit, and then click OK.
  • In Registry Editor, locate the following registry key:
    				\SCHANNEL\Protocols\SSL 2.0\Server


  • On the Edit menu, click Add Value.
  • In the Data Type list, click DWORD.


  • In the Value Name box, type Enabled, and then click OK. (The value will be automatically set to 0 – Disabled )


  • Next Restart the system and the SSL V2 will be disabled for good.

Vulnerability 4

Vulnerability Name:  Weak Supported SSL Ciphers Suites


The remote host supports the use of SSL ciphers that offer either weak encryption or no encryption at all. This vulnerability is valid for all SSL/TLS sessions that are passing sensitive information.
PCI defines strong cryptography, for secret key based systems, as anything above 80 bit encryption.


The solution to this is very simple but requires registry tweak again. Following are the steps:

  • Click Start, click Run, type regedt32 or type regedit, and then click OK.
  • In Registry Editor, locate the following registry key:
  • Under the Cipher key, there are several Ciphers.
  • Locate the ciphers which have encryption less than 128 bit.
  • Create DWORD values named Enabled and Value 0 for each of them, just as the previous case.
  • For convenience, I have marked them with red arrows in the picture above.
  • System Restart is NOT required for this.

Now the server is secured.
The above mentioned security issues are the major ones that most of the systems have. However other than this, there may be some easy and minor vulnerabilities like:

  • Using robots.txt in the pages. (Generally inserted by Web Marketing team to track user hit).
  • Directory Scanner: Common directories are revealed. This can be resolved by URL rewriting and setting “Directory Browsing” off.

Note: For the above vulnerabilities, minor registry tweaks will be necessary. So it is strongly recommended to back up the registry before doing anything. By any chance if something gets messed up, just delete the SCHANNEL key and restart the machine, the key will be auto-generated.


  • 4th March, 2009: Initial post


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

No Biography provided

You may also be interested in...


Comments and Discussions

GeneralVery interesting Pin
cwp4210-Mar-09 21:48
membercwp4210-Mar-09 21:48 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web04 | 2.8.170915.1 | Last Updated 4 Mar 2009
Article Copyright 2009 by Anindya Sen Gupta
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid