嗯，用户让我总结一下这篇文章的内容，控制在一百个字以内，而且不需要特定的开头。首先，我需要快速浏览文章，抓住主要点。 文章讲的是一个反欺诈团队分析了一个钓鱼工具包中的JavaScript文件ss1.js。这个脚本试图阻止Google安全浏览检查，但效果不佳。具体来说，它通过阻止网络请求和禁用预取机制来实现，但这些措施无法绕过浏览器级别的安全检查，因为浏览器的安全决策是在脚本运行之前完成的。此外，脚本还添加了严格的CSP，可能破坏合法资源。 总结的时候要涵盖：脚本的目的、使用的手段、为什么无效、以及对防御者的意义。同时要注意字数限制。 所以，最终的总结应该包括：ss1.js试图阻止Google安全浏览检查，通过阻止网络请求和禁用预取机制，但无效；因为它无法影响浏览器的安全决策；对防御者来说是检测指标。 </think> 这篇文章分析了一个名为ss1.js的JavaScript文件，该文件试图通过阻止Google安全浏览检查和禁用浏览器预取机制来绕过安全检测。然而，由于浏览器的安全决策在脚本运行前完成，该方法无法有效绕过安全检查。此外，脚本还添加了严格的CSP策略，可能破坏合法资源。 2026-2-11 13:30:38 Author: www.d3lab.net(查看原文) 阅读量:0 收藏
In February 2026, the D3Lab Anti‑Fraud Team analyzed a phishing kit that embedded a JavaScript file named ss1.js. The script, branded SafeBrowsingBlocker, attempts to prevent Google Safe Browsing checks by blocking network requests to Google Safe Browsing domains and disabling browser prefetching/prerendering mechanisms.
Our technical analysis shows that this approach is largely ineffective against browser‑level Safe Browsing interstitials, which are decided before any page JavaScript executes. The script’s primary effect is limited to blocking page‑initiated requests (e.g., fetch, XHR, sendBeacon) and adding a restrictive CSP that can break legitimate resources.
This post details how the script works, why it cannot bypass Safe Browsing, and provides IoCs for detection.
Context: Where the Script Is Loaded
The phishing page loads the script in the <head> and initializes it immediately:
<head>
<script src="381890/ss1.js"></script>
<script>
new SafeBrowsingBlocker({ verbose: false });
</script>
</head>
Technical Analysis
1) Blocking Safe Browsing Domains in fetch and XHR
The script overrides fetch and XMLHttpRequest.prototype.open to block a hardcoded list of Google Safe Browsing endpoints. A simplified excerpt:
const blockedDomains = [
'safebrowsing.googleapis.com',
'safebrowsing-cache.google.com',
'sb-ssl.google.com',
'sb.google.com',
'safebrowsing.google.com',
'update.googleapis.com/service/update2/crx',
];
const originalFetch = window.fetch;
window.fetch = function (...args) {
const url = typeof args[0] === 'string' ? args[0] : (args[0] && args[0].url) || '';
if (blockedDomains.some(d => url.includes(d))) {
return Promise.reject(new Error('Request blocked by SafeBrowsingBlocker'));
}
return originalFetch.apply(this, args);
};
const originalOpen = XMLHttpRequest.prototype.open;
XMLHttpRequest.prototype.open = function (...args) {
const url = args[1];
if (blockedDomains.some(d => url.includes(d))) {
throw new Error('Request blocked by SafeBrowsingBlocker');
}
return originalOpen.apply(this, args);
};
What this actually does: it blocks page‑level network requests to those domains. It does not affect the browser’s Safe Browsing decision process, which happens before the phishing page runs any JavaScript.
2) Disabling Prefetching/Prerendering
The script removes and blocks <link rel="prefetch|prerender|dns-prefetch|preconnect"> tags to reduce background network activity.
const prefetchLinks = document.querySelectorAll( 'link[rel="prefetch"], link[rel="prerender"], link[rel="dns-prefetch"], link[rel="preconnect"]' ); prefetchLinks.forEach(link => link.remove());
Why it’s ineffective for bypassing Safe Browsing: prefetching controls are not the mechanism used by Safe Browsing to show the red interstitial. The decision is made by the browser security stack before the DOM is even constructed.
3) Blocking navigator.sendBeacon
The script overrides navigator.sendBeacon to prevent background telemetry:
if (navigator.sendBeacon) {
navigator.sendBeacon = function (url, data) {
return false;
};
}
This can prevent some analytics from being sent, but it does not stop the browser’s threat checks.
4) Injecting a CSP via <meta>
The script adds a CSP meta tag that only allows self by default.
<meta http-equiv="Content-Security-Policy"
content="default-src 'self'; connect-src 'self'; ...">
This can actually break external resources in a phishing kit (e.g., CDN scripts, fonts). It also cannot override server‑sent CSP or browser‑level security decisions.
Why This Script Fails to Bypass Safe Browsing
Safe Browsing interstitials are triggered by browser‑level and service‑level checks that occur before the phishing page can execute any JavaScript. Blocking network requests from the page cannot retroactively alter that decision.
In short:
- Too late in the chain: the check happens before
ss1.jsruns. - Wrong layer: it only affects page JS, not browser security engines.
- Limited scope: it may block page‑initiated telemetry, but not Safe Browsing.
Indicators of Compromise (IoCs)
- Script name / path:
381890/ss1.js - Hash:
50b9d271cd021f47587f8b85570b30a544a23ebfcea8d9a81a930bedbf9f2b19 - Class name:
SafeBrowsingBlocker - Functionality string: “Safe Browsing Blocker – COMPLETE STANDALONE VERSION”
Open‑Source Visibility and Recency
Our team checked public scanners and found:
- Urlscan: only one scan result (our own), observed 9 Feb 2026.
- VirusTotal: no prior submissions.
This strongly suggests the script is very recent and has limited distribution at the time of analysis.
Final Assessment
The ss1.js “SafeBrowsingBlocker” is a clear example of security theater in phishing kits: it tries to block Safe Browsing by interfering with client‑side requests, but it is ineffective against the browser’s real‑time threat checks. Its main impact is disrupting page‑level telemetry and potentially breaking legitimate resources.
For defenders, the script remains a useful IoC and a behavioral indicator of phishing tooling that tries to evade analysis with superficial client‑side measures.
如有侵权请联系:admin#unsafe.sh