Havenlon｜执行缝隙（五）：为什么 UI 展示也是执行系统的攻击面

Lovekde_cn1

173人浏览 · 2026-07-10 09:15:00

Lovekde_cn1 · 2026-07-10 09:15:00 发布

用户不是直接面对执行。 用户面对的，是 UI 告诉他的那个执行。

摘要

大多数团队，都把 UI 当成体验层。

按钮好不好点，页面清不清楚，流程顺不顺，提示友不友好，字段够不够简洁。

这些当然重要。

但在高风险执行系统里，UI 远不只是体验层。

UI 是用户理解执行的入口。 UI 是审批人判断风险的依据。 UI 是签名之前，最后一次语义展示。 UI 是 AI Agent 请求授权时的解释窗口。 UI 是 Intent 在被用户再次确认之前，唯一的表达形式。

所以，UI 从来不是执行系统"之外"的东西。

UI 本身，就是执行链路的一部分——而执行链路上的每一环，都是攻击面。

如果 UI 展示的内容不完整、被包装、被误导、被压缩，或者干脆被篡改，那么用户最终确认的，就可能根本不是即将发生的那个真实 Execution。

这就是执行缝隙里的第五层问题：

UI 展示，也是执行系统的攻击面。

过去，我们习惯于防后端、防接口、防签名、防权限。这些防线都建得很厚。但在 AI Agent、企业自动化、Web3 多签和高风险 SaaS 的世界里，一次错误的展示，就足以把用户平稳地引向一次错误的确认。前四篇我们一路追问 Intent、确认、审批、payload；这一篇，我们把目光转向那个离用户最近、却最少被当作安全对象的东西——屏幕本身。

一、UI 不是一个中立的窗口

很多人会下意识地认为：UI 只是把后端的结果如实展示出来而已。

但在真实系统里，UI 从来不是完全中立的。

它会选择展示什么，也会选择不展示什么。

它决定字段的顺序，决定风险提示的强弱，决定按钮的文案，决定摘要的长短，决定哪些内容被折叠、哪些被高亮，决定哪些风险被归类为"普通提示",决定用户在点下确认之前，到底能不能看到完整的后果。

这些选择，每一个都在影响用户的判断。

同一个执行请求，用两种不同的 UI 去展示，用户感受到的风险，可能截然不同。

一种展示会让用户警觉，另一种会让他放松。一种会让用户意识到这是高风险动作，另一种会让他以为这只是走个流程。一种会把最终后果摊开给他看，另一种只给他一个操作名称。

所以 UI 不只是显示层。

UI 是语义层——它决定了用户如何理解一个即将改变现实的动作。

它不是一面透明的玻璃，它是一副有度数、甚至可能被人调过度数的眼镜。

二、用户确认的不是底层事实，而是 UI 版本的事实

用户极少直接看见底层的 payload，审批人也极少直接看见完整的执行路径。

他们看到的，永远是 UI 渲染出来的那个版本。

比如：付款审批页面、钱包交易弹窗、多签平台确认页、SaaS 权限申请页、Agent 工具调用授权页、运维变更工单、设备远程控制面板、企业流程审批摘要。

这些页面上呈现的内容，通常都已经过了好几层处理：底层的执行对象被解析成字段，字段被聚合成摘要，摘要被格式化成界面，界面再用文案、颜色、排序、按钮，去引导用户的判断。

用户在最后点下确认时，他确认的，是这个 UI 版本的事实。

但 UI 版本的事实，不一定等于底层的执行事实。

如果 UI 说的是 A，payload 做的是 B，用户确认的是 A，现实发生的却是 B——那么这次确认，就已经失去了它全部的安全意义。

因为用户从头到尾，都没有真正确认过 B。他只是确认了 UI 告诉他的那个 A。

在密码学界，这个问题早就有一个专门的名字：WYSIWYS——What You See Is What You Sign，所见即所签。它是一个理想，也是一条至今没有被彻底满足的要求：你签下的字节，必须和你眼睛看到的语义，严格对应。一旦这条对应关系断裂，安全就从"是否签了"退化成了"你以为签了什么"。

三、UI 攻击不一定是篡改页面，更多是选择性展示

