WordPress is a-ok. Go Daddy is rock solid. Neither were ‘hacked,’ as some have speculated.

After an extensive investigation, we can report there was a small group of customers negatively impacted. What happened? Those users had outdated versions of the popular blogging software, set up in a particular way. – Alicia from GoDaddy

From what I have read around the web customers were being told that it was not GoDaddy’s responsibility to fix the sites, that they only offered “limited support” in situations like this, leaving people with only the option of restoring from a backup (which would often not help even in outdated WordPress hack situations, since hacks can go undetected for months) or hiring outside help to clean things up.

You can see on the support page they have set up, What’s Up with Go Daddy, WordPress, PHP Exploits and Malware? that they still claim that outdated scripts are part of the problem. Going to that page and viewing the source reveals something almost unbelievable:

(click to enlarge)

That’s right, in a classic “do as I say, not as I do” twist it seems that GoDaddy is in fact running an older version of WordPress (WordPress MU, based on the version number, which has the same security holes as regular WordPress) for their community blog that they are using to tell people to upgrade their WordPress versions.

To be fair, simply having an older version of WordPress does not mean that it is automatically insecure… the security fixes in the more recent versions may be minor and the known vulnerabilities might have been manually patched. I can’t know without actually digging deeper and looking if in fact the installation was vulnerable.

Then again… neither can GoDaddy in the case of their customers.

Although a change to AJAX technology would only make searches milliseconds faster, those milliseconds add up, allowing people to do more searches, faster. And that would let Google grow even more, eating up percentage points along the way. – Sarah Perez

However, what was missed by many in all of this is that when Google implemented this “fix” to retain the referrer, it wasn’t actually fixed in the way that they described in their blog post. What Brett Crosby highlighted in his post was the referring url itself that webmasters might start seeing in their traffic logs, and how it would be retaining the q= parameter for analytics packages to make use of, and nothing at all about how they were actually accomplishing this. He omitted these details even though he qualified the post in the opening by saying that they were writing it “for the most geeky among us”, and real geeks would want to know the nuts and bolts of what was happening. What neither he nor Google spokesperson Eitan Bencuya mentioned when discussing this is that the magic of retaining the referrer was not accomplished by simply coming up with a new url structure… due to the way that all major browsers function, just changing the url won’t fix the issue. Google engineers, to the best of my knowledge and generally speaking, are smart people. They know this. It simply cannot be done. Therefore what they did is to create a second, interim landing page that users are funneled though when they click on a link in the serps. This page then loads some Javascript that is processed, which when complete fires either a Javascript driven redirect or a meta refresh in the users browser, eventually bringing them to their final destination page.

If you happen to be getting served these new urls, you can see what the Javascript code on these new pages looks like by right clicking on the url and choosing to save the target. If you then view the file in a text editor, you will see code similar to this (there are a couple of variations on what code they are testing, apparently):

<script>if(parent!=window&&parent.google){parent.location.href='http://www.bad-neighborhood.com/';location.replace('about:blank')}else{location.replace('http://www.bad-neighborhood.com/')}</script><noscript><META http-equiv="refresh" content="0;URL=http://www.bad-neighborhood.com/"></noscript>

which was generated by saving this url:

http://www.google.com/url?sa=t&source=web&ct=res&cd=1&url=http%3A%2F%2Fwww.bad-neighborhood.com%2F&ei=YVbnSYraM5CNtgevkpzLBQ&rct=j&q=bad+neighborhood&usg=AFQjCNH7sp5nWWhaVsJafdeL1Rw8-TTXxA

Why does this matter? Well, remember, the gain that Google is getting from doing this switchover to AJAX is, on a per-search basis, minimal at best. It is in the area of milliseconds. Now to correct something that it breaks they are adding in two additional slowdowns to the navigation process… the delivery of more html, which although tiny does involve time itself to connect to the server and deliver the actual code, and the processing time of each browser to either interpret the Javascript or trigger the meta refresh. This not only nullifies any benefit that would be gained by switching to AJAX in the first place, in many, many cases it will actually cause the searches to be slower than if Google had just left things alone.

Google is aware of this too. Matt Cutts mentioned again the other day how he wished there was a better solution:

