The other day I received an email from a webmaster whose site was blacklisted by Google. In Webmaster Tools, he found the following example of a malicious code detected on his site (domain changed):
<img src="http://example .net/images/logos/rssicon.png" />
So why did Google think this image tag was malicious? Can images be malicious? After all they are not scripts, iframes or embedded executable objects that that hackers use to attack web surfers.
It turns out, images can really make Google blacklist your site. In that particular case, the image was from a third party site and it was (as its name suggests) just an RSS icon. A normal legitimate file. The only problem was the third party site got hacked and attackers modified its .htaccess file to redirect search traffic to malicious sites (like here). Subsequently, that “example. net” got flagged by Google.
Sometimes it’s enough for your site just to load something from a blacklisted site to get a warning. For example, Google Chrome has so called “cross-site warnings“. When you open a website that is not currently blacklisted, Chrome can detect (in real time) that a page loads something (usually scripts or iframes) from a known blacklisted site. In this case you will see the infamous red malware warning. The only difference from a normal warning will be the words that “website at <your website> contains elements from the site <third party site>, which appears to host malware…“.
These cross-site warning only (reliably) work in Google Chrome. And since websites that contain elements from malicious site are not blacklisted at the moment, there will be no malware warnings in Webmaster Tools (until Google discovers malware on your site). So the webmaster couldn’t find that code in Webmaster Tools if that was just a cross-site warning.
Let’s get back to that hacked site. It’s .htaccess file also contained rules to redirect all erroneous requests (e.g. requests with error codes 404 Not Found, 400 Bad Request, 401 Unauthorized, 403 Forbidden and 500 Internal Server Error ) to malicious sites. In our case, that rssicon.png file was missing for some reason, thus requests to this file returned the 404 error code and got redirected to a bad site.
So every time when someone loads a page with that img tag, behind the scenes, one browser request goes to a malicious site. This is probably what Google malware scanners detected and this was the reason for flagging that website with the rssicon.png img tag.
Another real world example is the current problem with Blogger blogs that use some fishy “page views counter widget” from bloggerwidgets .cz .cc. Google says, this site has infected 169 blogs.
All infected site has the following “counter widget” code
<img src="http://forums .bit-tech .net/images-light/misc/stats.gif" alt="" width="16" height="16" />
<img src="hxxp://demo .bloggerwidgets .cz .cc/counter2.php?page=xxxxxxxxxxxxxxxxxxx&digit=4" alt="counter" />
As you can see, this code loads an image from demo .bloggerwidgets .cz .cc. I guess it is supposed to display views count. However, the “bloggerwidgets .cz .cc” domain seems to be discontinued and now redirects all requests to a scam site.
Can those images from hacked/redirecting sites be really dangerous for visitors to a site that embeds the images via an <img> tag? Well, I think such tags are “mostly harmless” ;) Modern browsers seem to correctly handle such redirections and simply don’t process server responses in unsupported formats (the malicious redirect returns some HTML code where an image is expected). But who knows, maybe some older browsers under certain conditions may misinterpret the scope of the redirection and navigate a browser to a bad site (after all this is what browser exploits are all about — they allow to do undocumented stuff).
Anyway, whats’ more important for webmasters is that image tags can really be the source of malware warnings.
So here are some basic tips on how to deal with such situations:
1. Where possible, don’t use images and other resources (e.g. scripts, objects, etc) from third-party sites. You might want to copy the files to your own server (if their license permits this).
2. If you have to embed resources from third party sites (counters, widgets, ads), check how trustworthy and reputable they are (e.g. compare Facebook widget and the “bloggerwidgets .cz .cc” widget).
3. If Google blacklists your site and mentions some <img> tag as the source of the problem, you should remove that tag (or replace the image with some placeholder with similar dimensions to preserve page formatting) from all pages and then request a malware review via Google Webmaster Tools.
4. In case you don’t see any samples of malicious code in Webmaster Tools (for example, if you haven’t registered your site with Webmaster Tools yet) you might want to check Google’s Safe Browsing diagnostic page for your site:
Just replace “example.com” with your site domain.
On the diagnostic page, check domains mentioned in the “What happened when Google visited this site?” section. If your site links to some images on those domains you need to remove them before requesting a malware review.
5. If you really want to use those images on your site, you should contact the owners of the sites they reside on and ask to clean them up and have Google unblock them. Once those third party websites are clean you can link to their images again.
Note, the above instructions only apply to situations when Google blacklists your site because of the <img> tags that you added to your site yourself. If you find some image tags or other HTML code that don’t belong to your site and you never added them yourself, this will be a whole different story that requires different remediation steps (for example, the most important step will be to figure out how that alien code was injected into your web pages.)