一说到 UI 攻击，很多人会立刻想到页面被黑、前端被篡改、按钮被替换。

这些当然是真实存在的风险。前端供应链攻击就是典型：一个被投毒的 npm 依赖、一段被注入的第三方脚本、一次被劫持的 CDN，都足以让钱包弹窗里显示的地址，和真正被签进 payload 的地址悄悄分家。用户看到的是自己复制的收款地址，签下去的却是攻击者的。这类攻击里，后端和链都毫发无损，出问题的纯粹是那层"给人看"的展示。

但更常见、也更难防的 UI 风险，其实根本不来自明显的篡改。

它来自选择性展示。

比如：只展示交易名称，不展示真实后果；只展示金额，不展示授权范围；只展示目标系统，不展示环境差异；只展示审批理由，不展示执行参数；只展示 Agent 的目的，不展示它的工具调用细节；只展示"允许访问",不展示访问权限的边界；只展示"确认操作",不展示这个操作是否不可逆；只展示"低风险",不展示多个低风险动作组合之后的高风险结果。

这些 UI，可能一个字节都没被黑。它们甚至严格符合团队的产品设计规范，通过了所有的设计评审。

但它们仍然会造成安全问题。

因为它们让用户在一份不完整的信息上，做出了确认。

在普通产品里，信息不完整只是一个体验缺陷；在执行系统里，信息不完整会直接导致一个错误的执行被放行。

选择性展示的可怕之处在于，它不需要任何"攻击"就能生效——它只需要一次出于好意的简化。

还有一类更古老、也更狡猾的手法，介于"篡改"和"简化"之间，叫 UI redressing（界面伪装），最典型的就是 clickjacking（点击劫持）。攻击者不去改你看到的内容，而是在你以为的按钮之上，盖一层透明的、你看不见的元素；你以为自己点的是"取消",实际触发的是"授权"。你看到的一切都是真的，你点击的动作也是真的，唯独"看到的"和"点到的"之间，被人插进了一层。在这类攻击里，展示的内容甚至完全无辜，被利用的是展示与操作之间的空隙。

这提醒我们一件事：UI 的攻击面，不止是"显示了什么",还包括"显示的东西和你真正操作的东西，是不是同一个"。渲染是可信的，不代表交互是可信的。

四、友好的 UI，可能正在掩盖高风险动作

产品设计的本能，是追求友好：减少复杂度，降低认知负担，消解用户的恐惧，提高转化率，让整个流程更顺滑。

在绝大多数普通产品里，这些原则毫无问题，甚至就是好设计的定义。

但在高风险的执行场景里，过度友好会变成一层掩盖风险的糖衣。

一个删除生产数据的动作，不该被展示成"清理空间"。一个大额授权动作，不该被展示成"继续操作"。一次资产控制权的变更，不该被展示成"连接账户"。一次长期权限的开放，不该被展示成"临时访问"。一次 Agent 的高危工具调用，不该被展示成"完成任务所需的一步"。

当 UI 把一个高风险动作，包装成一个普通动作，用户就再也无法做出真实的判断了。

这不是用户不专业的问题。这是 UI 亲手改变了用户看到的语义。

用户不是在真实的风险面前做确认，他是在一个被产品化、被柔化之后的"风险表达"面前做确认。而只要这个表达压低了风险的感知强度，那次确认，本质上就已经被诱导了——哪怕没有任何一个环节存在恶意。

五、按钮文案，也是安全边界的一部分

很多系统里的确认按钮，做得极其简单：确认、同意、继续、授权、允许、下一步、执行。

这些文案，看起来只是纯粹的交互设计。

但在高风险执行里，按钮文案会直接影响用户对动作性质的理解。

"继续",和"执行转账",不是一回事。 "允许",和"允许长期访问账户",不是一回事。 "授权",和"授权第三方支配资产",不是一回事。 "确认",和"确认不可逆地删除生产数据",不是一回事。 "下一步",和"立即调用外部系统",不是一回事。

如果按钮文案把真实动作抽象掉了，用户几乎必然会低估它的后果。

在 AI Agent 场景里，这个问题被推到了极端。因为按钮可能只剩下一句：

