How to secure contact us page with SSL?

I've been testing this out in a few other carts. Haven't yet found one that has SSL on the contact page. Is the whole of the e-commerce world operating illegally in the Netherlands.

And what about blogs and other sites that generally don't have need of SSL. Are they all illegal too if they have a contact page?

What about comments on blogs. They typically have the same structure the Zen Cart contact us page: name, email, big text box. Are you suggesting that blogs with comments enabled are forbidden unless operating under SSL?

By a certifying authority which stand under supervision of the 'Raad voor Accreditatie' which has been established by the dutch ministry of economic affairs in 1981. link

To get this certification one of the rules is:

Indien een consument online persoonsgegevens beschikbaar stelt, dient het bedrijf afdoende maatregelen te
nemen voor een veilige overdracht van die gegevens. Een dergelijke beveiliging wordt bereikt door het
gebruik van SSL encryptieprotocollen of vergelijkbare encryptieprotocollen.

Translation (as good as it gets at this time of morning):

If a consumer has to make his personal data available online, the company has to take appropriate measures for a safe transmission of these data. Such measure of safety will be reached by using SSL encryption or similar encryption protocols.

I've seen several Magento shops that have it... also on a lot (most) off dutch 'rent a cart' have it (optionally).

Here is a blogpost of a leading Dutch ICT attorney.
I'm sorry it is in Dutch, this is what Google translate makes of it.

LOL. The lawyer that you're quoting has a link to his contact form on that very page. And it's not protected by SSL.

His defence would most likely be that the name and address are not stored in a database (he states that clearly). The same defence would apply to Zen Cart which doesn't store data from the contact page, but instead emails it to the store owner, which is most likely what his site is doing too.

Magento Community Edition was one of the carts that I tested. It doesn't have SSL on the contact page. It's possible that the paid editions may store the data and so may operate differently. I haven't tested those.

According to that translation: (coloring and emphasis is mine)

Security Requirements

Companies that process personal data, should take measures (technical and managerial) to prevent unauthorized access to get people here. In many cases, it is necessary to protect such data, such as passwords and encryption to be applied to the database. For transmission of data (such as filling out forms) often use secure Internet connections using SSL as recommended.

Recommended, not required. All the other forms, i.e. Create Account and checkout do use SSL when available.

Since the Contact Us is not required information, the customer is voluntarily sending you the correspondence, it is our position that SSL is not required.

@kuroi

His defense is that he is blogging as a private person not as a company.

@Kim

I took the liberty to email that same lawyer and here is his response:

Beste René,

De Wet bescherming persoonsgegevens eist 'adequate' beveiligingsmaatregelen tegen misbruik en diefstal van persoonlijke informatie. Er zijn geen harde normen, dus iedereen mag zelf verzinnen hoe in zijn situatie aan die eis voldaan is.

SSL lijkt me een voldoende manier voor bestel- en contactformulieren, dus als je dat doet dan zit je m.i. goed. Wel ook je database goed beveiligen natuurlijk. Maar heb je een andere manier die ook veilig is, of vind jij dat e-mailadressen in een niet-SSL contactformulier veilig genoeg zijn, dan is er geen rechtsregel die je tegenhoudt.

...

Bij bestellingen en betalingen geldt vaak dat de payment provider SSL eist (of zelf al hanteert), dat is dan een contractuele eis waar je aan moet voldoen. Ook keurmerk Thuiswinkel.org stelt eisen waar je SSL moet hebben, en wie die niet wil opvolgen, mag hun keurmerk niet voeren.

Je mag dit publiceren op het forum.

Met vriendelijke groeten,

Arnoud Engelfriet

Tanslation:

Dear René (that's me obviously),

The Data Protection Act requires "adequate" security measures against theft and abuse of personal information. There are no strict rules, so everyone can take there own measures to how that requirement is met.

SSL seems an adequate method for ordering and contact forms, so if you do, then you meet the requirements, in my opinion. Also protect your database of course. But if you have another way to be safe, or you think that e-mail addresses in a non-SSL contact form are safe enough, then there is no rule that stops you.

...

For orders and payments, often the payment provider requires SSL (or already uses), which is a contractual requirement that you have to meet. Also mark Thuiswinkel.org makes demands that you must have SSL, and who will not succeed, can not carry their quality mark.

You may publish this on the forum.

Sincerely,

Arnoud Engelfriet

Kim:

All the other forms, i.e. Create Account and checkout do use SSL when available.Just to clarify slightly ...

In Zen Cart, forms that involve the input and subsequent storage of personal, financial or security information, such as create account, the checkout process and login are protected by SSL.

forms that act as a simply front end to email, and from which no data is stored, such as contact-us and tell-a-friend don't use SSL.

We believe this to be normal practice for web applications, PA-DSS-compliant and consistent with how data protection legislation has been interpreted and applied across Europe in the decade plus since the European Directive that led to to specific legislation in individual countries was issued.

I actually replied to this because DrByte asked what the reason would be to secure the contact form.

At that moment I was under the impression that Dutch Law required SSL for all contact us forms (since there is a ruling that an email address is personal information) and because, to get certain quality marks you have to have the contact us secured by SSL.

From the answer of Arnoud Engelfried i now understand that is in fact not a legal requirement if you only ask for name + email address. But only if you want the dutch quality mark from Thuiswinkel.org (Thuiswinkel is dutch for homeshopping).

Therefor i thank Kuroi for post #3 and will write a description in the dutch ZC forum or a blogpost how to make your contact form SSL secured for those Zen Carts that want or need it.

Showing once again you are never to old to learn... :)