The problem is, of course, the better solution is to not make the changes. Unless all mainstream browsers recode the way that they handle url fragments after the hash mark (#), and Google waits until everybody in the world upgrades to those versions, it’s just not going to happen.

By the way, has anyone else noticed that Google is actually cloaking these new urls that they are delivering to people? If you happen to have your status bar turned on, and you mouse over a url in the serps, it shows you the final destination page instead of the actual one:

However, if you click on the url (even a right click), the true target suddenly appears:

Not that big of a deal, I know, and nothing that they haven’t done before, but still. Between that and the “don’t bother reading this post, it’s just for geeks” intro on the Google Analytics blog post it almost seems like Google is making an effort to not have these new changes noticed. If this change is such a great idea, I would have to wonder why that would be.

While those things would definitely be affected in at least the short term, there is a much greater impact from Google switching to AJAX. All of the issues mentioned involve a very small subset of the webmastering community. What actually breaks if Google makes this switchover, and is in fact broken during any testing they are doing, is much more widespread. Every single analytics package that currently exists, at least as far as being able to track what keywords were searched on to find your site in Google, would no longer function correctly.

The reason this breaks is core to the way all of the browsers handle referrer strings, which is how the browser tells the web server how it got to your page in those cases where it does send that information. Sending the referrer string is optional, and can even be turned off, although by default it is on in all of the major browsers that exist today. Analytics programs, whether they are log based (programs that go through the server logs reading the referrer strings) or Javascript based (such as Clicky, the built in tracking in MyBlogLog, and Google Analytics) use that referrer string to determine what it was that that someone actually searched on, assuming that they found your site via a search engine, before reaching your site. For Google, they analyze the querystring portion of the referring url, and look for the “q={keyword}” parameter. So for instance, if you were to find the following url in your logs:

then you would know that someone had gone to Google, searched on [troll defense], and then clicked on the link to your site. If you were running some form of analytics program, that program would then register and track that search for you, so you knew what was and what was not sending you traffic from Google. If you run Google Analytics, you can even hack it to get the full referring url and get even more information from the referral.

However, if Google switches over to AJAX none of this will be possible. Unfortunately this isn’t even something that could be accomplished with a simple recoding of the analytics packages either… it would require completely rewriting the browsers themselves in order to track referrals from the new Google AJAX searches. The new AJAX url, as I mentioned in the earlier post, is driven by parameters that come after the hash mark (the number or pound sign in the url). Browsers do not include that data in the referrer string, and it is never sent to the server. Therefore, all referrals from a Google AJAX driven search currently make it look as if you are getting traffic from Google’s homepage itself. Now, while this kind of information showing up in your tracking programs might be quite a boost to the ego if you don’t know any better, and will work wonders for picking up women in bars (“guess who links to me from their homepage, baby!”), for actual keyword tracking it is of course utterly useless.

On Friday I set up a couple of tests to demonstrate this, so I could show the results in the server logs, MyBlogLog tracking, and even in Google Analytics itself. I found a phrase that I was ranking for, that I knew that no one was searching on, [bad neighborhood vandemar], and sent myself some referrals. In every case the method I checked showed Google.com itself as the referring site. You can see this in the server web traffic log:

in MyBlogLog stats reporting:

and even in Google Analytics:

I don’t know if Google has considered these ramifications in making this switch over, or if this testing is something that they are actually interesting in pursuing. I don’t know why they would be testing a change of this magnitude in the first place, though, unless there was a good chance that they would eventually go live with it.

I noticed this as soon as I started searching for stuff today, from almost the first query I typed in. When I looked at the url, instead of seeing the normal /search?= at the beginning:

I found myself looking at this:

You can see that the query string, the portion of the url that sends parameters such as what keywords you are looking for and how many results per page you want to see to the server, has been removed, and that Google has replaced it with a hash tag, the part or the url that is normally only read by the browser itself (everything after the pound or number sign, shift-3 on the keyboard: “#”). This was what first clued me in to the fact that they had changed over, as this is a common visual way to indicate a “page change” to the user, letting them know that they have gone from one page to another in AJAX (which can perform the changes with no url change at all), and allows the Back and Forward buttons to still trigger AJAX calls.

I verified that this is indeed what is happening by performing a search, viewing the source of that search, and then looking inside that source for some text that I knew was on the page. For example, if you perform a search for [bad neighborhood]:

and then view the source, and search for [Search Engine Optimization] (which is clearly on the page):

you can see that it’s nowhere to be found:

So, what does that mean for us as searchers? To be honest I’m not sure of the full impact of this yet. I do know that AJAX can use more memory than pages generated by flat HTML, especially in Internet Explorer, so some older machines with fewer resources (such as those that might be prevalent in struggling businesses during economy strapped times) will possibly have performance issues. Also, certain Greasemonkey scripts will break with this change, like the handy Number Google Results, the script that allows you to insert sequential numbering into Google results, so you know where a site ranks at a glance without having to count.

As Google does with so many of it’s roll outs, there is no way to turn this feature off, either… so if it does affect you, tough. Google apparently doesn’t care. For now you can manually change the url by hand, but that is of course a pain in the keister. If anyone else finds other issues with this new change, or ways that it impacts us as searchers (or as seo’s, for that matter), please chime in.

Those who know me know that I always prefer to do manual upgrades, wiping everything out and starting over completely fresh each time, whether I have been hacked or not. This way if there was an intrusion it should still clean the hack out completely, even if I don’t know it’s there. As it happens, when I upgraded to 2.6.5 from 2.6.2 I did not do this. I merely upgraded the 2 files involved in the security portion of the WP 2.6.5 upgrade (which were wp-includes/feed.php and wp-includes/version.php). However, to date those are still the only two files from that version with a security risk according to WordPress, and I upgraded them well before I was hacked.

I noticed something was wrong earlier this week, after I wrote the post on how to easily find free photo downloads for your blog posts. I was checking to see if the post had any rankings a couple of days later, when I noticed that it wasn’t showing in Google. I don’t mean that it wasn’t ranking, either… I mean it wasn’t showing at all. I checked, and sure enough Google had definitely cached the post shortly after I had published it. It was showing when I did a site: command too. I realized that somethings was weird, however, when I saw that the description for my homepage still showed my post from November as being the snippet in the serps:

I checked that as well, and just as I thought they had already re-cached the homepage too, which means that showing the old snippet made no sense:

Neither the post itself nor the homepage were showing in the serps at all, even for exact phrases unique to those pages, phrases that were showing in Google’s cache, and therefore should have been searchable. My first thought was that I had been penalized for some reason (the conspiracy theorist in me even considered it might be the “PageRank for Sale” alt text on an image from Novembers post ), so I sent off a couple of Tweets asking people if they saw anything I might have missed.

Luckily, one of the people listening who was kind enough to respond was John Mueller. After telling me that I need to upgrade my tinfoil hat to Mu-metal one (heh, thanks John! ), he found the issue fairly quickly:

The link he gave me pointed to the text-only version of Google’s cache of my homepage, and when I scrolled down, sure enough there it was:

I upgraded last night (complete wipe and reinstall this time), but I’m a little concerned still. Since there has still been no word from WordPress about 2.6.5 being vulnerable, that may mean that it is something that they are completely unaware of, and therefore was carried over into WordPress 2.7. I did some research on other hacked blogs, and while I did find one other 2.6.5 blog and one 2.7, comparing their caches against other older cached pages on the same site it looks like both of those were hacked prior to them upgrading. If anyone else find more information about blogs that have gotten hacked after upgrading to WP 2.6.5 or above, please let me know.

The Problems

Two internet no-no’s that beginner web publishers often perform, many times without even realizing that they are doing anything wrong, are image theft and image hotlinking. The bottom line is that most images on the Internet are in fact copyrighted, and therefore cannot be used without the original author’s explicit permission (assuming, of course, that the original author is still in fact the copyright holder). Just because you find a picture posted on a public forum or on a newsgroup does not mean that the person who posted it had the right to post it, and if they did not then republishing it on your own site makes you just as guilty of copyright infringement as they are. While 9 times out of 10 you might get away with it, using someone else’s copyrighted material can lead to troubles (and time wasted dealing with those troubles) in the form of a DMCA Takedown Notice. In extreme circumstances, depending on your host and the degree of the infringement, this can even lead to the interruption of your hosting account.

Hotlinking an image is a little less of a cut and dried issue as far as whether or not it actually violates copyright laws. As far as I know the matter simply has not been tested in court, and legal opinions concerning it can vary. What is generally agreed upon regarding it is that it is impolite at best (regardless of arguments about how cheap bandwidth is). Additionally, you do run the risk of whoever you are hotlinking the image from simply switching it out for a different image if the request shows your site as the referrer (check out John McCain’s MySpace Page “Enhanced” for a classic example of this).

The Solutions

Luckily, however, there are plenty of images available out there that you can use, as long as you know how to find them. You can use any images that are within the Public Domain freely, and with a few easily followed terms many photographers and artists offer their images available under the Creative Commons license. Also, there are a few Free Stock Photo sites out there as well that offer a nice selection of images that can be used in blogs posts.

Finding Public Domain Images

Public Domain refers to any work that is not copyrighted or work on which the copyright has expired. Instead of worrying about how to try and find formerly copyrighted images where the copyright has expired, I am going to focus on how to locate ones that were never copyrighted in the first place. In the US, works that are authored by the federal government are not copyrighted, and therefore fall into the Public Domain. It is important to note that the distinction is works that were authored by them, and not all works that are owned by them. If a private individual creates the work, and then sells or transfers the copyright to the government, the work is still copyrighted. Also, some specific images might have use restrictions on them. A good example of this is the NASA logos… the general permission to use all images found on the NASA site does not extend to the logos. Specifically, none of the three logos may be used “by persons who are not NASA employees or on products (including Web pages) that are not NASA sponsored.” All others are pretty much fair game.

Now that we know where these images are that we can use, we need to figure out how to search through them and find the ones we want. There are a couple of useful methods for doing this. One of the easiest ways is simply going to Google Images, and performing a “site:{somegovtsite.gov}” search, plus whatever keyword you are looking for. Which federal government site you choose will most likely be based on what types of images you are trying to hunt down. For instance, if you need to find a good wildlife picture, then the US Forest Service at www.fs.fed.us is probably a good place to start. So, if for instance you need a deer picture, you would go to Google Images and type in:

[site:fs.fed.us +deer] (note that dropping the “www” from the “site:” search enables you to pick up any subdomains as well)

While not all of the images are exactly what we are looking for, we can see that some nice matches do come up on the front page:

If you notice results that appear to be from sites other than ones owned by US government (such as Blogspot or Myspace), don’t worry… those are people who are using hotlinked images on their own pages. The images themselves are still hosted on the government websites. Some good examples of federal government sites that are rich in images, along with the number of images returned for each by using the “site:” command without a keyword in Google Images, are:

• NASA (nasa.gov) – 1,020,000 image results
• The Whitehouse (whitehouse.gov) – 116,000 image results
• Library of Congress (loc.gov) – 186,000 image results
• Government Printing Office (gpo.gov) – 8,370 image results
• Department of Education (ed.gov) – 23,400 image results
• National Oceanic and Atmospheric Administration (noaa.gov) – 317,000 image results
• Department of Energy (energy.gov) – 22,100 image results
• Environmental Protection Agency (epa.gov) – 65,000 image results
• US Forest Service (fs.fed.us) – 122,000 image results
• Federal Aviation Administration (faa.gov) – 9,720 image results
• US Army (army.mil) – 304,000 images results

Using parenthesis and the OR operator, you can also search multiple government sites at once, like so:

[airplane +(site:army.mil OR site:nasa.gov OR site:site:faa.gov)]

Which in the above example will search the US Army, NASA, and the Federal Aviation Administration websites for images matching the keyword [airplane] all at the same time.

Another option for searching the federal stockpile of images is to use the image search functionality on the USASearch.gov website. While you don’t have the luxury of being able to restrict your search to specific sites, you do have the added ease of being able to search all of the federal government sites at once, along with certain archives that might not be indexed by Google.

Finding Creative Commons Images

The Creative Commons is a set of free licenses that allow artists to share their work, while still retaining some of their rights. For bloggers, usually the images they will be most interested in are those that are licensed under straight Attribution. That means that you are free to share or modify the images as you need, even for commercial purposes, as long as you attribute the original work of the author in the manner they specify. This is usually done simply via a link back to the original image.

Google has an option on their Advanced Search to only search documents that are released under Creative Commons license. However, for some reason they don’t offer the same option under the Google Images search. Even if you search for a keyword and restrict the results to only show Creative Commons results in Web Search first, and then click on the Images link, the url parameter that tells Google that you want to restrict the search results is dropped. Luckily though, adding the parameter in manually does in fact work. I created a small tool on Bad Neighborhood that allows you to enter a search term in, and it will open up a Google Images search with the parameter that restricts the results to only show images released under Creative Commons here:

Creative Commons Google Image Search Assistant

Most of the results that you will see with this search will either be from Flickr and Picasa Web, since those images appear to be the ones that Google has the easiest time identifying the licensing on.

Unless you uncheck the checkbox at the bottom of the last paragraph on the page, you will notice that 2 windows open at the same time when you use that tool. This is because Flickr also has it’s own integrated Creative Commons search, on it’s Advanced Search page, but since the link to that page doesn’t show unless you perform a regular search first, many people won’t realize that it is an option. This tool includes a search on Flickr as well by default, without you having to go to the Advanced Search page first.

If you want to perform just the Flickr search, you can go there, and click on the search button. The link to the Advanced Search will then appear just to the right of the search box:

Once there, scroll down to the last set of options, and you will see 3 checkboxes that you can use to search only for content that you are allowed to use under the Creative Commons:

Once you find a picture that you think fits, you can verify that it is indeed released under Creative Commons by looking for the CC logo in the right hand column:

Just remember to attribute the author of any original work that you use.

Finding Free Stock Images

Lastly, there are of course the Free Stock Photo sites that most people are aware of. Last year Donna Fontenot wrote a post about her Favorite 10 Free Stock Photo Download Sites. Out of those, I picked my favorite 7, and built a tool using the same “site:” search plus OR operator method I described above:

Bad Neighborhood Free Image Meta Search

Simply enter your keywords into the box and hit Search. A new Google Images window will open up, allowing you to simultaneously search all 7 sites as once for images matching your keywords. While the selection may not be quite as great as going to each site one by one and using their built in search functionality, it can be much, much quicker to find a graphic that fits your needs this way.

Happy Image Hunting.

Our purpose is rather simple. We want to make the internet as open as possible. Currently only a select few corporations have a complete and useful index of the web. Our goal is to change that fact by crawling the web and releasing as much information about its structure and content as possible. We plan on doing this in a manner that will cover our costs (selling our index) and releasing it for free for the benefit of all webmasters.

If, again, DotBot is owned by SEOmoz, then actual goal of collecting those webpages was the development of a commercial tool. With that in mind, Rand’s refusal to remove pages from the index that the owners do not want in there takes on a whole new level of unreasonableness. When pressed about it, this is the most Rand is willing to compromise as far as removing sites from the index:

3)SEOmoz will ONLY remove your site from DISPLAYING your data through Linkscape if you add a customized SEOmoz meta tag to each and every page on your site, and even then, only after a 30-60 day time period.

Yes, although we are looking at ways to block an entire site from being shown in the future through a registration system. And yes, we can’t block anything until we’ve re-crawled and re-indexed that page, which can take 30-60 days depending on the speed with which we crawl/re-crawl a given URL.

4)SEOmoz is “unwilling to provide a clear concise way to keep data out of Linkscape.”