允许 Agent 继续。

而这个"继续"背后，可能包含着：调用外部 API、修改账户权限、访问敏感文件、提交生产变更、广播一笔交易、删除数据、执行脚本。

一个词，兜住了七种后果。

所以按钮不是一个简单的 UI 组件。

它是用户踏进执行路径之前，看到的最后一句语义提示。如果这句提示是模糊的，那么它遮住的，就是真实的风险。

六、AI Agent 让 UI 展示问题变得空前严重

AI Agent 带来的一个根本变化是：用户越来越少直接操作某个具体功能，而越来越多地，是在确认 Agent 的计划、建议和下一步动作。

这时候，UI 展示的对象，就不再是一个固定的、可审计的表单，而可能是 Agent 动态生成的一段自然语言。

例如：我需要访问这些文件来完成分析；我需要调用这个工具来继续任务；我建议批准这批操作；我将为你完成后续步骤；这是一个正常的权限请求。

这些话都合情合理。但它们可能根本没有完整展示真实的执行边界。

Agent 的解释可能遗漏关键细节。Agent 的摘要可能弱化风险。Agent 的语气可能让用户放下警惕。Agent 对目标的描述，可能盖住了工具调用真正的后果。Agent 那种笃定的自信，可能让用户干脆不再检查。

更麻烦的是，Agent 生成的这段 UI 内容本身，是不稳定、且可被操纵的。

同一个执行动作，Agent 可以用十种不同的措辞去解释，而不同的措辞会带来不同的风险感知，进而导致不同的确认结果。更危险的是，如果 Agent 的上下文里混入了提示注入（prompt injection）——一段藏在文件、网页或工具返回值里的恶意指令——那么它生成给用户看的那段"解释",本身就可能是被攻击者构造出来的。展示层不再是开发者写死的模板，而成了一个可以被外部输入影响的动态产物。

在 AI Agent 时代，UI 不再只是展示层，它变成了一个动态生成的语义中介——而这个中介本身，就是一个全新的、会说话的攻击面。

七、Web3 钱包，早就把 UI 展示的危险演示了一遍

在 Web3 世界里，大量的资产损失，根本不是因为签名系统坏了。

签名是有效的。链上执行是正确的。私钥也没有泄露。

问题出在——用户看到的内容，和真实的执行后果之间，存在一道断层。

用户看到"签名登录",实际可能是在签一个复杂的授权。用户看到"领取奖励",实际可能是在批准一次资产支出。用户看到"确认交易",实际可能是在调用一个带有连锁后果的合约。用户看到"连接钱包",实际可能是在建立一段后续的权限关系。

这里的问题，不在于链执行错了。链非常忠实，钱包也可能一切正常，用户也确实亲手点了确认。

问题在于，UI 没有让用户理解真实的后果。

这背后一个长期存在的技术顽疾，叫盲签（blind signing）：当交易数据复杂到钱包无法解析、或硬件设备屏幕太小无法完整呈现时，用户面对的其实是一串无意义的十六进制，或者一句语焉不详的"确认签名"。他签的不是他理解的东西，他签的是他看不懂、于是选择相信的东西。

行业为此发展出了两条补救路线：一条是前面提过的 EIP-712 结构化签名，让数据能被解析成人类可读字段；另一条是交易模拟（transaction simulation）——在签名之前先把这笔交易在一个仿真环境里跑一遍，把"你的资产余额会发生什么变化"直接摊给用户看。这些都是把 UI 从"展示意图"推向"展示后果"的努力。

但它们依然有边界：模拟依赖的状态可能和真实执行时不一致，解析依赖的合约元数据可能被伪造。于是那条铁律再次成立：

如果 UI 没能展示真实的语义，那么签名越顺畅，风险就越顺畅地进入现实。

八、企业审批系统里的 UI 风险，更隐蔽

企业系统同样如此，而且藏得更深。

审批页面往往看起来非常正式、非常齐全：申请人、部门、理由、金额、风险等级、审批链、附件、操作按钮，一应俱全。

但这些信息，未必足以证明执行安全。

