当你每天都与代码打交道时，很容易只关注如何让代码“运行起来”，而忽略一些关键因素： 当你的应用程序开始与你无法控制的代码通信时会发生什么？第三方脚本、外部库、广告、分析小部件、供应商集成……所有这些都为开发者提供了便利，但也为一些最危险、最难检测的攻击打开了方便之门。
一旦你允许外部脚本在你的浏览器或系统上运行，你就把极大的信任寄托在了你没有编写的代码上。而攻击者深知这一点。 恶意脚本和“无文件”攻击已成为首选攻击途径之一。 攻击者可以窃取数据、将恶意软件加载到内存中，或以极少的磁盘痕迹或“可疑”附件渗透您的基础架构。如果您希望您的应用程序和系统不仅仅是易受攻击的目标，那么透彻了解这些风险至关重要。
外部脚本究竟是什么（以及为什么它如此敏感）？
本质上，脚本是 另一程序解释执行的代码片段例如浏览器、PowerShell 解释器、VBScript 引擎、Python 解释器等等。与编译后的可执行文件不同，脚本通常是纯文本（尽管很多时候……） 乌斯卡多 （有意识地），并且由系统中已有的解释器即时执行。
当我们在安全语境中谈论外部脚本时，我们主要指的是两种情况： 来自网络的代码 （JavaScript、嵌入PDF的脚本、Office宏、HTA等） 在系统本身上运行的脚本代码 （PowerShell、bash、VBScript、Python 等）由用户、其他程序或通过漏洞利用驱动。
这些剧本的妙处（也是问题所在）在于： 他们依赖的是完全合法的工具。您的浏览器需要运行 JavaScript；Windows 系统内置 PowerShell 和 WMI；许多公司使用脚本实现管理自动化。攻击者只需渗透到这个工作流程中，就能重用您使用的相同功能，但其目的却远非如此高尚。
合法网站遭到入侵：问题的最阴险一面
当今最危险的攻击手段之一是使用…… 恶意脚本嵌入到完全合法的网站中 用户的安全受到威胁。用户访问自己喜爱的媒体网站、银行网站或新闻网站时，在并非自身过错的情况下，浏览器接收并执行了第三方注入的代码。
这段代码通常会 含糊不清且伪装得很好 在合法库、广告或第三方插件之间。在许多情况下，它是……的一部分 漏洞攻击包 （Neutrino、Angler 等，以及其他更现代的工具）能够自动检测浏览器、插件（Flash、Java、PDF）甚至操作系统和辅助应用程序中的漏洞。
当出现特定安全漏洞和权限组合时，脚本会下载并执行一个 有效载荷勒索软件、木马、僵尸网络、加密货币挖矿程序，或者攻击者感兴趣的任何其他恶意软件。所有这些都可能发生。 用户没有点击任何特别不寻常的东西不仅仅是加载带有横幅广告或恶意脚本的页面。
恶意广告：广告如同特洛伊木马
的运动 恶意广告 它们是外部脚本滥用的一个相当明显的例子。攻击者不需要直接入侵大型网站：只需…… 在广告网络中植入恶意广告 该网站使用了恶意软件。这些广告包含脚本，会将用户重定向到带有漏洞利用工具包的页面，或直接在浏览器中执行代码。
在一些国际顶级城市也出现过类似案例。 注入的广告会执行诸如 Angler 或 Neutrino 之类的漏洞利用工具包。在某些情况下，攻击者只需点击一下横幅广告即可控制设备，尤其是在用户使用旧版本插件或浏览器本身浏览网页时。
这里的问题在于传递信任：主站点委托给 第三方脚本和内容 （广告网络、分析提供商、社交插件）与页面其他部分加载在相同的安全上下文中。如果其中任何一个链接失效，攻击者就可以注入任何他们想要的代码，并获得与合法代码相同的权限。
客户端脚本：威力与攻击面
客户端编程——JavaScript、TypeScript、HTML5、CSS 和其他 Web 语言——是现代 Web 的引擎。正因为有了它，我们才能拥有…… 动态表单、单页应用程序 (SPA)、交互式地图、实时仪表盘等。 但这种强大的功能也伴随着一个缺点：该代码在每个用户的浏览器中运行，完全可见且可修改。
这意味着任何客户端脚本都是 攻击者的直接目标。你可以检查它、逆向工程它、在运行时操纵它、拦截 API 调用，甚至可以通过利用 XSS、CSRF 漏洞或 CORS 和 CSP 的糟糕实现来注入你自己的代码。
不安全的客户端脚本通常会导致以下问题： 跨站点脚本（XSS）跨站请求伪造（CSRF）、前端令牌和敏感数据泄露 通过 DOM 进行代码注入 以及从浏览器控制台直接操作应用程序状态。
XSS：当你的前端反过来攻击你时
跨站脚本攻击仍然是网络漏洞之首。其原理很简单： 攻击者使应用程序向其他用户传递由他控制的脚本。该脚本在受害者的浏览器中运行，并拥有与合法网站代码相同的权限。
典型的向量包括评论字段、用户个人资料、URL 中的参数，或应用程序的任何数据。 未经清理和未正确编码的反射如果将该输出直接插入到 HTML 中——或者更糟糕的是，将其插入到类似这样的属性中 onclick 或 innerHTML “攻击者可以偷偷植入一个标签。” <script> 或者更复杂的有效载荷。
有了XSS漏洞，攻击者可以 窃取 cookie 和会话令牌模拟用户操作，部署模仿您界面的网络钓鱼表单，修改用户看到的内容，甚至如果受影响的用户是管理员，还可以发起连锁攻击来攻击后端。
Office 文档、PDF 和其他文档中的脚本
外部脚本并非只能通过浏览器访问。攻击者多年来一直在利用这一点。 Office 文档、PDF 和其他看似无害的格式中的宏和脚本机制带有“必须打开”附件的电子邮件仍然是一种非常有利可图的营销机会。
对于 Office 来说，传统方法是使用包含混淆 VBA 宏的文档，并且也存在与此相关的风险。 办公脚本该宏在用户启用活动内容时运行，通常会调用 PowerShell 脚本、WScript、HTA 或其他系统组件 将恶意代码下载并加载到内存中。许多勒索软件家族都是通过这种方式入侵系统的。
另一方面，PDF 文件可以包含 嵌入式 JavaScript 某些读取器会执行此操作。如果读取器或浏览器插件存在漏洞，此脚本可以利用这些漏洞执行代码。同样，无需 .exe 文件；所有操作均通过已安装组件中的脚本和漏洞利用程序完成。
PowerShell、bash 等：无需访问磁盘即可在系统上运行脚本
在系统环境中，PowerShell、VBScript、bash、Python 或 Perl 等语言都是极其强大的管理工具。正因如此， 高级威胁组织和无文件恶意软件都喜欢它们他们不会投放可执行文件，而是直接注入或下载一个完全在内存中运行的脚本。
PowerShell 就是一个典型的例子。它不仅每天都被用于自动化 IT 任务，还被用于…… 将恶意DLL加载到内存中、提取凭据、在网络中横向移动或与加密的C2服务器通信所有这些都仅使用标准、通常经过混淆处理的函数来实现，并且不会在磁盘上留下任何传统杀毒软件可以识别的明显恶意软件。
这同样适用于 Linux 环境下的 bash 或 Python 脚本，以及 macOS 上的 AppleScript。从论坛复制的简单命令，或者从不可靠的代码库下载的脚本，都可能在你的系统上运行。 远比表面看起来要多得多从打开后车门到修改关键设置。
无文件攻击和规避传统杀毒软件
攻击者的一个关键优势在于，这些脚本允许他们发起攻击。 几乎无需向磁盘写入任何内容漏洞利用程序通过网络、电子邮件或远程桌面协议 (RDP) 传播，执行 PowerShell 或 JavaScript 命令，将额外代码直接下载到内存中，并将其注入到合法进程中，仅此而已。重启后，大部分痕迹都会消失。
根据近年来的研究， 目前观察到的攻击中，高达 40% 是“无文件”攻击或严重依赖脚本的攻击。恶意载荷驻留在内存中，使用由 Microsoft 或其他供应商签名的进程，并依赖于 mshta.exe、wscript.exe、powershell.exe、rundll32.exe 等合法工具。
在这种情况下，几乎完全依赖于以下因素的产品 磁盘上文件的签名 他们处于劣势；值得回顾一下诸如以下方面的比较： Windows Defender 安全性比较 了解局限性和替代方案。检测则依赖于启发式技术和行为分析：可疑的命令字符串、使用混淆参数调用解释器、异常的网络连接、使用敏感API等等。
权限过高和配置不当：恶意脚本的最佳帮手
经常被低估的一个方面是……的影响 拥有过多权限的账户在许多 Windows 环境中，大多数用户仍然以本地管理员身份工作，或者用户帐户控制 (UAC) 的级别设置得非常低。如果恶意脚本以这些凭据运行，它就可以随意安装驱动程序、服务、修改注册表或禁用安全控制。
像这样简单 将UAC配置为中/高级，并使用不具备管理员权限的帐户。 对于日常任务而言，这将大幅降低许多脚本的影响。即使脚本运行，如果它无法轻易提升权限，其造成的危害也会大大降低。
这同样适用于服务器、容器和云环境：运行诸如此类的服务 root在不恰当的情况下授予写入权限，或者在不同环境之间共享密钥和令牌，会引发巨大的安全隐患。 任何被篡改的脚本都可能成为攻击目标。 远远超出了最初的预期范围。
在系统上使用外部脚本的主要危险
当您的应用程序或基础架构依赖于外部脚本时，以上所有内容都会转化为一系列非常具体的风险：
- 任意代码执行（RCE）： 攻击者可以通过 XSS、宏、PowerShell 脚本、HTA 或阅读器和浏览器中的漏洞利用，以用户甚至系统的权限执行命令。
- 数据和凭证盗窃： 浏览器中的脚本可以读取 cookie， 本地存储 以及 API 响应；系统脚本可以收集密码、令牌、API 密钥、敏感文件，并将它们传输到远程服务器。为了检查帐户泄露，建议…… 检查您的账户是否已被泄露。 出于怀疑。
- 会话和身份劫持： 精心设计的 XSS 攻击或被攻破的第三方脚本可以窃取会话令牌、JWT 和 cookie。 未受保护 甚至可以拦截虚假表单中的凭证。
- 横向移动和持续性： 一旦进入系统，管理脚本（PowerShell、WMI、bash）允许您探索网络、传播到其他计算机、安装后门并保持持久访问权限。请参阅相关指南。 持续威胁管理 有助于缓解这些情况。
- 加密货币挖矿和资源滥用： 网站上的恶意脚本或注入的扩展程序可以在未经您同意的情况下使用您用户或服务器的 CPU 和 GPU 进行挖矿，从而降低性能并缩短设备的使用寿命。
- 网站篡改和内容篡改： XSS、被篡改的插件或修改过的外部脚本可以改变用户看到的内容，在您自己的网站上插入广告、钓鱼或欺诈内容。
- 规避管制和复杂的法证分析： 由于脚本攻击在内存中运行并使用合法工具，因此在磁盘和日志中留下的清晰痕迹较少，这使得它们更难被检测和分析。
使用外部脚本安全操作的最佳实践
这并非要妖魔化所有外部脚本，因为现实情况是…… 大多数现代应用程序都依赖于它们。目标是最大限度地减少隐性信任，并在所有关键点实施合理的控制措施。
1. 加强前端安全并控制执行的操作
在客户端，目标是最大限度地减少恶意脚本（无论是您自己的脚本还是第三方脚本）可能造成的损害：
- 对客户端和服务器上的输入进行验证和消毒。 客户端过滤可以提升用户体验，但真正的安全保障在于服务器端。即便如此，尽可能进行过滤仍然有助于缓解许多简单的跨站脚本攻击和注入攻击。
- 转义并始终对输出进行编码。 您在 HTML 中显示的任何用户数据都必须正确转义。避免通过以下方式构建 HTML：
innerHTML使用原始字符串。 - 避免使用在线脚本。 请勿将 JavaScript 代码直接放入 HTML 属性或代码块中。
<script>尽可能使用嵌入式文件。使用外部文件可以更好地利用更严格的内容安全策略。 - 实施一个合理的CSP。 制定内容安全策略，限制脚本的上传来源，并禁止以下行为：
eval并阻止inline-script除非确有必要。 - 使用带有 HttpOnly 和 SameSite 的安全 cookie。 对于会话，请将 cookie 标记为
Secure,HttpOnlyySameSite=LaxoStrict保护它们免受 XSS 和 CSRF 攻击。 - 应用安全标头。 HSTS、X-Content-Type-Options、X-Frame-Options 和类似工具可以帮助关闭许多基于脚本的攻击所利用的漏洞。
2. 加强客户端脚本管理
除了应用程序的逻辑之外，还必须监控前端依赖项：
- 尽量减少第三方脚本的数量。 每增加一个组件、CDN 或 SDK，就意味着增加了一个新的攻击面。只有在真正必要的情况下才加载它们。
- 设置版本并使用子资源完整性（SRI）。 从 CDN 加载脚本时，请使用属性
integrityycrossorigin确保内容未被篡改。 - 保持库和框架的更新。 许多 XSS 和类似漏洞在 React、Angular、Vue、jQuery 等的较新版本中都已修复。坚持使用旧版本会使已知的漏洞暴露在外。
- 定期检查您的扩展程序和插件。 在企业浏览器和服务器（CMS 插件）中，它会删除所有非必要的内容，并监控安全警报。
3. 确保在系统中使用脚本（PowerShell、bash 等）。
在操作系统领域，关键在于…… 应用最小权限原则并监控行为:
- 它限制了谁可以执行什么操作。 根据用户需求进行分类：每日需要脚本的用户、偶尔需要脚本的用户以及从不需要脚本的用户。屏蔽不需要翻译的个人资料上的不必要翻译人员。
- 限制 PowerShell 和其他解释器。 使用执行策略、AppLocker 或等效替代方案，仅允许已签名的脚本或位于受控路径中的脚本。
- 默认情况下禁用宏。 它们应该只对需要使用它们的用户和文档启用，并且最好进行数字签名。
- 除非绝对必要，否则不要使用管理员帐户。 使用标准帐户执行日常任务，并将特权凭据保留用于特定的、受控的任务。
- 监控可疑指令。 使用 Base64 字符串的 PowerShell 序列、从不寻常的域下载文件、执行
mshta,wscriptorundll32异常情况的出现是出现问题的明显迹象。
4. 保护客户端和服务器上的敏感数据
脚本是载体，数据是奖品。要设置难度：
- 避免在前端暴露令牌和密钥。 不要将密钥隐藏在 JavaScript、全局变量或静态代码中。客户端的所有内容都是可见的。
- 正确加密并使用强密钥。 对于传输中的数据，请使用配置良好的 TLS；对于静态数据，请使用当前算法和模式（例如 AES-GCM、Argon2/bcrypt 用于密码等）。
- 正确使用基于令牌的身份验证。 JWT 和类似协议必须使用安全密钥签名，设置合理的过期时间，并且不得使用不安全的算法。请始终使用 HTTPS。
- 仅将白盒加密或混淆作为额外的安全层。 混淆脚本可以增加逆向工程的难度，但这并不能替代安全的设计。
5. 辅助工具：不要试图“用肉眼”看清一切
现代系统处理的代码和脚本数量庞大，手动审查所有内容是不现实的。合理的做法是： 将安全工具集成到开发和运维周期中:
- 静电分析仪（SAST）和安全短截器。 ESLint 配合安全插件、Semgrep 等工具可以检测危险模式，例如使用……
eval不安全的 HTML 或 shell 命令拼接。 - 漏洞扫描器和SCA。 他们会分析你的依赖项（包括前端和后端），查找已知存在 CVE 漏洞的库，并推荐安全版本。
- WAF 和流量监控。 优秀的 Web 应用防火墙可以实时阻止常见的 XSS 和注入攻击，并让你了解异常模式；值得与……配合使用。 防火墙中的自定义规则.
- 硬化工具和 RASP。 运行时自我保护、混淆、篡改和完整性监控为高度暴露的客户端应用程序增加了多层防御。
- 对开发者友好的安全平台。 现代解决方案集成了SAST、SCA、密钥扫描和CI/CD配置，提供 早期发现并通常自动修复 与脚本和依赖项相关的漏洞。
组织变革：脚本安全不仅仅是“IT”人员的事
无论你的代码多么精雕细琢，如果组织仍然不加思考地打开附件，或者运行通过电子邮件收到的每一份脚本，你都将永远疲于奔命地救火。这一点至关重要。 对用户和团队进行培训 关于脚本的具体风险：
- 定期培训。 人们知道如何识别可疑电子邮件、意外的宏、奇怪的弹出窗口和“神奇的”论坛脚本。
- 明确的使用政策。 可以安装哪些软件，从哪里下载脚本，如何管理宏，谁可以使用交互式 PowerShell 等。
- 网络和设备分段。 如果脚本成功入侵了一台计算机，该计算机不应该与整个内部网络建立直接联系。
- 全天候监控和响应。 越早发现正在执行的恶意脚本，它就越没有时间移动、加密或窃取数据。
简而言之，外部脚本是现代开发中强大且绝对必要的工具，但它们也是攻击者的特权入口点，尤其是在与被入侵的合法网站、恶意广告和配置不良的环境结合使用时。
减少权限、控制上传的代码、监控行为，并通过集成到开发周期中的安全工具和流程来支持所有这些操作。 它决定了基础设施是“能用”还是即使有人试图破坏它也能继续运行。 分享信息，其他用户也能了解这个话题。