That’s what you said, and I merely copied it to point out that it had an exception. I know it’s a fun soundbyte, but without the important caveat in the sentence it was in, it’s really unfair to keep using this phrase. That caveat is that we are willing to provide one clear, concise way to keep data out of Linkscape – the seomoz noindex meta tag.

So, the only way Rand will voluntarily remove your site from his index is if you agree to basically brand your website with a meta tag using his company name, and then wait 30-60 days. Unfortunately for him, that’s really not his call.

You own your website and the data it contains (assuming you did not scrape it from somewhere else, of course), and that ownership is protected under US copyright law. Anyone whose rights are violated under that law have specific remedies available to them under the Digital Millennium Copyright Act.

Now, I cannot stress this strongly enough… these remedies are not intended to harass a website owner. They should be used neither frivolously nor fraudulently, and there are penalties for filing false information. You should under no circumstances perform this process for any urls or domains that you do not explicitly own, and if a counter-notification does get filed then you should in fact follow through with a lawsuit.

For all valid claims, I am outlining an easy to follow process for requesting that your information be removed from his index.

First, verify that your content is indeed in their tool. If it is, then the next step is to contact SEOmoz directly. Give them a chance to rectify the situation within a timely manner. Send a polite request that your entire domain be completely removed from the index powering their Linkscape tool, and for a way to confirm that it has indeed been done once they have. The support email for SEOmoz is listed on the site as sitesupport@seomoz.org, or you can fax them the request at (206) 338-3797. In this request you should list who you are, the address of your domain, and your contact information. Despite Rand’s insistence that they cannot do this, it might turn out that they do in fact have the ability after all. Do not skip the step of contacting them first. For tracking purposes, you might want to CC their ISP with this initial request, to document that you did indeed attempt to resolve the issue with them first, although this is not required. If you do decide to do that, SEOmoz’s ISP is HopOne Internet Corporation. The appropriate email to use for these matters, according to HopOne’s AUP, is abuse@hopone.net, and their fax is (604) 608-2953.

