How to remove the "This site may harm your computer" warning from your website's listings in Google search results, step by step
- If you are looking for information about a similar but not identical warning from Internet Explorer, see Notes at the bottom of this page.
What is the warning?
Google
puts this warning flag in its search results for pages where its automated web crawler was attacked by viruses or
spyware when it visited the page. The purpose of the warning is to help protect web surfers who are using Google search results,
by steering them away from malicious pages. Yahoo also provides similar warnings on its result pages.
The warning is not a punishment or penalty, and it does not mean that Google, Yahoo, or StopBadware think you designed your site to be malicious. They all know that the overwhelming majority of webmasters do not create malicious pages on purpose and that you probably didn't, either. But they also don't want to send their customers to dangerous pages, and they do require you to do the necessary cleanup before they start referring visitors again.
You are probably wondering what happened to your site that got it flagged.
Why is your site flagged?
Here are reasons why your website can be flagged with the "This site may harm your computer" warning in Google search results:
- Your site was hacked.
This is the most common reason for the badware flag. If someone can trick your server into allowing them to modify files in your
site, they can insert malicious code into your web pages or database tables, or they can alter
your .htaccess or your HTML or JavaScript code so your
site automatically redirects visitors to a malicious site.
- A site other than yours got hacked, but it is affecting the content on your pages. Let's say your pages have normally harmless iframes or JavaScript
that are pulled into a visitor's browser
from the other website by using the property (in the HTML code) "src=http://othersite", or they use PHP
code that resides on another website but is included into your pages before being served, with a
PHP include(). If the other website gets hacked, your pages can turn dangerous, too, if the content that the other site was
supposed to be sending out (advertisements, hit counters, top 10 lists ...) gets replaced by viruses, spyware, or other bad things.
Whenever you use content from another website on your pages, you are dependent on that other site staying clean.
- Your pages trigger the loading of Flash .swf files that are scripted to do malicious
things or that are out of date and exploitable. Flash advertising is a common problem area.
- (Your site contains an outlink to another site that has badware on it.) This was once a major reason for being flagged. That might not be true anymore, but it is still worthwhile to check your outlinks to make sure you are not linking to malicious sites, or to a site that got hacked and has turned malicious.
StopBadware and Google describe the criteria they use to determine whether a website is contributing to the badware problem.
The Firefox 3+ and Chrome browsers use data from the Google Safe Browsing Service to warn users about suspected malicious sites. If your site is flagged in Google search results, Firefox 3 users are getting a warning that says, "Reported Attack Site!", and they are blocked from going there.
Why antivirus scanning might not find the bad code
The first idea that occurs to many webmasters is to do an AV scan on the site, but in many cases that will not find the problem. The next sections explain why.
A) Scanning your website files on the server
Scanning your server with an antivirus program will only work if the site is actually hosting the virus, which it often isn't.
More likely, the virus itself is hosted on another computer. Your pages have been injected with iframe or JavaScript code that refers indirectly (with src=) to the virus on the other website. Thus, the AV program on your server sees only iframes and JavaScript which don't trigger virus alerts because they aren't viruses.
The remote viruses aren't pulled in until the page is loaded into a visitor's browser. Then their browser fetches the code referred to by the src= property, and then they get a virus alert.
If you scan your site with an antivirus program and it finds no viruses, that does not mean the site is clean.
B) Downloading your site files to your PC and scanning them there
Using a tool like FTP, Wget, or cURL to download the source code of your pages to your local PC and AV-scanning them there is also unlikely to find the virus, for the same reason given above: the actual virus is probably not on the pages.
Wget in "recursive download" mode can retrieve all linked files, including ones from remote sites, but if some of them are viruses, you will be taking the unnecessary risk of downloading them directly to your PC.
C) Risky - browse your pages with an antivirus program running on your PC
If you are determined to use the facilities of an AV program to scan your site, you can browse the site as if you were an ordinary visitor. This is risky because an increasing number of viruses are "polymorphic". Their code changes so frequently (every day or every time they are served) that antivirus programs can't keep up, and they do a poor job of detecting them:
- Make sure your PC is fully patched with all the latest security updates. On a Windows PC, while logged into an account with Administrator privileges (it doesn't have to be your hidden Administrator account), go to Windows Update. (or IE7 > Tools > Windows Update).
- Make sure your antivirus software is up to date with the latest definitions. Do a manual update even if you normally get automatic ones.
- Set all your browser security settings to their highest levels, including turning JavaScript (or "active scripting") OFF.
- Go to each of your site's pages with your browser.
- Remember that if you are attacked by malware, the precautions you took in steps 1-3 are the only things protecting you. Otherwise, you are as vulnerable as any other visitor.
- If your AV pops up an alert, that's a good sign you've found the problem.
- If your AV doesn't pop up an alert, that doesn't mean the site is clean. As mentioned, AV programs might not detect these viruses. The viruses might be encrypted, and your AV might not detect them until they are decrypted, which requires JavaScript. But if you enable JavaScript, you might discover the virus by getting infected with it.
In summary, antivirus scanning is not definitive. If it finds a problem, that's useful. If it doesn't find a problem, it means nothing because the virus might be on a different website, or might be encrypted and polymorphic, or your website's problem might not be a virus at all. It might be a malicious redirect in the .htaccess file that selectively only occurs for users coming from search engine results, or it might be a bad outlink on one or more of your pages.
So the most thorough way to examine the site is to learn what to look for and then inspect your source files manually.
How to search your pages for malicious code
1) Discover which pages are flagged for malware and get clues about why they are flagged
- In any Google search box, enter: site:yoursite.com
- Note which pages have the warning flag. Usually, it's all of them, but sometimes it's only one section, such as the forum or
blog, which tells you where to focus most of your attention.
- Click the search results link for one of your flagged pages. Instead of going to your site, it will take you to a Google "interstitial"
warning page.
- On that page, follow the link to the "Safe Browsing diagnostic page" and study it. Another way to get
to the Safe Browsing diagnostic page directly (you can check any website this way) is by entering this URL into your browser address
bar. Replace EXAMPLE.COM with the address of the website you want to check:
http://www.google.com/safebrowsing/diagnostic?site=EXAMPLE.COM
Detailed instructions for how to understand the Google Safe Browsing Diagnostic report have been moved to a separate page.
- Go to Webmaster Tools at Google Webmaster Central. If you don't have an account there, create one.
It's free. They
show the badware status of your site, help information, and a partial list of the pages they consider suspicious.
- Look up your site in the
StopBadware Clearinghouse
database.
- If Symantec's Norton Safe Web has
found malware, their report shows the locations (filenames) of the threats more completely than the Google and StopBadware
reports.
- Scan pages of your website at
UnmaskParasites to find hidden iframes.
- Scan pages of your website at Dasient.
- Do a web search on each of the domain names and IP addresses mentioned in your Google Safe Browsing Diagnostic report as being the sources or intermediaries of the malware on your pages. Some of these website names and IP addresses are associated with specific types of attacks. For example, if the domains mentioned are gumblar or martuz, it is certain that a virus on the PC of one of your site administrators stole the FTP login information and used it to hack the site, so you must do virus scans. On the other hand, if the domain is beladen, you are facing a server-wide compromise, not just an ordinary attack on your one website, so you must notify your webhost. These domain names can give you good clues about what is wrong and save you a lot of time if your search is successful.
Now that you have preliminary information about which pages are affected and what seems to be wrong with them, you can start searching for bad code. Some of it might have been identified in steps 9 and 10 above.
2) Remember to search your source code for badware
Whenever possible, view and search the source code of your pages, on your server. This allows you to see ALL the code, even if it is only put on the pages sometimes.
Explanation:
Some exploits put malicious code on pages only under certain conditions such as if the visitor is using Internet Explorer or if they came to your site from a Yahoo or Google search results page. Your particular viewing might not meet those conditions (such as if you're using Firefox or you went directly to the site without going through a search engine). If you examine pages with your browser's View Source command, you can think the page is clean even though at other times, or when other people view it, it's not.
Examining the source code on your server lets you see all the code that's there.
3) Programs for searching pages for malicious code
3a) Search one page at a time (recommended)
- An FTP client program such as FireFTP. You can use Windows Explorer for FTP, if you really have to.
- cPanel (or Plesk) > File Manager
Starting with the most important flagged page (such as your home page), visually inspect the source code of each file for the types of malicious text described in Section 4 below.
Malicious code is often inserted into web page files by robots (programs) using very simple rules for where to put it. Common locations are:
- At the very top of the file.
- Just before or after the <body> or </body> tags.
- At the very bottom of the file, after the </html> tag.
If your pages normally validate at W3C, go there and check your badware-flagged pages. Any errors you get might point directly to where the bad code is.
3b) Multi-file searching
With multi-file searching, a program scans all files for the search string you specify, and reports all the instances it finds. This is an efficient way to search if you already know how to do it. Otherwise, this is probably not the best time to learn, and I'd recommend the one-page-at-a-time method, above.
Dedicated server
Do your search directly on the server with an operating system tool like grep.
Shared server
If you're already familiar with cron and grep, you can create a cron job to do the grep search as though you had shell (command line) access.
Otherwise, download the pages (or your entire site) to your PC so you can search them there. Download with:
- FTP. If you normally publish to your site with FTP, be sure when you reverse-publish back to your PC that you don't overwrite your local site! Copy the files to a different location.
- Wget. After a confusing search, I got my Windows XP version at http://www.christopherlewis.com/WGet/WGetFiles.htm.
- cURL.
After downloading the pages to your PC, you can do the searching with any program that supports searching multiple files. Some examples:
- FrontPage
- Expression Web
- Dreamweaver
- GREP or a similar utility
- A programming IDE such as Microsoft Visual C++ or Borland C++ Builder
- Windows Explorer (its search methods have peculiarities that make it a poor choice for these searches)
4) Search strings to find malicious code
These are useful search strings, whether you are searching one file at a time or all files at once:
| <iframe | Can quickly discover malicious links, which are often in iframes. |
| src= | Finds occurrences of iframes and JavaScript because they both use this property. The equals sign might be encoded as = or %3D or %3d. Searching for just src would find all of them. |
| http:// | Finds references to remote websites. |
| script language= | Finds occurrences of scripts. |
| unescape | A JavaScript function often found in malicious code. |
| eval | Another JavaScript function often found in malicious code. |
Make sure all instances of src= and http:// refer to files on your site or to external sites you know and trust.
Some common trusted sites that are not a problem are:
- pagead2.googlesyndication.com (if you use AdSense)
- www.google-analytics.com (Google Analytics). However, make sure it is not gooqle-analytics with the second G really being a Q. That is a spoof/malware site, and not ok. Other look-alikes of the google-analytics name are common, so check the spelling carefully.
4a) What do malicious or invisible iframes look like?
iframe code looks like this. If you don't recognize remotesite.com, the code is suspicious. This example combines two separate methods of making it an "invisible iframe", either one of which would work by itself: the width and height settings, or the style:
<iframe src="http://remotesite.com/path/file" width="0" height="0" frameborder="0" style="display:none"></iframe>
Whenever you find an iframe like this, do a web search on remotesite.com to find security-related websites, blogs, or forum posts that discuss it:
remotesite.com malware OR hacked
Be careful to avoid clicking any result that is the malicious website, or is a website that was infected by it! Some iframes are always associated with a particular type of exploit, so information about the one you found can save a lot of time discovering how your website got hacked. For example, iframes referencing gumblar.cn, martuz.cn, and a growing list of others are the result of FTP password theft from the webmaster's PC, so the security problem is on the PC, not the server.
4b) What do malicious JavaScript references look like?
JavaScript references to external sites look like this. If you don't recognize remotesite.com, the code is suspicious. This code calls and runs a JS script that is hosted on a website that isn't yours. After a visitor loads your page, their browser fetches this JavaScript from the other site and runs it:
<script language="JavaScript" src="http://remotesite.com/path/file.js"></script>
4c) What does malicious or obfuscated JavaScript code look like?
Malicious JavaScript code directly on your pages (rather than being called by reference as described above) is often "obfuscated", "obscured", "encoded" to make it hard to tell what it does. It looks like an undecipherable jumble, like this (this has been greatly shortened and mangled to make it nonfunctional). Code like this is always suspicious and must be investigated:
<script language="JavaScript">function nbsp() {var t,o,l,i,j;var s=''; s+='47116101120'; s+='097114099111'; s=s+'1203403211910'; s=s+'7121058110111112'; s=s+'9062032'; t='';l=s.length;i=0; while(i<(l-1)) {for(j=0;j<3;j++){t+=s.charAt(i);i++;} if((t-nescape(0xBF))>unscape(0x00)) t-=-(uescape(0x08)+unescae(0x30)); doc.rite(String.froCharCode(t));t='';}}nbsp(); </script>
Sometimes VBScript is used instead, so the code starts with:
<script language="VBScript">
If in doubt about whether a block of code is malicious, take a snippet of it and do a web search on it.
5) Which pages to search for malicious code
Search all the files that have any part in creating your web pages: .html, .htm, .php, .asp, .aspx, .inc (include files), .cfm, and whatever other extensions you use.
Inspect .js JavaScript and any other script files (including ones that you know originally came from a trusted source), watching for obfuscated code as described above. Some exploits try to do as little damage to the site as possible other than adding one little malicious JavaScript function into an otherwise normal .js file, to make it go undetected for as long as possible and be difficult to find.
If you find nothing in your text files, it might be necessary to search your database for malicious code, which is discussed in Section 12) below.
6) Search your pages for links to flagged sites
If your site can still be flagged for outlinking directly to another site that has badware on it (which, as mentioned earlier, I am not sure is still the case), only one-hop links count. If you link to a site that links to a site that has badware, that does not cause a flag.
Having a large number of outlinks makes you especially vulnerable. If you link to 1000 other sites, what are the chances that they all manage to stay clean all the time?
To investigate, make a list of all the sites you link to. For each one:
- In any Google search box, enter site:thatsite.com, or
- Look it up in the StopBadware Clearinghouse database
If any of the site's pages have the "This site may harm your computer" warning, you may be flagged for linking to them. Or they may be flagged for linking to you, if they do. There's no way to tell which it is. If you have a good relationship with the other site, tell them they've been flagged. They might not know about it.
7) Forum posts and blog comments
Examine the user-generated content on your site for malicious links that may have been posted by visitors or spambots. To be efficient, start with posts from a few days before the site first got flagged. Or start at the end and work backwards. For every link to another site, do a Google site: search to see if it's flagged. If it is, remove the link.
8) Advertisements that Google considers badware
If you run affiliate ads or ads from advertising networks, you usually put the ads on the page by inserting iframe links or JavaScript into the code of your pages. The ads are retrieved from the third party sites only when your page is loaded into a visitor's browser.
There are a few advertising networks that do things in their code that StopBadware and Google consider badware behavior. There are also ad networks that fail to properly screen the ads submitted by advertisers for distribution, so sometimes malicious ads get into their inventory. Make a list of the advertisers you are affiliated with. Do a web search on them or ask about them in a forum where there are people who might be up-to-date with which advertisers (if any) are currently problematic. An example of a web search that I have found useful is:
advertiser badware OR StopBadware OR malware OR virus
Bad ads can slip into even the big ad networks. DoubleClick clients got hit in 2007.
An increasing amount of advertising is being served in Flash .swf files. These files can be flagged as badware, too. See the next section.
9) Out-of-date, exploitable, malicious Shockwave Flash files
There have been numerous security vulnerabilities found in Flash. In addition, Flash scripting allows authors to embed badware behavior such as redirecting to a different website while the user is helpless to prevent it.
Whether your Flash files serve third-party advertising or merely your own content, they will get flagged if Google determines they have malicious scripting or are otherwise a hazard to a visitor's PC.
The easiest way to determine whether .swf files are the reason for your site being flagged is to remove the files as part of your initial site cleanup. After the badware flag is removed from your site, put the files back. If the flag returns, they're a problem. You can also try scanning your .swf files with the AdopsTools Online click checker, which gives you a report about the file's content.
These links might help you investigate further:
- InformationWeek explains (overview) why Flash can be dangerous
- How sleazy operators slipped malware Flash advertisements into an ad network
- List of Flash authoring tools with critical vulnerabilities; recommended solutions
Technical articles:
- Adobe article about creating more secure SWF web applications
- Adobe Flash CS3 Documentation on Flash Player Security aspects of Programming ActionScript 3.0.
While you are investigating and fixing your site, you might want to keep Flash disabled in your browser in case you have a bad .swf file.
In Internet Explorer, go to Tools > Manage Add-ons > Enable or Disable Add-ons > Add-ons that have been used by Internet Explorer. Disable two items: 1) Shockwave Flash Object and 2) Shockwave ActiveX Control (if present).
For Firefox, there is a highly recommended plug-in called NoScript to block Flash, JavaScript, Java, and more.
10) Advertisements from otherwise legitimate ad networks that have been hacked and are now serving badware
Even if your advertisers normally use only legitimate methods, their ads might have been replaced with malicious code, which would start appearing on your pages instead of the usual ads.
This is a danger anytime your pages pull some of their content from other sites.
This is one case where the only way to detect the malicious code is to visit your site pages with your browser, to make sure all the ads are the legitimate ones you expect. If you are affected by the problems an advertising network is having, you won't be the only one, so a web search should turn up other similar reports.
11) Other third party content
If you use any code that includes content from a remote site, such as
- iframes or JavaScript with a property of "src=http://othersite.com", or
- PHP scripts that use include("http://othersite.com/file.php"), or the related include_once(), require(), and require_once(),
there is always the danger that a problem at the other site could affect your pages.
12) Database content from your CMS.
If content for your site pages is stored in a Content Management System (CMS) database, it is possible that an SQL injection attack inserted malicious code into the database tables, and it is getting into your pages from there.
One way to search or visually inspect and clean the data in your database tables is with cPanel > phpMyAdmin.
Another way that should sometimes be workable is to go to cPanel > Backups and download a backup of the database in sql.gz format which is a plain text file when it's decompressed. If your antivirus software allows you to keep the downloaded file (it might detect the malware and quarantine the file instantly), and if the database isn't huge, you can view the text in a text editor, search and replace the malicious code, and upload the cleaned database back to the server.
The easiest way to clean the database is to restore it from a known-good backup.
13) Rewrites or redirects in your .htaccess file(s)
Examine your site configuration files such as Apache .htaccess and httpd.conf for code that sends your visitors to a malicious site. Look for lines containing the words Rewrite or Redirect with references to sites that aren't yours, and RewriteRule lines referring to google.com or yahoo.com. htaccess exploits often redirect only if the visitor came from a search engine. If your visitors report being redirected and you can't reproduce the behavior yourself, try going to your site from a Google search result.
In your existing .htaccess files, search carefully and scroll all the way to the bottom of the file. Sometimes hundreds of blank lines are inserted before the malicious code.
Look for new .htaccess files that might have been added to the site. Search all the folders inside /public_html and also the folder(s) above /public_html.
14) JavaScript redirects
JavaScript is another way your page can automatically redirect visitors to a different website. While examining the JavaScript in your site, look for code like the following. It can be in the JavaScript code in your pages, or, increasingly common, injected into your .js files that are called by your pages:
window.location="http://unknownsite.com/"
window.location.replace("http://unknownsite.com/")
15) Meta-refresh redirects
An HTML meta-refresh is yet another way to automatically redirect visitors to a different website. Look for code like this within the <head></head> sections of your documents:
<meta http-equiv="refresh" content="0;
url=http://unknownsite.com/">
<meta http-equiv="location" content="0;url=http://unknownsite.com/">
These examples redirect to the other page after 0 seconds.
16) Check your error pages
If you have custom error pages that you created and that are stored within your website, you probably examined those files already in the previous steps.
However, many websites don't have custom error documents. In that case, the server uses its default error documents which are stored outside your website. You can test those by provoking a server error and checking the page you receive:
- Make sure your antivirus program is up to date.
- Turn off JavaScript so your browser won't execute any scripts.
- Using your browser, go to: http://yoursite.com/notarealpage.html
- You should get a "404 Not Found" error page.
- View its source code in your browser:
IE7: Page > View Source
FF : View > Page Source - Look for the same types of injected links and virus code that you searched for on your other pages earlier.
If you find bad links or viruses on your server's default error pages, it is a sign that the server, not just your website, has been compromised. Continue to the next step, and notify your webhosting company.
17) Server has a rootkit installed
A rootkit is a type of infection that installs malicious programs to partially replace the server's operating system. It performs ordinary operating system tasks just like the OS would, but it also performs whatever malicious activity it is programmed to do. Because it controls operating system tasks, it can hide itself. A server compromised with a rootkit-type infection cannot be trusted at all, not even to properly report on its own status or give accurate directory listings.
If you have thoroughly investigated all the preceding possibilities and you are sure everything inside your site is clean, it is possible that areas of your server outside your website are compromised (such as the default error pages in the previous step), or the server itself might be infected with software such as a rootkit. It might be injecting malicious content onto your pages in real time, after the pages are read from disk and just before they are sent out.
One possible indication of a compromised server is a situation where, even though your request wasn't redirected to some other malicious website (that is, you are getting a page from your site), the page you get in your browser is completely different -- every time, or just sometimes -- from the one that you know is on your server. For example, the page on your server is completely clean, but when you request it with your browser or with wget, it's nothing but a page full of JavaScript, or a page with an iframe in it. One type of attack that works this way is called beladen.
The behavior described above is not proof of a compromised server, however. For example, it is possible for the hacker to put new pages -- or even an entire website -- inside your website and then use .htaccess rewrites or PHP code to serve those pages instead of the requested ones. In this case, the pages are actually in your site and there is no server-wide compromise. With any luck, the investigation you've done to this point would already have uncovered either the hidden files or the rewrite code that is causing them to be served.
If you truly believe your server is compromised and you're on shared hosting, there is nothing you can do to repair the damage to the server. File a support ticket with your webhost and ask them to investigate. While you wait, you can:
- Identify other sites hosted on your server (your neighbors):
- Do a web search on "reverse ip", and choose a lookup provider. Some are free.
- Do a Google site: search on your neighbors to see if they are flagged.
- If several are flagged, it's evidence of a server-wide problem, and it might help convince your host of the need to
investigate.
- Examine your site files. This time, search not for injected malicious code, but for security vulnerabilities in your code. Also research lists of known vulnerabilities in the third-party applications you use. Even if your entire server is compromised, there is always the possibility that a security hole in your site was what allowed it to happen. It would not necessarily modify the files inside your site. So, since you can't do much else, use the time to check your site for security holes before it goes live again on a freshly cleaned server.
If you run a dedicated server, reformat the hard drive, reinstall and configure the operating system and server software, reinstall your site from known-good backups, --> fix the security vulnerability that allowed the compromise to occur <--, and start fresh.
Server-wide compromises used to be rare. In 2009, with exploits such as beladen, the incidence is increasing. It is still almost the last thing you should suspect, but it's not as unlikely as it used to be.
You might find the following articles useful if you suspect a server-wide compromise. The attacks discussed were from 2008, but their methods may have evolved into the more widespread attacks being seen today:
- cpanel.net information about the "Random JavaScript Toolkit".
- Discussion at cpanel.net forum about server diagnostics, possible repair methods. The Random JS Toolkit was not specific to cPanel, but cPanel discussed it the most. Registration (free) is required to read their forum. Register with the screen name you actually want (not your real full name). Unlike some forums, you cannot specify a different screen name after you join, nor change the one you joined with.
- Similar forum thread.
18) DNS cache poisoning
People think of website addresses as text like http://website.com, but web addresses are really numbers called IP addresses. Before a browser can fetch a web page from a site, it must first send a query to a DNS Server to get the site's correct numeric address.
Occasionally, someone manages to inject bad data into a DNS server so the IP address translations it returns are wrong. If someone tries to visit your website but their browser gets your IP address from a poisoned DNS server, they will be sent to a completely wrong website. That site might have malicious content, which could cause your site to be flagged for badware.
When investigating your badware flag, this is a "way-out-there" scenario, rare and unlikely, but it has happened, so it's included here for completeness.
19) Ask for help
If the reason your site is flagged remains a mystery, feel free to post a message in our forum.
20) Request a review from Google or StopBadware
After you have found and resolved all the likely reasons your site got flagged, file a request for review in the Webmaster Tools section of Google Webmaster Central, or on the StopBadware Request for Review form. If they find that the badware or badware links are gone, the warning flag is usually removed within 1 to a few days, even though their submission form says to allow longer.
If you changed nothing on your site, but only submit the review request, the flag will not be removed. Google's accuracy at identifying malware is nearly 100%.
Other resources
- StopBadware Tips for Cleaning & Securing Your Website has information about additional aspects of badware. It is in some areas more detailed, and in others less, than what I have presented here.
- If it turns out your site was hacked, see the step-by-step guide how to repair a hacked website and the several other articles that it links to.
- The malicious code (if any) that you find on your pages might not look very
threatening at first glance, often because what you see is only a reference to additional code hosted on another website, but it
can be very
dangerous. To get an idea what the current crop of badware is like, see
MPack Analysis (Overview of MPack and Russian Business Network),
Massive MPACK Compromise (follow all 4 links at the bottom of that page, which provide additional detail about MPack and its effects),
New JavaScript that evades antivirus detection. If your site is serving this code, your visitors' antivirus software (assuming they have any, which many do not) might not be able to protect them.
Keeping badware off your site
The most important ways to keep badware off your site are
- Avoid getting hacked.
- Use a CAPTCHA to prevent robots from posting spam comments. A CAPTCHA is an image that humans can read, but robots can't. Some forum (and other) software has this feature in it already, and all you have to do is enable it.
- Monitor forum posts and blog comments so you can catch and remove links to malicious sites.
- Keep to a minimum the amount of content served to your pages by outside (third party) websites.
- Use only trusted advertising networks. If a network has been identified as the cause for badware flags, avoid it until you are sure the problem is resolved.
- If a site has an obviously careless attitude toward security, don't link to it. Clues would be outdated versions of forum and blog software, spam posts that haven't been removed, and areas where anyone can upload content for others to download.
- Keep the number of outlinks down to the number you are willing to check manually. The more outlinks you have, the more likely you will get badware-flagged. If you get flagged, you might have to check them all or remove them.
Comments, questions, and discussion welcome in the Forum.
In case you're wondering, no this site has never been flagged. I have helped numerous webmasters get the warning removed, both in discussion forums and for hire.
Notes
- Many people find this page while searching for information about a popup, claiming to be from IE7, that
says: "Internet Explorer Warning - visiting this web site may harm your computer".
Although the message is similar to the one from Google discussed in the article above, it is not related. It is also not
from IE7. It is a popup generated by malware that is trying to infect your computer. Do not visit any website that it
tries to make you visit, and do not download or run any program
that it tries to "recommend". There is a bit more information
in my article about high security in
IE7.
Also do a web search on rogue antivirus to find useful information and possibly screenshots that match the ones
you are seeing, to help you identify it. I've recently learned that this page you are reading now is one of the ones these
fake antivirus programs try to prevent you from visiting.
- Thank you for linking to this page. Its address is:
http://25yearsofprogramming.com/blog/20071223.htm
