How To Remove - This Site May Harm Your Computer - From Google Search Results

How to remove "This site may harm your computer" from Google search r...
http://25yearsofprogramming.com/blog/20071223.htm
An open source source for C, C++, OWL, BASIC, MDB, XLS, DOT, and more...
Home Projects Sitemap Search Blog Forum+Chat About Us Privacy Terms of Use Feedback FAQ Images Services Payments Humor Music
If you are looking for information about a similar but not identical warning from Internet Explorer, see Notes at the bottom of this page.
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 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. However, they don't want to send their customers to dangerous pages, so they require that your site be cleaned before they will start referring people to it again.
Here are reasons why your website can be flagged with the "This site may harm your computer" warning in Google search results: 1. Your site was hacked. This is by far the most common reason. 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
1 of 16
10/2/2012 5:11 PM
.htaccess or your HTML or JavaScript code so your site automatically redirects visitors to a malicious site. 2. 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 to your pages (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. 3. Your pages trigger the loading of Flash .swf files that are scripted to do malicious things. Flash advertising is a common problem area. StopBadware provides a description of what they consider to be malicious website behavior. The Firefox 3+ and Chrome browsers use data from the Google Safe Browsing Service to warn users about suspected malicious sites. When your site is flagged in Google search results, Firefox users receive a warning that says, "Reported Attack Site!", and they are blocked from going there. Internet Explorer does not use the Google service. It uses a Microsoft database. If Firefox gives a warning but Internet Explorer does not, it does not mean that the site is safe in either browser. It just means there is different data in the two databases. The Google database is nearly 100% accurate. If Google says your site has become harmful, it is safest to assume they are correct. False positives are rare.
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
2 of 16
10/2/2012 5:11 PM
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: 1. 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). 2. Make sure your antivirus software is up to date with the latest definitions. Do a manual update even if you normally get automatic ones. 3. Set all your browser security settings to their highest levels, including turning JavaScript (or "active scripting") OFF. 4. Go to each of your site's pages with your browser. 5. 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. 6. If your AV pops up an alert, that's a good sign you've found the problem. 7. 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 or polymorphic, or your website's problem might not be a virus at all. It might be a malicious redirect in the .htaccess file that only occurs for users coming from search engine results.
3 of 16
10/2/2012 5:11 PM
So the most thorough way to examine the site is to learn what to look for and then inspect your source files manually.
1. In any Google search box, enter: site:yoursite.com 2. 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. 3. 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. 4. 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 If needed, here is a detailed guide for understanding the diagnostic page. 5. 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. The "fetch as Googlebot" feature allows you to test whether your site is "cloaking" malicious content (serving different content to Googlebot than it does to everybody else). 6. Look up your site in the StopBadware Clearinghouse database. 7. 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. 8. Scan pages of your website at Unmask Parasites to find hidden iframes and other content that comes to your pages from external sites. To see for yourself the iframes or other malicious content in your source code, without possibly exposing yourself to viruses by first requesting the page with your browser, you can use the source code viewer at Web-Sniffer, or at Redleg's File Viewer which usefully
4 of 16
10/2/2012 5:11 PM
highlights iframes and other potentially malicious code. 9. After you've determined some of the text strings, such as malicious domain names, that you need to find in your website files, this PHP script can be customized to help find them. 10. 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 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 already in the steps above.
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.
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.
5 of 16
10/2/2012 5:11 PM
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 reversepublish 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. At 2011-09-19, that site appears to be undergoing remodeling, and WGet appears to be part of the GnuWin32 project: http://gnuwin32.sourceforge.net/packages/wget.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)
6 of 16
10/2/2012 5:11 PM
These are useful search strings, whether you are searching one file at a time or all files at once: <iframe src= http:// unescape eval Can quickly discover malicious links, which are often in iframes. 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. Finds references to remote websites. A JavaScript function often found in malicious code. Another JavaScript function often found in malicious code.
script language= Finds occurrences of scripts.
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?
7 of 16
10/2/2012 5:11 PM
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+='09711409-9111'; s=s+'120340321-1910'; s=s+'71210581101-11112'; 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.
Search all the files that have any part in your web pages: .html, .htm, .php, .asp, .aspx, .inc (include files), .cfm, .css (style sheets). Inspect .js JavaScript and any other script files (including ones that you know originally came from a trusted source such as an Ajax library), 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 will be discussed later.
Examine user-generated content on your site for malicious uploads or attachments 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.
8 of 16
10/2/2012 5:11 PM
If you run affiliate ads or ads from advertising networks, you usually put the ads on the page by adding iframe or JavaScript code into the source code of your pages. Your visitor's browser fetches the ads directly from the advertiser site as part of the process of displaying your web page. There are a few advertising networks that intentionally do things in their code that StopBadware and Google consider badware behavior. Other ad networks fail (either consistently or accidentally) to fully screen the ads submitted by advertisers for distribution, so sometimes malicious ads get into their network. Make a list of the advertisers you are affiliated with. To find out if other publishers are experiencing the same problem as you with this network, 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 are currently causing problems. An example of a web search I have found useful is: advertiser badware OR StopBadware OR malware OR virus Bad ads can slip into even the big ad networks such as DoubleClick and MSN. When this happens at the biggest networks, it is usually resolved quickly. If you suspect bad ads might be your problem, the solution is to stop displaying the ads on your pages until the ad network problem is resolved. Report the problem to the network with as much detail as you can provide. An increasing amount of advertising is being served in Flash .swf files. These files can be flagged as badware, too. See the next section.
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:
9 of 16
10/2/2012 5:11 PM
InformationWeek explains (overview) why Flash can be dangerous How sleazy operators slipped malware Flash advertisements into an ad network 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.
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.
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.
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.
10 of 16
10/2/2012 5:11 PM
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. If you suspect SQL Injection, you can use the online hack attempt identifier to determine whether your site has been receiving attacks of that type. If you write your own database connection and query code, it is possible to prevent SQL Injection.
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. You can test for, confirm, and study redirects as they happen with the Firefox add-on Live HTTP Headers.
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/")
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
11 of 16
10/2/2012 5:11 PM
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.
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: 1. 2. 3. 4. 5. 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 6. 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.
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,
12 of 16
10/2/2012 5:11 PM
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: 1. Identify other sites hosted on your server (your neighbors): a. Do a web search on "reverse ip", and choose a lookup provider. Some are free. b. Do a Google site: search on your neighbors to see if they are flagged. c. If several are flagged, it's evidence of a server-wide problem, and it might help convince your host of the need to investigate. 2. 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.
13 of 16
10/2/2012 5:11 PM
Similar forum thread.
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.
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 malicious behavior is 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. If you did nothing but delete the pages that were flagged, the flag will not be removed. The flag is removed after Google finds that the previously infected pages are still there, and clean.
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), JavaScript that evades antivirus detection. If your site is serving this code, your
14 of 16
10/2/2012 5:11 PM
visitors' antivirus software (assuming they have any, which many do not) might not be able to protect them.
The most important ways to keep badware off your site are 1. Avoid getting hacked. 2. Keep to a minimum the amount of content served to your pages by outside (third party) websites. 3. 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.
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.
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 letting others know about this page by linking to it. Its address is: http://25yearsofprogramming.com/blog/20071223.htm
Ads by Google
Virus Scan
Google Web Hosting
Google Browser
Anti Virus
Search the web
Search this site
15 of 16
10/2/2012 5:11 PM
Copyright 2012 Steven Whitney. Last modified Sun 07/29/2012 10:53:28 -0700.
16 of 16
10/2/2012 5:11 PM

How To Remove - This Site May Harm Your Computer - From Google Search Results

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

How To Remove - This Site May Harm Your Computer - From Google Search Results

Uploaded by

Copyright:

Available Formats

How to remove "This site may harm your computer" from Google search r...

A) Scanning your website files on the server

B) Downloading your site files to your PC and scanning them there

C) Risky - browse your pages with an antivirus program running on your PC

3a) Search one page at a time (recommended)

3b) Multi-file searching

script language= Finds occurrences of scripts.

4a) What do malicious or invisible iframes look like?

4b) What do malicious JavaScript references look like?

4c) What does malicious or obfuscated JavaScript code look like?

Similar forum thread.

Google Web Hosting

Search the web

Search this site

You might also like