Website Security Tips for SEO

A hacked website can seriously affect your search engine optimization efforts. This article will explain the three ways it can hurt you, the major forms of attack, what makes a site vulnerable to them, and what you can do to protect your site from hackers.

A hacked website’s impact on SEO can be separated into three major categories:

Effect on search engine ranking. Major search engines like Google will penalize your website as an ”attacked” site or site hosting malware, and then your rankings will be dropped until the website has fully recovered from the attack.

This loss of rankings will of course affect website traffic, which your website needs in order to produce sales and profit.

Effect on customer quality experience and security. Sometimes, even though a site is not hosting malware (and is not labeled with the “This site may harm your computer” warning in Google’s search results), if your website security is compromised and you’re not aware of it, the attacker can plant scripts in your website in such a way as to steal your customers’ personal and financial information.

Examples of this information include user passwords, Social Security numbers, credit card information, etc.

Effect on trust. If your website security is compromised and your website has been confirmed as hosting an attacker who steals customer information, you might be liable to cover for damages, refunds, etc. The worst part is that the “trust” you may have once had as a reputable and secure merchant will be lost. And of course, it will be very hard to re-establish and recover your lost reputation.

No matter how good your website’s SEO is, if you ignore the site’s security issues, then all of your efforts to increase rankings and traffic will be gone in an instant the moment an attacker gets inside your website and compromises everything.

This article will examine some of the most common security issues found in most commercial and non-commercial websites and suggest some tips to help you improve or tighten the security.

Because of the increasing popularity of dynamic websites (websites that rely on the use of databases to display information on the web pages), according to “The Web Hacking Incident Database 2009,” SQL injection is responsible for 19 percent of the attacks.

Source: The Web Hacking Incident Database 2009

The primary causes of SQL injection include the following:

Insufficient user input validation. If you use web forms, URL query IDs, and/or cookies, then you need to carefully validate these things to ensure that what has been written to the database are real answers that do not contain “poisoned” queries that the attacker can manipulate further to compromise your website.

Different platforms need different solutions. In MySQL, you can use the function in PHP known as mysql_real_escape_string to filter inputs before doing any MySQL queries. Here is an example of a vulnerable script:

mysql_query("INSERT INTO example

(name, age) VALUES(‘$name’, ‘$age’ ) ")

or die(mysql_error());

Here is the sanitized query using the mysql_real_escape_string function:

$name= mysql_real_escape_string($name);

$age = mysql_real_escape_string($age);

mysql_query("INSERT INTO example

(name, age) VALUES(‘$name’, ‘$age’ ) ")

or die(mysql_error());

If you use the MS SQL server database (commonly used in IIS and ASP.NET 3.5 websites), you can start by scanning your website for vulnerability here and read for more tips

Poor database design. You should carefully design your database in such a way that it allows only practical data to be stored in it. For example, if you have name field, it would be impractical to assign 300 characters to it during the database field type assignment, since most person’s names may not even exceed 35 characters most of the time.

Improper database security privileges. Web applications should not be given root access to a particular database. Instead, it might be good to create a particular “user” account for a particular database that does not include ALL privileges. Most web applications only read and write database information, but should never be used to create tables, create databases or even access files in your server.

Since MySQL is the world’s most popular open source database, it is important for you to understand its security aspects. For more details, refer to this Dev Shed MySQL security tutorial

It is of primary importance that you have a “very strong password” if there is no way to isolate the administrator log-in panel from public access and it does not have adequate brute force prevention.

Such a password could be made from a 96-character system (mixed upper and lower case alphabet plus numbers and common symbols). Aim for a password that is a minimum of eight characters in length; 12 to 15 characters is recommended.

According to LockDown, using an 8-character-long password in a 96-character system means it will take 23 years for a brute force approach to succeed in a Class D attack.

A Class D attack is defined as using a “fast PC, Dual Process PC.” Of course, if an attacker is using a slower computer (such as a single processor), it will take longer.

However, I recommend using 12 to 15 characters in a 96-character system, as it offers the best security benefits overall (most platforms, like WordPress, can accept 12 characters in a 96-character system).

Insufficient authentication and brute force accounts for 22 percent of the overall hacking attacks, as observed in "The Web Hacking Incident Database 2009."

If you can isolate the administrator folder from public access, then you can permanently prevent brute force attacks (because you are the only one that can access the administrator log-in panel). For example, in WordPress, the administrator directory is wp-admin. If you upload an .htaccess to the wp-admin directory that contains the syntax below:

Order allow,deny

Allow from 123.456.789

It will only allow a client with the IP address 123.456.789 (in this case the administrator IP address) to access the wp-admin directory (to add a new post, edit posts, configure plug-ins, etc).

All other IP addresses (like public users, including hackers) will be blocked and given 403 forbidden errors. You can likewise apply this concept to all of your sensitive folders, including customer-related documents. Just upload an .htaccess and white list your IP address.

This is a technique used by hackers/attackers to impersonate your website on the Internet as if it were a legitimate/real website. Their objective is simple: to trick users into providing personal and financial information on those spoofed pages.

According to "The Web Hacking Incident Database2009," content spoofing attacks account for 10 percent of the overall types of attack.

Not only has this become a security issue, but it is a very serious concern for your SEO efforts, for a number of reasons.

Let’s consider what happens if attackers build several sites containing spoof content of your original website. If they can manage to market it in several medium (directories, search engines, etc), then it might appear that they are starting to gain authority and trust. Your website will be affected by serious canonical or duplicate content issues.

To combat this, use http://www.google.com/alerts (Google Alerts) so you can be informed in real time when your website’s name is been mentioned elsewhere. You can then check the source to find out if there is a spoofing problem. If there is, you can file under the DMCA to have the content removed from Google, or even report them to their web host for their illegal activities.

You should also protect your user’s important financial or personal information by using SSL. This is required because it can be used to authenticate the real website owner. For example, say you have an online banking business (which is a common content spoofing target), it is mandatory to use SSL in customer login pages for two reasons. First, because the client can use that to determine that the certificate issues really belongs to the bank owner; and second, for encryption purposes.

So how does the client determine if the certificate issued really belongs to the bank owner and not to anyone else?

Step 1. Client will go to an online banking website.

Step 2. Client will click to log in to his account.

Step 3. Your online banking website will then change protocol to https (secure mode).

Step 4. Your client (customer) will click the https in the address bar, and then click “More information,” and finally click ”View Certificate.” A sample screen shot is shown below:

As to the encryption purposes, SSL will encrypt the communication of everything from the client browser to the Internet banking server, thus any eavesdropping will be prevented.

A third way to fight this is to educate your clients on how to prevent content spoofing. That includes examining the website SSL certificate, making sure that the connection is encrypted (https) and making sure they are visiting the correct website (at the correct domain name with no misspellings) that matches in the address bar and the certificate issued.

Fourth, you can protect your domain name by registering it as a trademark. Remember, if someone registers a domain name very similar to yours, your client can be tricked into visiting that fake website and then entering financial information. Registering your domain as a trademark at least gives you some recourse. Other solutions are registering all domain misspellings and having them redirect to the official website. Google does this; for example, gogle.com 301 redirects to www.google.com.

Cross Site Scripting

This vulnerability is caused by the execution of script in the client browser that can result in either client or website security issues; for example, if a website is vulnerable to XSS (Cross site scripting), the attacker can craft a URL with  malicious code in it.

To deploy that, the attacker will send an email to one of their known clients with a link containing the malicious URL.

The client will receive the email, and then, since the URL is “correct” (not even a misspelling of the domain), the user will click on it, thus executing the code on his/her browser. The objective of the malicious code is to compromise user password and login details (contained in the cookies, for example), as well as other information.

Then once the login details are stolen, they will be sent to the attacker. The attacker can then use them to log in to the website (like a normal client).

The good news is that you can determine whether or not your site is vulnerable to cross site scripting by using the free edition of www.acunetix.com. if the site is vulnerable, you can prevent XSS attacks by sanitizing the inputs, as discussed here:

http://support.microsoft.com/kb/252985  

http://www.ibm.com/developerworks/web/library/wa-secxss/

Google+ Comments

Google+ Comments