If after a reasonable amount of time, say, 24 hours, they still have not removed your sites information, then you can consider sending a formal DMCA letter to their ISP, HopOne. The requirements for such a letter are very specific, and are laid out in 17 U.S.C. § 512(c)(3), ” Elements of notification”. A sample DMCA notice for this purpose might look something like this:

To: abuse@hopone.net
Subject: Notice of Copyright Infringement
The copyrighted work at issue is the the entire set of links appearing on my domain at {www.mydomain.com}, each comprised of their respective URLs, anchor texts, and attributes, including both those constituting my websites navigation, as well as those linking my website to other websites on the Internet. While I acknowledge than an individual url in and of itself may not be copyrightable, I maintain that the set of links residing on my website taken as a whole or in sections do in fact comprise a structure that is unique and my own property.

The freely accessible URL where my copyrighted material is located is accessed through the gateway page located at http://www.seomoz.org/linkscape . Since the interface that is displaying my content is only visible via an http POST request, it is necessary to enter my domain {www.mydomain.com} into the text box presented, and then press the button labeled “GO”, in order to view the infringing material. Note that while this does demonstrate the existence of the infringing material being used on the server, it is only the one open to the general public without paying a fee, although this request is for the removal of the information from the index completely, including from areas accessible only to paying members of the website.