Re:

JC.M:

Is it possible to secure the contact us page or any certain page with SSL?
kuroi:

In this case you would need to find all instances of zen_href_link(FILENAME_CONTACT_US) and change them to zen_href_link(FILENAME_CONTACT_US, '', 'SSL')

I have 'tpl_modules_shipping_estimator.php' currently hide the user name and address (if logged in) as it's included in the shopping cart page ~ which is not always SSL.

From kuroi #3 i've found varitions for the cart page

zen_href_link(FILENAME_SHOPPING_CART)
zen_href_link(FILENAME_SHOPPING_CART, ' ', 'NONSSL')
zen_href_link(FILENAME_SHOPPING_CART, 'action=remove_product&product_id=' . $product['id'])
zen_href_link(FILENAME_SHOPPING_CART, 'action=update_product', $request_type)

to force the cart page to use SSL are the following revisions correct?

zen_href_link(FILENAME_SHOPPING_CART, ' ', 'SSL')
zen_href_link(FILENAME_SHOPPING_CART, ' ', 'SSL')
zen_href_link(FILENAME_SHOPPING_CART, 'action=remove_product&product_id=' . $product['id'], 'SSL')
zen_href_link(FILENAME_SHOPPING_CART, 'action=update_product', $request_type, 'SSL')

I am having a problem with McAfee PCI scan citing my contact us page is not secure. I requested a false positive (no sensitive information passed from this form) and they rejected it with "name and email are still sensitive information and must be ssl" (well, I used quotes by that is not word-for-word:) Anyway, I followed #3 above and made all my links SSL. I had McAfee rescan, and got the same result. I noticed that if you simply remove the "s" from the URL, you get the non-SSL page (which I assume that is why it is still failing). I also did this to my login and checkout page with the same result. It appears we can "guide" a user to SSL, but not "force" it.

Is there a way to FORCE the ssl on a page? I've searched the net and many speak against putting it in an htaccess file. I tried a simple 301 rewrite for that particular page and didn't work anyway (not experienced by the way!). Any help would be appreciated!

tstamplis:

I noticed that if you simply remove the "s" from the URL, you get the non-SSL page (which I assume that is why it is still failing). I also did this to my login and checkout page with the same result. It appears we can "guide" a user to SSL, but not "force" it.
Um ... step back a moment.

On the checkout or contact-us screens, it doesn't matter if you arrive at the page in http mode, because all the data entered is only transmitted over https anyway.

This is a basic misunderstanding that many people have:
a) the URL displayed in the browser is the address used to DISPLAY the page
b) the URL in the <form action="URL HERE"> tag inside the page's HTML is what is used to SUBMIT the page.

And Zen Cart always puts an HTTPS URL into the <form action> when the page is set up to be protected by SSL, such as checkout.

So, fudging the URL used to ACCESS or DISPLAY the page is moot. If THAT is what the PCI Scanner is looking at, then it's amateurish and ought not to be in the business of scanning.

So ... if your issue is that the scanner is absolutely bent on the idea of an email address being ultra-sensitive information, then change the zen_draw_form(FILENAME_CONTACT_US) reference in your template and set its 3rd parameter to 'SSL' instead of 'NONSSL' and this whole problem goes away.

But, as I said in my first post in this long thread, the information collected is immediately sent off to the storeowner VIA EMAIL ... and we all know that EMAIL is the LEAST SECURE communication method on the internet. So ... protecting the collection of that info by SSL is entirely moot. Especially since THE PERSON GIVING THEIR EMAIL ADDRESS IS EXPECTING YOU TO EMAIL THEM AT SOME POINT. They WANT to be contacted. And they've opted to receive that contact via email. So clearly they don't object to the use of their information being shared in an email. So ... it goes back to the basic question: why is this considered "ultra sensitive" in the first place?
Anyway, rant over.

I suspect that your scanner is not doing its job correctly.

DrByte:

So ... if your issue is that the scanner is absolutely bent on the idea of an email address being ultra-sensitive information, then change the zen_draw_form(FILENAME_CONTACT_US) reference in your template and set its 3rd parameter to 'SSL' instead of 'NONSSL' and this whole problem goes away.

