以实例从软件工程及网络安全视角评 OWASP Top 10 2025 A06: Insecure Design 及跨域安全人才的不可替代性

作者：Sender Su 来源：本站发布日期：2026-01-16 最后修改日期：2026-01-16

笔者之前一篇《没有遵循 Secure by Design 而建的系统，整改就是噩梦》多少有点吐槽意味。时隔2个月后，基本上该系统的安全风险整改已经大部分完成，得以平静下来综合和深入地表达一下自己的观点。

需要前置强调的是，在笔者长达1年多的 Vibe Coding 过程中，各类大模型都频繁地生成带有安全漏洞的代码，除非在生成代码时先明确指出要排除什么风险因素。也就是说，对于缺乏安全风险控制思维的开发者来说，AI 编程必然会产生大量的风险漏洞，这必须敲响警钟。

可以预见，Insecure Design 将会演变为 Insecure AI Design，而专业挖漏洞的朋友估计会赢来事业黄金期。

题图为笔者自行拍摄。

笔者：国际注册信息系统审计师、软考系统分析师、软件工程硕士

一、前言

OWASP Top 10 2025 A06 “Insecure Design”（不安全设计）是软件工程行业与网络安全行业的真正交汇点，却也是双方最容易互相推诿、选择性忽视的“灰色地带”。

网络安全从业者常将其归为“开发的问题”，理由是对于与业务逻辑直接管理的不安全的设计，网络安全的“外科手术”式的手段基本上无能为力；而软件工程师则习惯性地认为：“设计即使有问题，那也是业务逻辑的要求，不是漏洞”，潜台词就是业务优先安全靠边。

所以 A06 风险长期存在，根源就在于认知的分歧且双方都没有穿透到问题的本质。

Insecure Design 的本质，不是简单地用编码缺陷能概括的。它是在需求分析阶段就会埋下的结构性风险，关系到执行需求分析的系统分析师，有没有具备足够的风险控制意识，以及从业务逻辑推断是否存在风险威胁因素的能力，进而才是设计和实现阶段的协同应对。

二、造成不安全设计问题的典型情况

笔者在此举出自己碰到的两例。

1）人的经验惯性

在工业物联网（IIoT）领域，一个典型的设计惯性是：由于设备通常部署在物理隔离的内网环境中，开发者习惯将控制指令（如启停、参数调整）以明文形式直接在网络上传输。这种设计在封闭网络中虽存在隐患，但因攻击面受限，尚属“可控风险”。

然而，当同样的设计逻辑被直接迁移到面向互联网的消费级 IoT 系统时，不可控的风险就随之而来。攻击者可通过枚举 API 路径、重放请求、篡改参数等方式，绕过身份校验，直接操控设备。

例如，假设某设备 API 设计的URL和接口数据如下：

POST /api/v1/device/12345/control
Body: { "action": "set_max_op_mins", "value": 30 }

若 API 内部逻辑未对 URL 路径中的设备ID（12345）实施适当的访问控制措施，比如校验用户身份、权限或者访客需提供正确的访问密钥（该例很显然没有）等方式，那攻击者就有可能通过穷举而获得设备的 ID，进而试探、构建出控制参数，对设备实施远程控制，损坏设备，导致经济损失。

需要强调的是，如果确实是在设计上就没有考虑任何权限控制措施，这就不是越权访问，而是根本未设计权限控制模型，属于 Insecure Design，开展源代码审计就可以确认问题性质。

产生这个例子的根源不在人的软件编码能力水平高低，而是依赖于经验惯性导致在系统设计时未将“资源归属”与“操作授权”作为业务逻辑的核心规则纳入业务模型。

2）具有潜在风险的业务模型

Insecure Design 除了没有遵循明确的风险控制规则而产生的安全漏洞之外，还有更隐蔽的情况：

业务逻辑模型本身就直接构成风险。

这种情况并不容易被发现，但却尤其需要在分析阶段就能被前瞻发现，这样才不会把问题留到设计和实现阶段，甚至在交付后才发现，导致不可收拾。

例如，某个 O2O 网上预订过程的业务逻辑设计为一系列的用户步骤和对应步骤的 API 操作，包括选择线下门店、选择服务类型、选择服务细节参数、选择预订时间、选择付款方式、发起付款、付款后处理等步骤环节，每个环节设计了至少一个 API 调用以完成该环节内用户的操作。

很显然，只从业务逻辑上看，这些步骤都是必须的，充分地引导消费者一步步地完成整个 Online 服务过程，那么 API 的设计跟着业务逻辑走，不就很“合理”了吗。