The contact information for the company of the infringing website, as indicated by their Contact Us page, is as follows:
Office: (206) 632-3171
Fax: (206) 338-3797
sitesupport@seomoz.org
SEOmoz.org
1221 E. Pike St., Suite 200
Seattle, WA 98122

I can be reached at {your@email.com}, or via telephone at {your telephone number}. My mailing address is {your full mailing address, including street and number, any apartment number, city, state, and zip code}.

I have a good faith belief that use of the copyrighted materials described above as allegedly infringing is not authorized by the copyright owner, its agent, or the law.

I swear, under penalty of perjury, that the information in the notification is accurate and that I am the copyright owner or am authorized to act on behalf of the owner of an exclusive right that is allegedly infringed.

At your earliest convenience, please respond to this letter at my email address listed above, and let me know what actions have been taken to resolve this matter. Thank you.

My electronic signature is below:
{Put Your Name Here}

Bottom line is, it would be nice if Rand would simply step up to the plate and actually be the nice guy he wants everyone to believe that he is. Until such time as that actually happens, however, as sad as it may be, this may be our only recourse to keep him from using our information without consent.

Eventually, after much complaining from the webmastering community (and not until many webmasters had been adversely affected by it), Google changed the way that they handled 302 redirects. Supposedly, this fixed the problem. In January 2006, Matt Cutts discussed how those changes worked:

Many months ago, if you saw someresult.com/search2.php?url=mydomain.com, that would sometimes have content from mydomain. That could happen when the someresult.com url was a 302 redirect to mydomain.com and we decided to show a result from someresult.com. Since then, we’ve changed our heuristics to make showing the source url for 302 redirects much more rare. We are moving to a framework for handling redirects in which we will almost always show the destination url. Yahoo handles 302 redirects by usually showing the destination url, and we are in the middle of transitioning to a similar set of heuristics. Note that Yahoo reserves the right to have exceptions on redirect handling, and Google does too. Based on our analysis, we will show the source url for a 302 redirect less than half a percent of the time (basically, when we have strong reason to think the source url is correct). – Matt Cutts

Since that time, aside from the rare rumor here and there, 302 page hijacking pretty much seemed to be a thing of the past.

Last week, however, I noticed what appears to be a fundamental change in the way that Google is handling 302 redirects, and one that goes directly against what Matt blogged two and a half years ago. Until last week, one of the more commonly seen cases of 302 redirects in the serps, where the destination url is the one displayed, was the login screen for blogs powered by WordPress. When you try and access a screen that requires you to be logged in (for instance, /wp-admin/, or a private post), WordPress delivers a 302 redirect to the login screen, and includes a parameter in the url so it knows where to take you once you have actually logged in. Since Googlebot is never actually logged in to peoples WordPress installs, whenever it tried to spider a /wp-admin/ folder, you would see the page that was redirected to in the serps, like so:

(click to enlarge)

Then, all of a sudden, it looks as if Google has started to change that, and is instead reverting back to showing the url that is actually getting redirected in the serps, but again showing the content of the target page in the cache:

(click to enlarge)

This would of course lead me to believe that it is now possible to again hijack a competitors page by using a 302 redirect. With a little poking around, I was in fact able to find a case of this happening. If you perform this search, you can clearly see an instance of Google showing a source url that is performing a 302 redirect (I confirmed this using Bad Neighborhood’s Header Detector), and showing the content of the target website, and doing so across domains:

(click to enlarge)

Viewing the cached copy of the url in question (via [cache:www.f2b.be/__redirection__/linkexchange/out.php?id=34]) confirms that this is indeed a case of one site hijacking a page on a different site altogether. While this particular instance may be completely harmless, the fact is that the exploit itself is indeed back, and it is almost a guarantee that there will be webmasters that will get hurt by it. We can only hope that this time Google doesn’t wait quite so long to fix the issue, and that not too many webmasters are affected before they do.

