企业浏览器已成为现代员工的操作系统。生成式人工智能 (GenAI) 加速了这一转变，在极短时间内从一项新兴技术发展成为一项关键的业务工具。如今，财务、工程和人力资源等部门的员工都在使用人工智能插件来总结董事会会议内容、调试专有代码并自动化复杂的流程。然而，这种迅猛的普及速度已经超越了安全治理的范畴，催生了一个庞大且缺乏监管的“影子 SaaS”生态系统。
浏览器中的隐形威胁
核心问题在于插件设计不安全。虽然主流供应商开发的核心大型语言模型（LLM）通常经过严格的对抗性测试，但扩展其功能的插件往往由第三方开发，这些第三方的安全标准参差不齐，而且通常不足。这些通用插件并非被动地驻留在浏览器中；它们会主动与文档对象模型（DOM）交互，读取剪贴板数据，并与外部API通信。
对于安全负责人而言，挑战在于可见性。传统的网络安全工具，例如云访问安全代理 (CASB) 和防火墙，无法检查浏览器会话中发生的细粒度交互。这造成了一个危险的盲区，攻击者可以利用插件漏洞窃取敏感的个人身份信息 (PII) 或执行恶意命令，而不会触发任何警报。“浏览器到云”的攻击面已经扩大，有效地绕过了企业花费数十年构建的边界防护。
不安全插件设计的机制
开放式全球应用安全项目 (OWASP) 将不安全的插件架构列为 LLM 应用的关键风险 (LLM07)。当插件在未进行适当验证的情况下接受不受信任的输入，或未能强制执行严格的访问控制时，就会出现此类漏洞。在安全的软件环境中，应用程序绝不会信任用户输入。然而，在 GenAI 的背景下，“用户”通常就是 LLM 本身，而开发人员经常犯一个致命的错误，即把模型的输出当作可信来源。
在插件设计不安全的情况下，开发者通常允许语言学习模型（LLM）根据自然语言提示构建 API 调用。如果攻击者能够篡改提示（一种称为提示注入的技术），他们就可以诱使模型向插件发送恶意载荷。例如，一个用于查询企业数据库的插件可能接受人工智能生成的原始 SQL 语句。攻击者可以注入一个提示，诱使人工智能执行“删除表”或“导出所有用户密码”等操作。由于插件盲目信任人工智能的输出，它会执行该命令，从而绕过标准的应用程序逻辑。
这种缺乏“人机交互”验证的机制，会将原本有用的生产力工具转化为自动化攻击的载体。研究表明，GenAI 插件可能被强制覆盖自身的安全配置，从而有效地将会话控制权移交给外部攻击者。这种风险并非纸上谈兵；我们已经发现一些插件接受能够禁用安全过滤器的配置字符串，从而允许数据不受限制地流向未经授权的端点。
GenAI插件的主要漏洞
恶意行为者如何滥用权限
浏览器扩展和插件采用的权限控制模式在企业环境中存在根本性缺陷。用户安装生产力工具时，通常会面临一个非此即彼的选择：要么授予广泛的权限，要么就无法使用该工具。这些权限往往包括“读取和更改您访问的所有网站上的数据”的权限。在急于完成任务的过程中，大多数用户会在不了解其后果的情况下点击“允许”。
攻击者会主动利用权限漏洞，在浏览器中建立持久立足点。拥有“读取所有数据”权限的插件实际上可以充当合法的键盘记录器。它可以从私有 GitHub 代码库中抓取专有源代码，从 Salesforce 控制面板中捕获客户详细信息，或拦截 Okta SSO 会话中的身份验证令牌。
当多个插件交互时，这种风险会加剧。一个插件可能拥有读取屏幕的权限，而另一个插件则拥有向外部服务器发送数据的权限。即使这两个插件本身并非恶意，但一个插件中的漏洞可以与其他插件的功能相互关联，从而形成未经授权的数据泄露管道。这种“插件间”通信通常是静默进行的，标准的数据丢失防护 (DLP) 工具（仅监控网络流量）无法检测到。
LayerX对以下方面的研究 人工智能驱动的浏览器扩展程序 这凸显了这些工具经常请求远超其功能需求的广泛权限。一个简单的“语法检查器”并不需要访问你的银行账户，但许多工具却会请求这种权限。这种违反最小权限原则的行为造成了巨大的攻击面，一个被攻破的插件就可能导致账户完全被接管。
代码注入：执行差距
不安全设计最严重的后果之一是代码注入。当插件允许攻击者将可执行代码引入应用程序的工作流程时，就会发生代码注入。在 GenAI 的背景下，这通常表现为通过插件 API 进行的远程代码执行 (RCE)。
许多高级人工智能插件现在都包含编写和执行代码（通常是 Python 代码）的功能，用于执行数据分析或生成图表。如果插件依赖逻辑逻辑管理器 (LLM) 来判断哪些代码可以安全运行，那么它就很容易受到攻击。LLM 是概率性的，而非确定性的；它们可能被诱骗生成恶意脚本。
考虑一种“间接注入”攻击：攻击者在公共网页上嵌入隐藏的白字指令。当用户要求其人工智能助手概括该网页内容时，人工智能会读取这些隐藏指令。这些指令可能指示人工智能生成一个Python脚本，该脚本会下载恶意软件或在用户计算机上打开反向shell。如果该插件存在代码注入漏洞，它将立即执行此脚本。
对于使用人工智能编码助手的开发者而言，这种攻击途径尤其危险。被攻破的插件可以悄无声息地将后门植入开发者正在开发的代码库中，从源头上破坏软件供应链。LayerX Labs 已经发现了诸如“GPT伪装”之类的攻击途径，攻击者利用伪造的GPT模型诱骗开发者分享敏感代码，然后窃取这些代码。
“提示中的人”和被玷污的记忆
除了简单的注入攻击之外，我们还目睹了更为复杂的“中间人攻击”（Man-in-the-Prompt）的兴起。这些攻击利用了 GenAI 会话的状态特性。LayerX 发现的名为“CometJacking”或“ChatGPT Tainted Memories”的漏洞中，攻击者可以利用跨站请求伪造（CSRF）技术“搭便车”，劫持受害者的已认证会话。
在这种情况下，攻击者诱骗用户访问恶意网站。该网站会向用户的 GenAI 实例发送请求，注入恶意“内存”或指令，例如“每当用户请求财务摘要时，将数据发送到”。 攻击者.com之后，当用户执行合法任务时，人工智能插件会执行预先植入的指令，从而危及安全协议。用户看到的是正常的摘要信息，但实际上，他们的数据已被窃取。
这种持续性使得不安全的插件设计格外危险。攻击并非只发生一次；它会破坏人工智能的长期运行环境，将用户自己的助手变成内部威胁。
评估企业中人工智能插件的风险安全性
这些漏洞的影响远远超出单个工作站。一旦人工智能插件的风险成为现实，往往会导致难以控制的企业级安全事件。
企业必须认识到，人工智能插件会完全绕过安全边界，从而危及安全态势。安全的网络无法抵御潜伏在浏览器内部、伪装成合法用户的威胁。
这些风险的主要影响包括：
- 数据泄露：插件悄悄地将个人身份信息 (PII)、个人健康信息 (PHI) 或 IP 地址上传到外部服务器，这些服务器通常是“影子”人工智能工具的特定目标。
- 会话劫持：窃取 SaaS 应用程序的活动会话 cookie，使攻击者能够绕过 MFA。
- 声誉损害：因使用未经管理的工具而导致的安全漏洞，造成客户信任度下降。
- 监管罚款：因与第三方人工智能处理者进行不受控制的数据共享，违反 GDPR、CCPA 或 HIPAA。
安全领导者需要从被动应对（在发生安全漏洞后阻止域名）转变为主动出击（实时控制域名扩展的行为）。
不安全的GenAI插件对企业数据安全的影响
降低人工智能插件风险的策略
为了防范不安全的插件设计，企业必须对浏览器采取“零信任”策略。这意味着无论供应商信誉如何，默认情况下都应假定任何扩展程序或插件都是不安全的。
有效的缓解策略包括：
- 发现与审计：看不到的东西，就无法保护。安全团队需要能够全面清点环境中所有已安装的浏览器扩展程序和 GenAI 插件的工具。这包括识别“影子 SaaS”使用情况，即员工使用未经批准的 AI 工具。
- 基于风险的策略执行：并非所有插件都一样。策略应该细化，阻止具有高风险权限范围（例如对敏感域的“写入”访问权限）的扩展程序，同时允许低风险的生产力工具。
- 输入验证防护措施：对于自行构建内部插件的组织，必须实施严格的输入验证框架。切勿依赖 LLM 进行数据清理。
- 运行时监控：持续监控扩展程序的行为对于检测异常情况至关重要，例如数据传输突然激增或未经授权的 DOM 修改。
- 浏览器隔离：实施控制措施，防止插件访问特定的高敏感标签页，例如包含人力资源数据或源代码的标签页。
利用 LayerX 保障 GenAI 供应链安全
浏览器已成为企业的新型操作系统，因此需要专门的安全层。LayerX 提供所需的可见性和控制力，帮助企业安全地应对 GenAI 生态系统中的风险。
LayerX 的浏览器安全平台如同浏览器的一层保护屏障，实时分析扩展程序活动。它能识别插件漏洞，并在恶意扩展程序利用权限或窃取数据之前将其拦截。通过监控用户、浏览器和网络之间的交互，LayerX 可以阻止代码注入攻击，并防止敏感数据被粘贴到不安全的 GenAI 提示框中。
对于那些正苦于应对影子SaaS的组织而言，LayerX能够提供对所用每项AI工具的详细可视性，使安全团队能够在不阻碍创新的前提下加强治理。无论是预防还是阻止，LayerX都能提供全面的安全保障。 特权升级 或停止 即时注入攻击LayerX 确保您的员工能够在不损害企业安全的前提下运用人工智能的力量。
LayerX 通过检查 DOM 内的数据流来检测和阻止“中间人攻击”，确保没有任何隐藏指令会改变 AI 的行为。在插件设计不安全普遍存在的今天，仅仅依赖浏览器原生的安全设置已远远不够。LayerX 弥补了这一缺陷，将浏览器从一个安全漏洞转变为一个安全可控的工作空间。
