Home »

Secure Your Contact Page

2. July 2010 by MJG 2 Comments

One of our clients uses McAfee Secure to monitor their website for vulnerabilities and just recently the Contact Us page on their ASPDotNetStorefront site has started being flagged as having a high severity when it comes to security vulnerabilities. Here is what McAfee has to say about this alleged vulnerability:

The remote host appears to allow sensitive form submission over unencrypted (HTTP) connections. This means that a user's personal information is sent over the internet in clear text. An attacker may be able to uncover sensitive information such as login names and passwords by sniffing network traffic.
All web pages that transmit Card Holder Data or Personally Identifiable Information (PII).
Examples:
- Users and/or Administrators login to the web site.
- Registration forms such as user signup pages.
- Updating User and/or Administrators profile pages.
- Updating User and/or Administrators shipping information pages.
- Forgot password reset page.
- Company "Contact Us" pages.

In order to work around this situation, we’ve added the following to the bottom of the driver.aspx.cs file; it was added to the bottom because we need to ensure that the topic1 class has been populated. As an alternative one could compare against the querystring (since ASPDNSF does URL mapping you’ll find the topic name in the querystring as Topic=). Here is our solution:

if (Topic1.TopicName.ToLower() == "contact")
                RequireSecurePage();

 

Anyone else have any ideas on how better to address this situation? Has anyone ever had a client complain that their customers didn’t want to use the contact us form because it wasn’t secured via SSL? I mean the only information that is being exposed here is an email address and their name really. If so, let us all know about it and comment using the form below.

Comments (2) -

steve
United States steve said:

We had to do the same type of thing to comply with whatever security company we contracted to certify us with the credit cards. In fact, they used McAfee to scan our site. Most of it was pretty meaningless but I patched everything up because the certification required 100% compliance. At the very least, it was a good exercise.

As far as customer preferences go, remember that most of them still don't know what a browser is. They're happy to assume that their information is secure and have no idea to look for that padlock and aren't sure if that would be comprehensive security anyway.

On a related note, the McAfee product seems to make a decent de-facto production monitoring device. One of our developers dropped phpMyAdmin a public web server to help him troubleshoot a facebook app he was writing. It wasn't needed in the regular use of the application, but was left there after development was complete. I wasn't even aware of its existence until McAfee jumped all over that like white on rice, finding three different types of vulnerabilities in there.

mjg
United States mjg said:

Good to hear from you Steve. How is life? Still running?

Add comment




  Country flag
biuquote
  • Comment
  • Preview
Loading