Thank you for your reply, passionate as it is:smile: If I had an ounce of the knowledge you have on the subject, I might be willing to fight that fight with McAfee. Unfortunately, as a lowly shop owner with minimal knowledge and a measly attempt to stay PCI compliant and avoid trouble, I find myself mostly trying to appease them.

As such, if your comments above will work, I would certainly like to try it, but am a little unclear on the exact place and coding format I need. I found this line in my tpl_contact_us_default file in my template:

But I do not see a NONSSL reference to change to SSL. A little help if you can as to which file and code line I'm looking for to change would greatly be appreciated.

DrByte:

But, as I said in my first post in this long thread, the information collected is immediately sent off to the storeowner VIA EMAIL ... and we all know that EMAIL is the LEAST SECURE communication method on the internet. So ... protecting the collection of that info by SSL is entirely moot. Especially since THE PERSON GIVING THEIR EMAIL ADDRESS IS EXPECTING YOU TO EMAIL THEM AT SOME POINT. They WANT to be contacted. And they've opted to receive that contact via email. So clearly they don't object to the use of their information being shared in an email. So ... it goes back to the basic question: why is this considered "ultra sensitive" in the first place?
Anyway, rant over.

I suspect that your scanner is not doing its job correctly.

This I agree with, and was my reasoning for requesting a false positive in the first place. Though again, it's not a fight I feel confident in winning. If changing a bit of code somewhere can avoid the fight, I'm willing to go that route and move on. I do thank you for your help. I understand this is a bit of a sensitive discussion with heated opinions on both sides. I'm not strong enough on the subject to pick a side. I just want to be able to submit my little questionnaire and passing pci scan result and move on to the business of shop keeping:P

tstamplis,

Try getting a copy of this file
/includes/templates/template_default/templates/tpl_contact_us_default.php

Once edited it needs to be uploaded to this location - create if does not exist
/includes/templates/your_template/templates/tpl_contact_us_default.php

About line #16 edit to match this - I have not checked this and if it crashes - just delete the edited file

<?php echo zen_draw_form('contact_us', zen_href_link(FILENAME_CONTACT_US, 'action=send', 'SSL')); ?> 

kobra:

tstamplis,

Try getting a copy of this file
/includes/templates/template_default/templates/tpl_contact_us_default.php

Once edited it needs to be uploaded to this location - create if does not exist
/includes/templates/your_template/templates/tpl_contact_us_default.php

About line #16 edit to match this - I have not checked this and if it crashes - just delete the edited file

Very much appreciated!!  I did this, and it does not crash the page!  But, it also does not stop me from viewing the page in nonssl (by removing the "s" in the address bar).  I don't know enough to know if that is what McAfee is doing or not.  I am going to request another false positive citing this issue was corrected on all links on the site and see if they will either accept it, or offer advice on what they are doing specifically so perhaps I can address that specific issue.  Since every link to the contact us page on my site takes the user to a secure page, I don't see how they can argue that it is not secure since I don't know any user that would purposely change the URL to avoid SSL (I think Dr. Byte has given me motivation to fight them a little:)!  Thanks again to both of you!

If they deny the false-positive again, at least make sure they run their tests again, and not just merely argue verbally. And ask for someone more senior to explain exactly (and technically) why they're being so picky (for lack of using a different word I'd rather say LOL).

DrByte:

If they deny the false-positive again, at least make sure they run their tests again, and not just merely argue verbally. And ask for someone more senior to explain exactly (and technically) why they're being so picky (for lack of using a different word I'd rather say LOL).

That's easy enough. I have the McAfee hacker safe scan which scans daily for security AND PCI compliance. I'll just wait until tomorrow, after tonight's scan, and if they cite me again for this page, then I'll request the false positive. That way I know they scanned it again. Maybe I'll get lucky and this last file edit I just did will do the trick!

tstamplis:

But, it also does not stop me from viewing the page in nonssl (by removing the "s" in the address bar).

You can force this by adding a redirect such as the following (may need to edit for your server or if using a URL rewriter) to your site's main .htaccess:

RewriteCond %{HTTPS} !=on
RewriteCond %{QUERY_STRING} main_page=contact_us
RewriteRule ^index.php$ https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]

I am guessing they may be flagging this to lower the potential for man-in-the-middle attacks (It is easy to transparently proxy & filter non-SSL).

However I agree with what everyone else has been saying. Sending and reading email by default does not use TLS/SSL unless configured to do so... and even then, most email communications between different email servers (send / receive) are still done over a unencrypted connection. Not to mention how does your email client and email server store the sent / received emails? How do they store backups of the emails? And then even if every point is encrypted, all it takes is one weak link (such as someone clicking "reply" or "forward", a weak key, stolen device with saved password, etc) for the data to be compromised.

Many thanks to all of you. The last fix from Kobra did the trick, I have passed my scan!