While almost all sources will recommend that you upgrade your WordPress to the latest version, what the majority neglect to tell you is that in most cases simply doing so will not prevent the attackers from getting back in, even if there are no known exploits with the latest version. The hackers may have left a back door file hidden in a directory where it wouldn’t get overwritten with an upgrade, or inserted code into your theme, or simply created an account that they then granted admin privileges to. Any one of those would allow them back in, even after you patched what was wrong the first time. Therefore I am providing this step by step process on how to completely clean out and restore a WordPress installation that has been hacked.

1. Backup the site and the database.

Even a hacked copy of your blog still probably contains valuable information and files. You don’t want to lose this data if something goes wrong with the cleanup process. Worst case scenario you can just restore things back to their hacked state and start over.

2. Make a copy of any uploaded files, such as images, that are referenced.

Images are generally exempt from posing a security risk, and ones that you uploaded yourself (as opposed to ones included with a theme, for instance) will be harder to track down and replace after things are fixed again. Therefore it is usually a good idea to grab a copy of all the images in your upload folder so as to avoid broken images in posts later. If you have any non-image files that could potentially have been compromised, such as zip files, plugins, or php scripts that you were offering people, then it is a good idea to grab fresh copies of those from the original source.

3. Download a fresh version of WP, all of the plugins you need, and a clean template.

Using the WordPress automatic upgrade plugin does make it easier to upgrade every time a new version comes out. However, it only replaces WordPress specific files, and does not delete obsolete ones. It also leaves your current themes and plugins in place, as is. This means that if used to upgrade a blog that has already been compromised, it can very well leave the attackers a way back in. It is best to start over from scratch as far as the files portion of your installation goes. Note that if you use the EasyWP WordPress Installer script that I wrote it saves you from having to download, unzip, and then upload all of the core WordPress files, although you will still need to grab fresh copies of the themes and plugins that you want to use.

4. Delete all of the files and folders in the WP directory, either through FTP (slower) or through cPanel’s File Manager (faster).

Now that you have fresh copies of all the files you need, and copied all of your uploaded images, completely delete the entire directory structure your blog is in. This is the only surefire way to completely remove all possibly infected files. You can do this through FTP, but due to the way that FTP handles folder deletion (ie. it walks the directory structure, stores each and every file name that needs to be deleted, and then sends a delete command for each one), this can be slow and in some instances cause you to get disconnected due to flooding the server with FTP commands. If available it is much faster to do this through either cPanel’s File Manager, or via command line if you happen to have shell access.

5. Re-upload the new fresh copies you just grabbed.

This step should be self explanatory, but I would like to mention that if your FTP client supports it (I use FileZilla, which does) and your host allows it, then increasing the number of simultaneous connections you use to upload can greatly reduce your overall transfer time, especially on servers or ISP’s where latency is more of an issue than bandwidth. In FileZilla this setting is found by going to “Edit -> Settings -> File transfer settings”:

Also, if not using the EasyWP WordPress Installer script, don’t forget to edit and rename your wp-config.php file (when freshly unzipped this is named wp-config-sample.php).

6. Run the database upgrade (point your browser at /wp-admin/upgrade.php).

This will make any necessary changes to your database structure to support the newest version of WordPress.

7. Immediately change your admin password.

If you have more than one admin (meaning any user with editing capabilities), and cannot get the others to change their passwords right then, I would change their user levels until they can change their passwords as well. If there is anyone in your user list that has editing capabilities, and you do not recognize them, it’s probably best to just delete them altogether. If changing passwords is something you hate doing, then maybe my new memorable password generator can make that a little less stressful for you.

8. Go through the posts and repair any damage in the posts themselves.

Delete any links or iframes that were inserted, and restore any lost content. Google and Yahoo’s caches are often a good source of what used to be there if anything got overwritten. The following query run against the database can help you isolate which posts you want to look at:

SELECT * FROM wp_posts WHERE post_content LIKE '%<iframe%'
UNION
SELECT * FROM wp_posts WHERE post_content LIKE '%<noscript%'
UNION
SELECT * FROM wp_posts WHERE post_content LIKE '%display:%'

If you did not change the default prefix for WordPress tables, than you can copy and paste that directly into a query window and run it, and it should pull up any posts that have been modified to hide content using any of the methods I have come across so far (iframes, noscript tags, and display:none style attributes). To get to a query window in cPanel, you would click on the MySQL® Databases icon, scroll to the bottom of the page, and then click on phpMyAdmin. Once the new window or tab opens, you would click on the database in the left hand side that your blog was in, and then in the right side at the top click on the SQL tab. Then just paste the query into the large text area and hit the Go button.

Note, however, that there may be other types of injected content that I haven’t seen yet, and that a manual inspection looking for the types of patterns that first alerted you to the fact that your blog was hacked is always a good idea.

