[nextpage title=”Publishing Emails”]

You should not publish email addresses on your website, as spammers run programs that sweep the web looking for email addresses to build a database to send spam or sell said database to other spammers. This kind of program looks specifically for the HTML code “mailto:,” meaning clickable email addresses are more prone to be collected by spammers.

If you really need to publish an email address on your website, do not make it clickable. You should also replace the “at” and “dot” symbols for something else, such as “[at]” and “[dot].” So, an email address such as “name@yourwebsite.com” would be published as “name [at] yourwebsite [dot] com. ”

If you need users to contact you or your team, create a contact form, which hides email addresses and provides a protection against spam – if the form is built right, which is our next topic.

Also, you should not create obvious emails addresses, such as sales@yoursite.com, contact@yoursite.com.br, support@yoursite.com etcetera. Even if these emails are not publicly exposed, spamming software tries to send spam to this kind of email, and you will get spam on these accounts even if you never published them anywhere.

[nextpage title=”Contact Forms”]

Contact forms prevent spamming software from collecting your email address. However, if they are not built right, they can expose your email address anyway. And if the script behind the contact form has a security flaw, hackers can exploit it and use your website to send out spam. This is a very serious and, unfortunately, common problem. If your website is hacked to send out spam, in a matter of minutes your domain will be blacklisted and you will have trouble sending legit emails.

First, let’s talk about the basics. The HTML code of the contact form should not expose any email address. In Figure 1, you can see the code of a contact form on a website that has this problem. Notice, where we put the red arrows, how the destination email addresses are present in the HTML form. This means that when the user selects a “contact department”, the form is the one doing the conversion between “departments” and email addresses. This should not be done: as explained, the email addresses are publicly exposed this way.

Figure 1: Email addresses exposed on a contact form

Instead, the email address should not be exposed in the HTML code, and the script where the data is sent should be able to decode this request and send the message to the appropriate email address. In other words, the conversion between an alias (“department”) and an email address must be done behind the scenes, away from privy eyes.

Of course, you should not use an alias that is just the first part of the email address or use an obvious email address, as these are too easy to guess by spamming software. For example, if you have a contact option (“department”) called “research,” do not create an email called research@yoursite.com; this is too obvious and easy to guess.

The addition of verification code on contact forms, also known as CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart), is a must. You probably have seen this a lot, as either an image with random letters and numbers that you must repeat or a challenge question such as “what is the result of 1 + 1 – 2?” This should be done to prevent the use of spamming programs that try to send out spam in an automated way using your contact form. Even if your contact form does not have a security flaw that allows spammers to use your contact form to send out spam to other people, you will get a lot of spam on your email address coming from your contact form.

Figure 2: Use of a CAPTCHA code

[nextpage title=”Contact Forms (Cont’d)”]

The biggest problem with contact forms is that it is very common for them to have security flaws that allow spammers to send out spam using your website. This is a very serious problem.

The exact security flaw that your website might have will depend on its particular code, but the general idea is as follows.

Analyzing the HTML code, the hacker can get the variables that must be passed to the script available on your website that handles the data sent by the form and which sends the actual email. (The script is the one listed in the “form” tag.)

With this information, the hacker can now try to access the script directly, manipulating the variables. If the script allows the user to configure the destination email address, the hacker can now pass any address he wants to the script, hence allowing him to send spam to anyone.

Let’s say we analyze the HTML code of a form and discover that the name of the script that handles the form is script.php and that the form has fields called from, to, subject, and text. Now, it is very easy for the hacker to access https://www.yoursite.com/script.php?from=fromemail@fromdomain.com&toemail@todomain.com&subject=CHEAP%20VIAGRA&text=cheap%20Viagra%20at%20my%20website and send an email to “toemail@todomain.com” with the subject “CHEAP VIAGRA” and the text “cheap Viagra at my website.”

We must emphasize that if the contact form script of your website has a security flaw such as this, the hacker will be able to transform your website into a spam server.

As you can see, contact forms that have email addresses on their HTML code (see Figure 2) are the ones easier to exploit, since they have a variable to configure the destination email. However, even if there is no email address on the HTML code, the script may have a hidden variable through which a hacker can configure the destination email. For instance, a hacker will most definitely access the script directly trying variables such as “to” and “email.” If the script allows the external configuration of the destination email address, you are toasted: it is just a matter of time for hackers to discover the name of the variable. This is, of course, a major security flaw.

In summary, the script that handles the contact form must not accept the external configuration of the destination email address.

[nextpage title=”Security Through Obscurity”]

“Security through obscurity” is when someone, instead of creating proper security measures, simply relies on the design of the system, which is complicated (or so they think) to be guessed. The problem with security through obscurity is that you may think you are protected, when in reality you are not.

A script that handles a form posted on a website allowing hackers to remotely configure the destination email address through a not documented variable is an example of security through obscurity. In this case, the developer trusts that only because the name of the variable is not written on the HTML code, no one will be able to guess it.

A good example of security through obscurity would be moving the control panel of your website to a directory with a very unusual name and not use any login system on it, relying that since the name of the directory is too hard to guess, nobody will ever be able to locate and enter your control panel. The problem, once again, is to feel safe when in fact you are not.

You should analyze your website to see if this concept was used. Think like this: “is there any part of my website that could be easily exploited if someone guesses the right name (a directory, the name of a variable etcetera)?”