So one day you wake up, go to your site, and yikes! You see your site is selling Viagra, your rankings are gone — or worse, your site has disappeared from Google.
What happened?
You rack your brain. Start calling anyone you know. You, my friend, have been possibly been hacked or jacked. Now what?
Well, let’s backtrack. Let’s look at three website exploits and what you could have done to prevent each from occurring in the first place.
1. XSS Scripting
“XSS vulnerabilities exist when a Web application accepts user input through HTTP requests such as a GET or a POST and then redisplays the input somewhere in the output HTML code,” according to Microsoft.
XSS scripting attacks happen when you leave your website open to script injections. A script injection is when you allow people to enter code into your site and that code to execute.
These script injections then change your website into whatever the attacker wants it to be.
Want to capture visitor login information? Sure.
Get all that meaty client billing data? Absolutely.
Sell them Viagra from your forums page? Yes.
I’ve actually seen someone run an entire mini-website inside a forums post with an embedded affiliate link.
When your site allows scripts to be injected into it, the party is open bar and your site is the one paying.
What is an XSS Attack?
XSS attacks involve three parties:
- The attacker
- The victim
- The vulnerable website that the attacker exploits to take action on the victim
You need someone to create the scripting attack, the person visiting the site or page, and the site that isn’t locked down, so that the attack may be executed.
Some of the most common reasons an XSS is implemented are to:
- Steal user data such as logins and passwords.
- Steal billing information.
- Create malicious code that gets your site labeled as malicious (hurts your rankings).
- Use your site position then inject affiliate or ads, that make someone else money (one site actually had someone redirecting their own products to a second site and the attacker site was pocketing their sales).
Injecting Testing
By simply entering a simple script into the search form of a site that has left itself open to such an attack, you can see that the form is vulnerable to injection scripting attacks:
<script type="text/javascript">// <![CDATA[
alert("HI - This site has a vulnerable form. April 11, 2011")
// ]]></script>
If I was less scrupulous (OK, and more talented, as I’m not a hacker), I could use this ability to inject scripts into their forms for other more nefarious activities.
What Can You Do?
You can use a very simple check to see, at the most basic level, if your forms are vulnerable.
Can you inject simple scripting code into your site? If you put this code into a form field and up pops the alert box, then you have a definite issue. Get help, now, like right now do not pass go or another day without it.
If this doesn’t work, does it mean you’re safe? No.
There are many other methods in which XSS attacks can be implemented, so you should always have your site checked over by a security professional or someone on your dev team who is adapt at security testing. However, it is a simple check that if you fail, tells you that you need to get someone onsite quickly.
When it comes to XSS scripting attacks, leaving your site vulnerable can lead to very expensive IT — and potentially even legal — costs. So think of that money you’re spending on security testing as an investment, not an expenditure.
2. Plugins/Add-Ons
This type of attack is geared to those using a free content management system (CMS). When you get that WordPress, Joomla or Drupal CMS tool set up and get your free plugins or add-ons, have you ever given any thought to the cost of free.
While open source and open dev systems have many advantages, put yourself in the mind of a hacker or site exploiter for just a moment. What is a great way for me to get lots of fantastic data or visitor information very quickly? Open development systems (i.e., create a plugin or add-on and away we go!).
Should You Freak Out?
Now before you get too concerned, it isn’t necessarily that the plugin is malicious, though there has been a fair share of those. However, just by putting up a plugin and having you register to get it, I just got lots of your personal information, including your login.
Where have you used that login before? What about your email? Wonder why spam never seems to die?
Now let’s take it one step further. Let’s say the plugin itself is nefarious. Will you know? Not if the programmer is good.
Think about XSS scripting. That requires a site that gives me accidental access to their backend. With plugins, you might be giving someone full authoritative access.
Would you know? Maybe or maybe not. Maybe you don’t know about it until a few people post about it in a help forum, but by then the person has their data, don’t they?
Now this isn’t to say you shouldn’t use these CMS tools or that you should read this article and disable every plugin you have on your site. Just do your due diligence.
Make sure you have an idea who you are getting your plugins from, that they are well known, and that the plugins are heavily used with no known vulnerabilities or malevolent behaviors. Just like when you use any product, don’t buy it off the truck in the back alley or you might just find yourself waking with empty pockets and buyer’s remorse.
3. Proxy Jack/Hack
The details of how this works will be at a high level. Basically, this is an attack technique designed to supplant an authentic web page in a search engine’s index and search results pages with another.
The main purpose of this hack? To kill your ranking.
However, past that, if you don’t know how, I don’t want to give you ideas, and it is a federal offense punishable with jail time. So if you go look it up and think, hmmmm I think I’ll try this, keep that in mind. No ranking is worth time in a jail (and this is in many countries, not just the U.S.)!
You should know that there is a way to protect yourself against this, even if you aren’t quite sure what all the details might be. I believe that it is increasingly being used against people.
Why? Because more and more, I talk to people and see the forums filled with people wondering, “Where did my site go?”
How Do You Know if You’ve Been Attacked?
Did your site or home page disappear from Google overnight? Is it OK in the other search engines?
Did you honestly examine your site (and link building) and are 100 percent sure that you aren’t suffering an extreme penalty such as the 750 or a keyword filter for overusing anchor text in links? And did copies of your content suddenly appear on the web? (Copy several long strings of your home page content, put it in quotes in Google search — is it suddenly showing up where it never did before?)
Is one of those sites Google’s own Appspot.com? Then it is likely you have been proxied.
If you have, then recovery will be difficult. However, there are ways if you attack it within the first 24-48 hours, or maybe if you’re lucky and can get to Matt Cutts and plead your case. This article, though, is to tell you how to help prevent it. The best way to make sure your site is set-up to avoid proxy attacks.
What Can You Do?
These are only a few things you can do, to help shore up your site from this extremely damaging and often unrecoverable attack:
- Use the canonical URLs to help give authority to your content as your content. This doesn’t always have a great affect on this type of attack, but it’s worth a try and good practice anyway.
- Block normal proxies using your htaccess in Apache or in IIS.
- Block Appspot.com. It’s important you do this, but be careful. If done incorrectly you can block the Google spider from indexing your site.
- Pass all spiders through a scripting check. One such check is to help prevent your content from being duplicated and is written by fellow Search Engine Watch contributor Gary-Adam Shannon. It helps make sure that if it isn’t the Googlebot, then it tells the spider not to index; you’ll probably want to add Bing and Yahoo to this also. Unfortunately, I only have a PHP version to share with you today.
I wish Google would address the Appspot issue as this seems to be the most problematic of the proxy hack/jack issues. However, the latest testing results show it to be quite alive and kicking.
So What Next?
Site security is an issue that will only become more complex as the web continues to develop. There are many more types of site attacks and hacks that can happen, so you must remain vigilant. The type of industry you are in will dictate some of your risk.
Above all, make sure to get your site tested and checked. Companies will do this for you, or if you have the budget, hire a developer with a strong background in security or “ethical” hacking.
Also, keep your site CMS up to date with all the latest security fixes. Make sure your system administrators (or hosting company) are doing the same with your servers.
By just keeping up to date, doing your due diligence, and making sure you have someone watching out for your security interests, you can help prevent the worst from happening to you.
If your site is hacked or attacked, don’t waste any time. Find and hire a security or forensics expert to get into your site right away as time will be of the essence if you hope to recover from an attack that affects your visits or your rankings.
Remember, it’s still the Wild West out there. Build a proper wall of protection around your site keep watch. Don’t be a victim!