UPDATE: 9. If you are having issues cleaning the installation yourself

When I wrote this post back in 2008 I intended it to be a do it yourself guide for the non-techie. However, I do realize that some people would still rather a professional programmer perform many of the steps I outlined here. If anyone has had their WordPress installation hacked, and either is uncomfortable attempting to clean it on their own, or has tried to do so with no success, I am available on a case by case basis. Most cleanings can be performed in about one hour, two at the most. The time can vary depending on the size of the blog, the amount of customization to the original theme, and the number of plugins installed. Feel free to contact me here if you feel like you could benefit from my help. Please include the site and any details that you think might be relevant (pro theme, anything you may have tried on your own, etc.) in the contact form.

UPDATE #2: 10. A note on hosting.

This past year (2010) has seen multiple waves of attacks on people’s websites that happened not due to insecurities within the WordPress platform itself, as has historically been the issue, but rather due to vulnerabilities with the actual hosts. Some of the bigger names that were hit include GoDaddy, Rackspace Cloud, MediaTemple, and Network Solutions, for instance. It is very important that you use a host that is not only well versed in security, but one that is stable and has knowledgeable tech support as well.

My personal recommendation for shared hosting is Hostgator. It is where this blog and many other sites of mine are currently hosted. Yes, that is an aff. link, but I would recommend them even if it wasn’t. For a dedicated solution that is both affordable and robust I use The Planet, which is where I host Bad Neighborhood. Both companies are ones that I have been using for years without issues, and that I do recommend to my own clients when they find themselves dissatisfied with their current hosts. If you were hacked, and your WordPress was up to date when it happened, then a change of hosts is something you should consider looking into.

“You must have and abide by an appropriate privacy policy that clearly discloses that third parties may be placing and reading cookies on your users’ browser, or using web beacons to collect information, in the course of ads being served on your website. Your privacy policy should also include information about user options for cookie management.”

On May 22nd, 2008 the AdSense team sent out an email announcing that they would now be accepting third-party ads on the AdSense network, and that if a publisher wanted to opt in to show those ads on their websites, they must update their privacy policies, this time including links to those third-party
advertisers:

“If you choose to allow third-party ads on your site, please update your privacy policy to inform your visitors that third-party vendors may serve ads on your site. Please also provide links to these vendor websites and inform your users that they may opt out of cookies (if the vendor offers this capability).”

Since the list of third-party ad providers on Google clearly states: “At its sole discretion, Google reserves the right to change this vendors list at any time”, I decided to provide a few easy methods for webmasters to include a version of the list that will automatically update itself.

I provide the list as an XML feed. You can see the feed here: google-third-party-ads.blogsblogsblogs.com. It looks like a normal webpage, because I styled it using an xsl stylesheet, but if you view source on the page you can see that it is actually a valid XML document:

(click to enlarge)

PHP provides some easy functions for working with XML, if you are comfortable with those.

I also provide the list as serialized data. For many people this will be easier than working with XML, since simply calling the unserialize() function will turn the list into a PHP array. To grab the serialized data, simply append ?output=serialized to the address, like such:

http://google-third-party-ads.blogsblogsblogs.com/?serialized=true

As long as your privacy page can process PHP (ie. if the extension is .php, or you have it set up to parse PHP inside HTML files), you can just copy and paste the following code where you want the list to appear in your page:

<?php
$thedata = unserialize( file_get_contents(
"http://google-third-party-ads.blogsblogsblogs.com/?serialized=true" ) );
$providers = $thedata["provider"];
echo '<ul>\n';
foreach( $providers as $provider ){
	$ptitle = $provider["title"];
	$purl = $provider["url"];
	echo '<li><a href="$purl">$ptitle</a></li>\n';
}
echo '</ul>';
?>

You will have to replace the funky single and double quotes with regular ones to use that code snippet in a PHP page.

Lastly, I provide the list as Javascript widget. Perhaps the easiest of all is the free Google third-party ad providers widget. Simply cut and paste this code into any HTML page (no PHP required) and the list will appear in it’s place when someone visits the page:

<script type="text/javascript" src=
"http://google-third-party-ads.blogsblogsblogs.com/gtpap.js"
id="gtpapwidget"></script>
<span>List provided courtesy of
<a href="http://google-third-party-ads.blogsblogsblogs.com/"
target="_blank">blogsblogsblogs.com</a></span>

You can style the widget any way you want, since each of the main HTML elements generated has a unique id associated with it, and explained on this page. Hope this helps make following the new terms easier.