审批页显示的是"供应商付款",却没有把"收款账户是否在近期被变更过"这一点突出出来。审批页显示的是"权限申请",却没有展示这个权限和用户已有权限组合之后的后果。审批页显示的是"临时访问",却没有展示回收机制到底存不存在。审批页显示的是"低风险变更",却没有展示目标环境其实是生产环境。审批页显示的是"Agent 任务执行",却没有展示 Agent 将要调用哪些外部系统。

企业审批的 UI，往往执着于展示"流程的完整",却恰恰漏掉了藏在流程之外的那层语义关系——而风险，正住在那里。

如果 UI 只展示流程，不展示执行后果，那么审批人能确认的，永远只是"流程",而不是那个即将发生的现实动作。他签的字很齐全，但他签的其实是一张流程表，不是一次执行。

九、UI 还可能制造一种"责任转移的幻觉"

很多系统喜欢在关键步骤，加上一句提示：请确认你已理解风险；点击即代表你同意；该操作由你本人确认；后果由操作者自行承担。

这些提示，看起来是在增强安全。

但如果系统压根没有真正把风险展示清楚，这些提示就只剩下一个作用——把责任转移给用户。

用户没有看到完整的后果，却被要求承担完整的责任。用户没有看到真实的 payload，却被要求确认真实的执行。用户没有看到权限的边界，却被要求接受权限的风险。用户没有看到 Agent 的工具调用，却被要求同意 Agent 去执行。

这不是安全，这是把系统自己没解释清楚的东西，打包转嫁给用户去扛。

在高风险执行系统里，责任提示永远不能替代语义展示。

不能因为用户点了一下"我已知晓",就默认他真的知道。系统不该把 UI 设计成一个法律意义上的免责按钮。它真正该做的，是尽最大努力把执行边界展示清楚，然后——在执行端继续独立验证。一句"我已阅读并同意",挡得住法务的追责，却挡不住现实里已经发生的损失。

十、真正安全的 UI，不是展示更多，而是展示关键边界

当然，解法绝不是把所有底层数据一股脑塞给用户。那样只会让他更看不懂，最终在信息过载里更快地点下确认。堆砌信息和隐藏信息，是同一枚硬币的两面，都会导致盲签。

真正安全的 UI，不是展示更多的字段，而是展示关键的边界。

它应该清晰地回答几个问题：这个动作会改变什么；影响的对象是谁；是否不可逆；权限范围有多大；时间窗口有多长；是否会触发外部系统；是否会产生持续授权；是否超出了历史行为模式；是否和原始 Intent 一致；是否和审批内容一致；是否和本地策略一致。

UI 应该帮用户看见的是边界，而不只是流程。

对于普通动作，UI 完全可以简洁、可以顺滑。但对于高风险动作，UI 必须克制、必须明确、不能有一丝含糊。

它不应该去追求让用户"无感通过"。

恰恰相反，好的高风险 UI，要让用户清清楚楚地意识到一件事：这是一个会改变现实的动作。

在这些地方，一点点"摩擦"不是体验的失败，而是安全的设计。

十一、但 UI 做得再好，也不能成为最终的安全边界

即便 UI 已经做到了极致，它依然不能成为最后一道安全边界。

因为 UI 仍然可能被攻击，前端仍然可能被篡改，展示仍然可能被误导，摘要仍然可能不完整，用户仍然可能误解，审批人仍然可能疲劳，Agent 仍然可能生成一段错误的解释。

任何需要靠"人正确理解"才能生效的防线，都不是一道可靠的防线——因为理解，本身就是可以被操纵的。

所以执行系统绝不能把 UI 当成最后的防线。

UI 的职责，是帮助人更好地理解和判断。但在最终执行之前，系统仍然需要一道独立的边界，去重新验证：UI 展示的内容，是否和 payload 一致；用户确认的对象，是否和执行的对象一致；审批摘要，是否覆盖了关键的执行边界；Agent 的解释，是否对应它真实的工具调用；SaaS 的展示，是否经过了本地边界的独立校验；最终的动作，是否仍然符合 Intent。

这，正是 Havenlon 和一个普通确认系统之间的根本区别。

普通系统的逻辑是：用户已经看见并确认了，所以可以执行。

而 Havenlon 关心的是另一个问题：