文章总结： 文档系统分析了漏洞产生的五大根本原因：人类的错误假设、软件编程漏洞、系统复杂性、过度定制化以及技术设计缺陷。文章指出漏洞多源于防御方的错误预设而非攻击方的高明手段，强调安全应融入架构设计而非事后补救。针对每类原因提供了具体解决方案，如输入验证、参数化查询、简化系统架构、采用成熟框架等可操作性建议。 综合评分： 85 文章分类： 漏洞分析,安全意识,安全建设,WEB安全,安全开发

2. 软件漏洞

这是大多数人听到“漏洞”这个词时首先想到的：一种引入意外行为的编程错误。

关键的区别在于：一段代码即使完全符合其功能需求，仍然可能存在严重的安全隐患。“它能运行”和“它安全”是两个截然不同的说法。

实际场景：一个Web应用程序处理表单数据并与数据库交互。开发人员没有使用参数化输入，而是直接将用户输入拼接成SQL查询字符串。

# 易受攻击：用户输入直接拼接
query = "SELECT * FROM users WHERE email = '" + user_input + "'"

# 安全：参数化查询
cursor.execute ( "SELECT * FROM users WHERE email = %s" , ( user_input, ) )

攻击者提交了精心构造的输入' OR '1'='1，查询结果返回数据库中的所有记录。敏感数据被窃取，账户被盗用。而应用程序却始终“运行正常”。

解决方法：永远不要将用户输入拼接到查询语句中。每次数据库交互都应使用参数化查询和预处理语句。运行静态分析工具，标记不安全的查询构造模式。在参数化查询之上，实施输入验证作为纵深防御层。

3. 系统复杂性

现代应用程序并非运行在单个服务器上的单一代码块，而是由 API、微服务、数据库、身份验证提供商、支付处理器、CDN、消息队列和第三方集成等组成的庞大生态系统。

组件之间的每一个连接都可能存在配置错误。每一次集成都可能造成信任边界失效。而且，系统越复杂，任何一个人就越难将整个架构牢记于心。

真实场景：一家公司在其Web应用程序中集成了多个第三方服务。身份验证提供商负责处理登录，支付处理商负责处理交易，分析服务负责跟踪数据。在一次例行部署过程中，一个内部管理API端点意外暴露在公共互联网上。该端点原本设计为只能通过VPN访问。

由于涉及的服务和配置数量庞大，因此无人察觉。攻击者通过基本的侦察手段发现暴露的端点，并直接访问关键的管理功能。

复杂性并非优势，而是攻击面。添加到系统中的每一个组件都必须进行安全保护、监控和持续维护。

解决方案：维护一份最新的 API 端点、服务和集成清单。定期进行攻击面审计。使用自动化工具扫描暴露的端点和错误配置。对每个服务间连接应用最小权限原则。如果某个服务不需要公开访问，那么就绝对不能公开访问。

4. 过度定制

企业软件开发中存在一种反复出现的模式，大致如下：

一家机构正在评估一个经过充分测试的标准身份验证（或会话管理或访问控制）框架。该框架与机构的内部需求并不完全匹配。因此，他们没有选择调整框架以满足自身需求，而是决定从头开始构建一个定制解决方案。

自定义代码意味着自定义漏洞。而自定义安全关键代码意味着自定义安全关键漏洞。

实际场景：某组织没有采用成熟的框架（例如 OAuth 2.0）或维护良好的身份验证库，而是构建了一个自定义身份验证系统。该自定义系统包含其自身的密码存储逻辑、会话处理机制和帐户恢复流程。

第一年运行良好。之后，开发团队离职。维护工作变得断断续续。密码哈希算法落后于行业标准。会话超时时间变得不稳定。账户恢复流程出现逻辑漏洞，攻击者可以通过篡改恢复令牌来重置任何用户的密码。

如果采用标准的、由社区维护并定期接收安全更新的框架，这一切都不会发生。

解决方案：所有安全关键功能都应默认使用成熟且维护良好的框架。除非存在现有解决方案无法满足的真正特殊需求，否则绝不应自定义构建身份验证、会话管理、加密和访问控制功能。如果自定义不可避免，则应将自定义代码视为高风险组件，需要进行专门的安全审查和定期审计。

5. 技术和设计缺陷

这可以说是最危险的一类问题，因为缺陷不在于代码，而在于架构。

技术和设计缺陷源于系统从一开始就未内置安全机制。功能是后期添加的，安全控制措施也是事后才匆忙添加的。而最初的设计中却隐藏着逻辑漏洞，任何安全的编码都无法弥补，因为这种缺陷是结构性的。

实际场景：一个Web应用程序需要实现多因素身份验证（MFA）。开发人员将MFA添加到登录流程中。用户输入密码，然后会收到发送到手机上的一次性验证码。这是标准实现方式。

但这里存在一个设计缺陷：应用程序在多因素身份验证 (MFA) 步骤完成之前就颁发了完全认证的会话 cookie 。会话是在密码验证之后、一次性代码提交之前创建的。

攻击者如果通过网络钓鱼或撞库攻击获取了有效密码，就可以登录并接收会话 cookie，然后直接访问已认证的页面，而无需完成多因素身份验证 (MFA)。MFA 界面只是一个前端入口，后端实际上已经授予了完全访问权限。

解决方案：必须从第一次白板讨论会开始就将安全性融入架构设计中。特别是对于多因素身份验证 (MFA)，只有在所有身份验证因素都成功验证后，才能颁发已认证会话。在设计阶段进行威胁建模，而不是在部署之后。审查端到端的身份验证流程，而不仅仅是单个组件。

五个背后的模式

综合考虑这五个根本原因，可以发现一个清晰的模式。

漏洞的出现很少是因为攻击者做了什么高明的手段，而是因为防御者做出了错误的假设。他们假设用户会按照预期的方式行事，假设代码只会接收到预期的输入，假设系统过于复杂以至于任何人都无法发现配置错误，假设自定义代码“足够好”，假设设计图看起来很安全，就想当然地认为它是安全的。

攻击者不需要多么聪明，他们只需要耐心和一个会做出错误假设的目标。

令人不安的事实是，大多数安全漏洞攻击都十分平庸。它们利用的是早已为人熟知、记录了几十年的漏洞类型。SQL注入自OWASP Top 10列表创建以来就一直位列其中。不受限制的文件上传也是一种已知的攻击途径，存在时间超过20年。通过会话管理不当绕过多因素身份验证（MFA）是渗透测试报告中的经典案例。

预防这些漏洞的知识早已存在。差距不在于知识，而在于执行力：构建系统时，始终假设每个用户都是攻击者。验证每一个输入。简化每一个系统。默认使用成熟的框架。在编写第一行代码之前，就将安全性融入架构设计之中。

这份清单上的所有漏洞都是可以预防的，每一个都是。唯一的问题是，预防措施是在漏洞发生之前实施，还是在漏洞发生之后实施。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：KK安全说 破天KK 破天KK《漏洞产生的五个原因》