但从风险控制角度观察，这个设计就等于把风险敞口扩大了N倍：N=API 的数量。而只要其中任一个 API 如果存在安全漏洞，则全军尽墨。

三、从软件工程开发角度考虑解决办法

上述两个例子都只能从软件工程开发角度考虑解决问题的方法，没有什么外科手术式的技术手段可以弥补。

对于例子1：混淆 API 的参数，设计合适的鉴权控制。

很自然地，这些解决方法会带来一些具体的工程问题，比如：对于例子1，很容易就会有人反问，API 参数混淆增加了复杂性和工作量，确有必要？

答案是肯定的，而且还要强调，混淆（Obfuscation）只是实现机密性（Confidentiality, C）的一种手段，而信息安全的 CIA 三要素（Confidentiality, Integrity, Availability）必须协同保障。

如何保证完整性（Integrity）？

使用数字签名对 API 的 Payload 进行签名和校验，或仅对关键 ID 参数使用 HMAC 校验，防止篡改。

如何保证可用性（Availability）？

混淆机制不能过度复杂化，避免引入性能瓶颈或调试困难。比如仅需要10分钟内有效的数字签名就没有必要使用长位数密钥，更没有必要采取多算法交叉校验。

具体混淆方式，业界已有很多 Pattern 比如 JWT（JSON Web Token）可以直接选用，也可简化为外部 ID 映射到内部 ID。但如前所述，必须结合对 CIA 三要素的综合评估结果再行确定。

对于例子2：取消原有每个步骤的 API，改为实现一个获取服务内容的 API，所有的步骤都在前端完成而不产生 API 交互，在发起付款的同时提交完整订单内容，API 接收后进行充分的校验。

这个解决办法的本质在于需要软件工程人员在分析和设计阶段对业务逻辑有更深入的理解，思维不能绑死在既有的分步逻辑上，还要意识到调整后的设计能更灵活地适应分步逻辑的变更：

整个业务逻辑的前期大部分都是在前端进行，如要调整分步过程以实现更好的用户友好度，大概率并不需要修改后端 API，相应地还提高了后端 API 的健壮性。

其实从软件工程角度对安全设计的真正认识是因安全设计而产生的额外的实现成本并不能简单地用值不值去衡量。一如“数据库读写访问要不要事务”、“系统要不要有日志审计”等基础认识。安全不是可选项，而是软件质量属性的一部分。作为系统分析师或架构师，我们的职责是在需求阶段就将安全视为非功能性需求，并量化其对系统可靠性、合规性的影响。

四、从网络安全角度重新理解 Insecure Design

许多安全从业者将 Insecure Design 依然简单等同于“越权漏洞”（Broken Access Control），这是一种误解。

Insecure Design 的实质是“没有限制风险的产生”。

越权的前提是存在权限模型，而 Insecure Design 则广阔得多。即使是从资源的所有者关系、角色操作的映射关系等要素去理解 Insecure Design，都是局限于直接的风险因素，没有从风险控制的整体性去理解 Insecure Design。就如笔者上面的例子2，是潜在风险敞口的倍增问题，这就是风险控制的整体性。

安全从业者之所以会有这种局限性，更多地是因为安全和业务的隔阂所导致。笔者在之前文章中都一直表达这样的观点：

安全如果没有和业务融合，则必然被边缘化以致根本无视。

对于企业高层来说，CIO/CISO 究竟应不应该是企业组织内两个分离的角色，答案在笔者这里就是否定的。

具体到执行网络安全职责的人员，如果没有能把职责和能力放到与业务逻辑相关的系统设计文档、数据流图、权限模型、功能流程的安全审查上，就是没有和业务融合。

五、安全设计没有近道，不能规避

软件开发中最危险的思维是：“先跑通功能，安全后面再加。”

这种“敏捷式拖延”在 Insecure Design 面前尤为致命。因为一旦数据模型、接口规范、权限体系定型，后期修改将牵一发而动全身，为此而额外支出的成本远高于初期设计。

顺带一提，这还会影响到经济审计（笔者背景之一）：

一个因安全漏洞而要补锅的应用系统，其实际价值并不会因为追加了修补安全漏洞的投资而增值，而是因为追加的投资确证其存在重大缺陷而应减值看待。

尤其是当涉及到知识产权定价和转让时，等于直接否定了其价值。谁会冒险采购一套曾经花大价钱修补风险漏洞的应用系统？谁知道这套系统还有没有未修补的重大风险漏洞？

所以 Secure by Design 的核心在于：安全不是系统功能建设，而是原则性的系统整体能力。

它要求我们在画第一张 UML 图、写第一个 USE CASE 时，就要有风险控制的意识贯穿其中。