安全指南

我们非常重视安全性。 CodeIgniter 采用了许多功能和技术来强制执行良好的安全实践，或让你能够轻松实现。

我们尊重 开放 Web 应用程序安全项目 (OWASP)，并尽可能遵循其建议。

以下内容来自 OWASP 十大安全风险 和 OWASP API 安全十大风险， 这些是针对 Web 应用程序和 API 的最高风险漏洞。 对于每个风险，我们提供简要描述、OWASP 建议以及 CodeIgniter 提供的应对措施。

OWASP 十大安全风险 2021

A01:2021 访问控制失效

访问控制强制执行策略，确保用户无法超出其预期权限进行操作。失败通常会导致未经授权的信息泄露、 所有数据的修改或破坏，或在用户权限范围之外执行业务功能。

常见的访问控制漏洞包括：

  • 违反最小权限原则或默认拒绝原则，即访问权限应仅授予特定能力、角色或用户，但实际对任何人都可用。

  • 通过修改 URL（参数篡改或强制浏览）、内部应用程序状态或 HTML 页面，或使用攻击工具修改 API 请求来绕过访问控制检查。

  • 通过提供其唯一标识符，允许查看或编辑他人的账户（不安全的直接对象引用）。

  • 访问 API 时缺少对 POST、PUT 和 DELETE 操作的访问控制。

  • 特权提升。未登录时以用户身份操作，或以普通用户身份登录时以管理员身份操作。

  • 操纵元数据，例如重放或篡改 JSON Web Token (JWT) 访问控制令牌，或操纵 Cookie 或隐藏字段来提升权限，或滥用 JWT 无效化。

  • CORS 配置错误，允许来自未授权/不可信来源的 API 访问。

  • 未认证用户强制浏览到需认证的页面，或普通用户强制浏览到特权页面。

OWASP 建议

访问控制仅在受信任的服务器端代码或无服务器 API 中有效， 攻击者无法修改访问控制检查或元数据。

  • 除公共资源外，默认拒绝访问。

  • 一次性实现访问控制机制并在整个应用程序中复用， 包括尽量减少跨域资源共享 (CORS) 的使用。

  • 模型访问控制应强制执行记录所有权，而非接受用户可以创建、读取、更新或删除任何记录。

  • 应通过领域模型强制执行独特的应用业务限制要求。

  • 禁用 Web 服务器目录列表，并确保文件元数据（例如 .git）和 备份文件不在 Web 根目录内。

  • 记录访问控制失败，适当时向管理员发出警报（例如，重复失败）。

  • 限制 API 和控制器访问频率，以尽量减少自动化攻击工具造成的危害。

  • 有状态会话标识符应在注销后在服务器端失效。 无状态 JWT 令牌应尽可能短暂，以最小化攻击者的机会窗口。对于长期有效的 JWT， 强烈建议遵循 OAuth 标准来撤销访问。

CodeIgniter 应对措施

A02:2021 加密失败

首要任务是确定传输中和静态数据的保护需求。例如，密码、信用卡号、健康记录、个人 信息和商业机密需要额外保护，尤其是当这些数据受隐私法（如欧盟《通用数据保护条例》(GDPR)）或法规（如支付卡行业数据安全标准 (PCI DSS)）约束时。对于所有此类数据：

  • 是否有任何数据以明文形式传输？这涉及 HTTP、SMTP、FTP 等协议，也包括使用 STARTTLS 等 TLS 升级。外部互联网流量是危险的。请验证所有内部流量，例如负载均衡器、Web 服务器或后端系统之间的流量。

  • 是否默认或在旧代码中使用了任何旧的或弱的加密算法或协议？

  • 是否在使用默认加密密钥，生成了弱密钥或重复使用密钥，或缺少适当的密钥管理或轮换？加密密钥是否被提交到源代码仓库中？

  • 是否未强制执行加密，例如，是否缺少任何 HTTP 头（浏览器）安全指令或头？

  • 是否正确验证了收到的服务器证书和信任链？

  • 初始化向量是否被忽略、重复使用，或未为加密操作模式生成足够安全？是否使用了不安全的操作模式（如 ECB）？在更适用认证加密时是否使用了加密？

  • 在没有密码派生密钥函数的情况下，是否将密码用作加密密钥？

  • 是否使用了未设计满足加密要求的随机性用于加密目的？即使选择了正确的函数，是否需要由开发人员进行种子填充，如果没有，开发人员是否用熵/不可预测性不足的种子覆盖了其内置的强大种子填充功能？

  • 是否使用了已弃用的哈希函数（如 MD5 或 SHA1），或在需要加密哈希函数时使用了非加密哈希函数？

  • 是否使用了已弃用的加密填充方法（如 PKCS 1 v1.5）？

  • 加密错误消息或侧信道信息是否可被利用，例如以填充预言攻击的形式？

OWASP 建议

至少执行以下操作，并参考相关资料：

  • 对应用程序处理、存储或传输的数据进行分类。根据隐私法、监管要求或业务需求识别哪些数据是敏感的。

  • 不要不必要地存储敏感数据。应尽快丢弃或使用符合 PCI DSS 的令牌化甚至截断。未保留的数据无法被窃取。

  • 确保对所有静态的敏感数据进行加密。

  • 确保使用最新且强大的标准算法、协议和密钥；使用适当的密钥管理。

  • 使用安全协议（如具有前向保密 (FS) 密码、由服务器优先选择密码和安全参数的 TLS）对所有传输中的数据进行加密。使用 HTTP 严格传输安全 (HSTS) 等指令强制执行加密。

  • 禁用包含敏感数据的响应的缓存。

  • 根据数据分类应用所需的安全控制。

  • 不要使用 FTP 和 SMTP 等旧版协议来传输敏感数据。

  • 使用具有工作因子（延迟因子）的强自适应和加盐哈希函数存储密码，例如 Argon2、scrypt、bcrypt 或 PBKDF2。

  • 必须为操作模式选择合适的初始化向量。 对于许多模式，这意味着使用 CSPRNG（密码学安全的伪随机数生成器）。对于需要 nonce 的模式，初始化向量 (IV) 不需要 CSPRNG。在所有情况下，对于固定的密钥，IV 都不应使用两次。

  • 始终使用认证加密，而不仅仅是加密。

  • 密钥应通过密码学方式随机生成，并以字节数组形式存储在内存中。如果使用了密码，则必须通过适当的密码派生密钥函数将其转换为密钥。

  • 确保在适当的地方使用密码学随机性，并且它没有以可预测的方式或低熵进行种子填充。大多数现代 API 不需要开发人员为 CSPRNG 填充种子即可获得安全性。

  • 避免使用已弃用的密码学函数和填充方案，例如 MD5、SHA1、PKCS 1 v1.5。

  • 独立验证配置和设置的有效性。

CodeIgniter 应对措施

A03:2021 注入

当应用程序出现以下情况时，容易受到攻击：

  • 应用程序未对用户提供的数据进行验证、过滤或净化。

  • 在解释器中直接使用动态查询或无参数化调用，且未进行上下文感知的转义。

  • 在对象关系映射 (ORM) 搜索参数中使用恶意数据以提取额外的敏感记录。

  • 直接使用或连接恶意数据。SQL 或命令在动态查询、命令或存储过程中包含结构和恶意数据。

一些更常见的注入类型包括 SQL、NoSQL、操作系统命令、对象关系映射 (ORM)、LDAP，以及表达式语言 (EL) 或对象图导航库 (OGNL) 注入。所有解释器的概念都是相同的。代码审查是检测应用程序是否易受注入攻击的最佳方法。 强烈建议对所有参数、头部、URL、Cookie、JSON、SOAP 和 XML 数据输入进行自动化测试。组织可以将静态 (SAST)、动态 (DAST) 和交互式 (IAST) 应用程序安全测试工具集成到 CI/CD 管道中，以在生产部署前识别引入的注入缺陷。

OWASP 建议

防止注入需要将数据与命令和查询分开：

  • 首选方法是使用安全的 API，它完全避免使用解释器，提供参数化接口，或迁移到对象关系映射工具 (ORMs)。

    • 注意：即使使用了参数化，如果 PL/SQL 或 T-SQL 连接查询和数据，或使用 EXECUTE IMMEDIATE 或 exec() 执行恶意数据，存储过程仍可能引入 SQL 注入。

  • 使用白名单式/肯定式服务器端输入验证。由于许多应用程序需要特殊字符（如文本区域或移动应用程序的 API），这并非完整的防御措施。

  • 对于任何剩余的动态查询，使用该解释器特定的转义语法来转义特殊字符。

    • 注意：表名、列名等 SQL 结构无法被转义，因此用户提供的结构名称是危险的。这是报表编写软件中的一个常见问题。

  • 在查询中使用 LIMIT 和其他 SQL 控制，以防止在发生 SQL 注入时大量泄露记录。

CodeIgniter 应对措施

A04:2021 不安全的设计

不安全的设计是一个广泛的类别，代表不同的弱点，表现为“缺少或无效的控制设计”。不安全的设计并非所有其他十大风险类别的根源。不安全的设计与不安全的实现之间存在区别。我们之所以区分设计缺陷和实现缺陷，是因为它们有不同的根本原因和补救措施。

一个安全的设计仍可能存在导致漏洞的实现缺陷，这些漏洞可能被利用。不安全的设计无法通过完美的实现来修复，因为根据定义，必要的安全控制从未被创建以防御特定攻击。导致不安全设计的因素之一是所开发的软件或系统中固有的业务风险画像缺失， 从而导致无法确定所需的安全设计级别。

OWASP 建议

  • 建立并使用安全的开发生命周期，与应用安全 (AppSec) 专业人员合作， 以帮助评估和设计安全与隐私相关的控制

  • 建立并使用安全设计模式库或可直接使用的组件库

  • 对关键的身份验证、访问控制、业务逻辑和关键流程使用威胁建模

  • 将安全语言和控制集成到用户故事中

  • 在应用程序的每一层（从前端到后端）集成合理性检查

  • 编写单元和集成测试，以验证所有关键流程对威胁模型的抵抗力。为应用程序的每一层编译用例和误用例。

  • 根据暴露和保护需求，在系统和网络层上隔离各层

  • 在所有层中通过设计稳健地隔离租户

  • 按用户或服务限制资源消耗

CodeIgniter 应对措施

A05:2021 安全配置错误

如果应用程序出现以下情况，则可能易受攻击：

  • 在应用程序堆栈的任何部分缺少适当的安全加固， 或云服务上的权限配置不当。

  • 启用了不必要的功能或安装了不必要的功能（例如，不必要的端口、服务、页面、账户或权限）。

  • 默认账户及其密码仍然启用且未更改。

  • 错误处理向用户显示堆栈跟踪或其他过于详细的信息。

  • 对于升级的系统，最新的安全功能被禁用或未安全配置。

  • 应用程序服务器、应用程序框架（例如，Struts、Spring、ASP.NET）、库、数据库等的安全设置未设置为安全值。

  • 服务器未发送安全头或指令，或未将其设置为安全值。

  • 软件已过时或存在漏洞（参见 A06:2021-易受攻击和过时的组件）。

如果没有一个协调一致、可重复的应用程序安全配置流程， 系统将面临更高的风险。

OWASP 建议

应实施安全的安装流程，包括：

  • 一个可重复的加固流程，使其能够快速轻松地部署另一个适当锁定的环境。 开发、QA 和生产环境应全部进行相同的安全加固配置，但在每个环境中使用不同的凭据。 此流程应自动化，以最小化设置新安全环境所需的工作量。

  • 一个不包含任何不必要功能、组件、文档和示例的最小化平台。 移除或不安装未使用的功能和框架。

  • 一项任务，即作为补丁管理流程的一部分， 审查和更新与所有安全说明、更新和补丁相对应的配置（参见 A06:2021-易受攻击和过时的组件）。 审查云存储权限（例如，S3 存储桶权限）。

  • 一个分段的应用程序架构， 通过分段、容器化或云安全组 (ACLs) 在组件或租户之间提供有效且安全的隔离。

  • 向客户端发送安全指令，例如，安全头。

  • 一个自动化流程，以验证所有环境中配置和设置的有效性。

CodeIgniter 应对措施

A06:2021 易受攻击和过时的组件

你很可能存在漏洞：

  • 如果你不知道所使用的所有组件的版本（包括客户端和服务器端）。这包括你直接使用的组件以及嵌套的依赖项。

  • 如果软件存在漏洞、不受支持或已过时。这包括操作系统、Web/应用程序服务器、数据库管理系统 (DBMS)、应用程序、API 以及所有组件、运行时环境和库。

  • 如果你没有定期扫描漏洞，并订阅与所用组件相关的安全公告。

  • 如果你没有以基于风险的、及时的方式修复或升级底层平台、框架和依赖项。这在补丁是受变更控制的月度或季度任务的环境中很常见， 使组织面临数天或数月的不必要暴露于已修复的漏洞。

  • 如果软件开发人员没有测试更新、升级或打补丁的库的兼容性。

  • 如果你没有保护组件的配置（参见 A05:2021-安全配置错误）。

OWASP 建议

应建立一个补丁管理流程，包括：

  • 移除未使用的依赖项、不必要的功能、组件、文件和文档。

  • 使用版本、OWASP Dependency Check、retire.js 等工具， 持续清点客户端和服务器端组件（例如，框架、库）及其依赖项的版本。 持续监控 Common Vulnerability and Exposures (CVE) 和 National Vulnerability Database (NVD) 等来源， 以发现组件中的漏洞。使用软件成分分析工具来自动化该流程。 订阅与你所用组件相关的安全漏洞的电子邮件警报。

  • 仅通过安全链接从官方来源获取组件。优先选择签名包，以降低包含被修改的恶意组件的可能性（参见 A08:2021-软件和数据完整性失败）。

  • 监控未被维护或不为旧版本创建安全补丁的库和组件。如果无法打补丁， 考虑部署虚拟补丁以监控、检测或保护免受已发现的问题。

每个组织必须确保有一个持续的计划，用于在应用程序或组合的生命周期内监控、分类和应用更新或配置更改。

CodeIgniter 应对措施

  • 通过 Composer 轻松 升级

A07:2021 身份识别和认证失败

确认用户身份、认证和会话管理对防御认证相关攻击至关重要。如果应用程序：

  • 允许自动化攻击，例如凭据填充（攻击者拥有一份有效的用户名和密码列表）。

  • 允许暴力破解或其他自动化攻击。

  • 允许使用默认、弱或众所周知的密码，例如 "Password1" 或 "admin/admin"。

  • 使用弱或无效的凭据恢复和忘记密码流程， 例如“基于知识的答案”，这些无法确保安全。

  • 使用明文、加密或弱哈希的密码数据存储（参见 A02:2021-加密失败）。

  • 缺少或多因素认证无效。

  • 在 URL 中暴露会话标识符。

  • 成功登录后重用会话标识符。

  • 未正确使会话 ID 失效。用户会话或认证令牌（主要是单点登录 (SSO) 令牌） 在注销或一段时间不活动期间未被正确失效。

OWASP 建议

  • 在可能的情况下，实施多因素认证， 以防止自动化的凭据填充、暴力破解和被盗凭据重用攻击。

  • 不要使用任何默认凭据进行发布或部署，特别是管理员用户。

  • 实施弱密码检查，例如将新密码或更改的密码与最差的 10,000 个密码列表进行测试。

  • 使密码长度、复杂性和轮换策略符合美国国家标准与技术研究院 (NIST) 800-63b 第 5.1.1 节关于“记忆密钥”的指南， 或其他现代、基于证据的密码策略。

  • 确保注册、凭据恢复和 API 路径通过为所有结果使用相同的消息来强化， 以防御账户枚举攻击。

  • 限制或逐步延迟失败的登录尝试，但要小心不要造成拒绝服务场景。 记录所有失败，并在检测到凭据填充、暴力破解或其他攻击时向管理员发出警报。

  • 使用服务器端安全的内置会话管理器，在登录后生成一个高熵的随机会话 ID。 会话标识符不应在 URL 中，应安全存储，并在注销、空闲和绝对超时后失效。

CodeIgniter 应对措施

A08:2021 软件和数据完整性失败

软件和数据完整性失败涉及代码和基础设施， 它们无法防止完整性违规。一个例子是应用程序依赖于来自不可信来源、仓库和内容分发网络 (CDN) 的插件、库或模块。 一个不安全的 CI/CD 管道可能导致未经授权访问、恶意代码或系统被攻陷。

最后，许多应用程序现在包含自动更新功能， 更新在没有充分完整性验证的情况下被下载并应用于先前受信任的应用程序。 攻击者可能上传他们自己的更新程序， 以便在所有安装中分发和运行。

另一个例子是对象或数据被编码或序列化为攻击者可以查看和修改的结构， 这容易受到不安全反序列化的影响。

OWASP 建议

  • 使用数字签名或类似机制来验证软件或数据来自预期来源且未被篡改。

  • 确保库和依赖项（如 npm 或 Maven）从受信任的仓库获取。 如果你的风险状况较高，考虑托管一个经过审查的内部已知良好仓库。

  • 确保使用软件供应链安全工具（如 OWASP Dependency Check 或 OWASP CycloneDX）来验证组件是否不包含已知漏洞。

  • 确保有代码和配置变更的审查流程， 以最小化恶意代码或配置被引入软件管道的可能性。

  • 确保你的 CI/CD 管道具有适当的隔离、配置和访问控制， 以确保流经构建和部署过程的代码的完整性。

  • 确保未签名或未加密的序列化数据不会在没有某种完整性检查或数字签名的情况下发送给不可信客户端， 以检测对序列化数据的篡改或重放。

CodeIgniter 应对措施

  • 暂无

A09:2021 安全日志记录和监控失败

此类别旨在帮助检测、上报和响应主动的入侵行为。没有日志记录和监控，就无法检测到入侵。 每当出现以下情况时，就会发生日志记录、检测、监控和主动响应不足：

  • 未记录可审计的事件，例如登录、登录失败和高价值交易。

  • 警告和错误未生成、生成了不充分或不清晰的日志消息。

  • 未监控应用程序和 API 的日志以发现可疑活动。

  • 日志仅存储在本地。

  • 未建立或无效的适当警报阈值和响应上报流程。

  • 渗透测试和动态应用程序安全测试 (DAST) 工具（如 OWASP ZAP）的扫描不会触发警报。

  • 应用程序无法实时或近实时地检测、上报或警报主动攻击。

如果将日志记录和警报事件暴露给用户或攻击者（参见 A01:2021-访问控制失效），你就可能会受到信息泄露的影响。

OWASP 建议

开发人员应根据应用程序的风险实施以下部分或全部控制措施：

  • 确保所有登录、访问控制和服务器端输入验证失败都能被记录， 包含足够的用户上下文以识别可疑或恶意账户， 并保留足够长的时间以允许延迟的取证分析。

  • 确保日志以日志管理解决方案可轻松解析/消费的格式生成。

  • 确保日志数据被正确编码，以防止对日志或监控系统进行注入或攻击。

  • 确保高价值交易具有带有完整性控制的审计跟踪， 以防止篡改或删除，例如仅追加的数据库表或类似机制。

  • DevSecOps 团队应建立有效的监控和警报， 以便快速检测和响应可疑活动。

  • 建立或采用事件响应和恢复计划，例如美国国家标准与技术研究院 (NIST) 800-61r2 或更高版本。

存在商业和开源的应用保护框架，如 OWASP ModSecurity 核心规则集，以及开源日志关联软件，如 Elasticsearch、Logstash、Kibana（ELK）堆栈，具有自定义仪表板和警报功能。

CodeIgniter 应对措施

A10:2021 服务端请求伪造 (SSRF)

每当 Web 应用程序在未验证用户提供的 URL 的情况下获取远程资源时，就会出现 SSRF 缺陷。 它允许攻击者强迫应用程序将精心制作的请求发送到意外的目的地， 即使受到防火墙、VPN 或其他类型的网络访问控制列表 (ACL) 保护也是如此。

由于现代 Web 应用程序为最终用户提供便利的功能，获取 URL 已成为一种常见场景。 因此，SSRF 的发生率正在增加。此外，由于云服务和架构的复杂性，SSRF 的严重性也在提高。

OWASP 建议

开发人员可以通过实施以下部分或全部纵深防御控制来防止 SSRF：

从网络层：

  • 将远程资源访问功能隔离在单独的网络中，以减少 SSRF 的影响

  • 强制执行“默认拒绝”的防火墙策略或网络访问控制规则， 以阻止除必要内网流量外的所有流量。

    • 提示：

      • 基于应用程序建立防火墙规则的所有权和生命周期。

      • 在防火墙上记录所有接受和阻止的网络流 （参见 A09:2021-安全日志记录和监控失败）。

从应用层：

  • 净化并验证所有客户端提供的输入数据

  • 使用白名单对 URL 协议、端口和目标进行强制规定

  • 不要向客户端发送原始响应

  • 禁用 HTTP 重定向

  • 注意 URL 的一致性，以避免 DNS 重绑定和“检查时间与使用时间”(TOCTOU) 竞态条件等攻击

不要通过使用黑名单或正则表达式来缓解 SSRF。攻击者拥有有效载荷列表、工具和技能来绕过黑名单。

CodeIgniter 应对措施

OWASP API 安全十大风险 2023

API1:2023 对象级别授权失效

API 倾向于暴露处理对象标识符的端点， 从而创建了一个广泛的对象级访问控制问题攻击面。 在每个使用用户提供的 ID 访问数据源的函数中，都应考虑对象级授权检查。

OWASP 建议

  • 实施一个依赖于用户策略和层级的适当授权机制。

  • 在每个使用客户端输入访问数据库中记录的函数中， 使用授权机制检查登录用户是否有权对记录执行请求的操作。

  • 优先使用随机且不可预测的值作为记录 ID 的 GUID。

  • 编写测试以评估授权机制的漏洞。不要部署导致测试失败的更改。

CodeIgniter 应对措施

API2:2023 认证失效

认证机制通常实施不当， 使攻击者能够破坏认证令牌或利用实现缺陷来临时或永久地冒充其他用户的身份。 破坏系统识别客户端/用户的能力， 就破坏了 API 安全的整体性。

OWASP 建议

  • 确保你了解所有可能的 API 认证流程（例如实现一键认证的移动/Web/深度链接等）。询问你的工程师是否遗漏了什么流程。

  • 了解你的认证机制。确保你理解它们是什么以及如何使用。OAuth 不是认证，API 密钥也不是。

  • 不要在认证、令牌生成或密码存储方面重新发明轮子。使用标准。

  • 凭据恢复/忘记密码端点在暴力破解、频率限制和锁定保护方面应被视为登录端点。

  • 对敏感操作要求重新认证（例如，更改账户所有者邮箱地址/2FA 电话号码）。

  • 使用 OWASP 认证速查表。

  • 在可能的情况下，实施多因素认证。

  • 实施反暴力破解机制，以缓解在认证端点上的凭据填充、字典攻击和暴力破解攻击。该机制应比 API 上的常规频率限制机制更严格。

  • 实施账户锁定/Captcha 机制以防止针对特定用户的暴力破解攻击。实施弱密码检查。

  • API 密钥不应用于用户认证。它们仅应用于 API 客户端认证。

CodeIgniter 应对措施

API3:2023 对象属性级别授权失效

此类别结合了 API3:2019 过度数据暴露和 API6:2019 - 批量赋值， 聚焦于根本原因：缺少或不当的对象属性级授权验证。 这会导致信息被未经授权的方暴露或操纵。

OWASP 建议

  • 当通过 API 端点暴露对象时， 务必确保用户有权访问你暴露的对象属性。

  • 避免使用 to_json() 和 to_string() 等通用方法。 相反，应精确选取你明确希望返回的特定对象属性。

  • 如果可能，避免使用将客户端输入自动绑定到代码变量、内部对象或对象属性的函数（"批量赋值"）。

  • 仅允许客户端更新对象中应被其更新的属性。

  • 实施基于模式的响应验证机制作为额外的安全层。 作为该机制的一部分，定义并强制执行所有 API 方法返回的数据。

  • 根据端点的业务/功能需求， 将返回的数据结构保持在最低限度。

CodeIgniter 应对措施

API4:2023 未受限的资源消耗

满足 API 请求需要网络带宽、CPU、内存和存储等资源。 其他资源（如电子邮件/SMS/电话呼叫或生物识别验证） 由服务提供商通过 API 集成提供，并按请求付费。 成功的攻击可能导致拒绝服务或运营成本增加。

OWASP 建议

  • 使用一种能够轻松限制内存、CPU、重启次数、文件描述符和进程（如容器/无服务器代码（例如 Lambdas））的解决方案。

  • 为所有传入参数和有效载荷定义并强制执行最大数据大小， 例如字符串的最大长度、数组中元素的最大数量以及上传文件的最大大小（无论是在本地还是在云存储中存储）。

  • 在定义的时间范围内， 实施对客户端与 API 交互频率的限制（频率限制）。

  • 频率限制应根据业务需求进行微调。某些 API 端点可能需要更严格的策略。

  • 限制/节流单个 API 客户端/用户执行单个操作的次数或频率 （例如，验证一次性密码 (OTP) 或请求密码恢复而不访问一次性 URL）。

  • 为查询字符串和请求体参数添加适当的服务器端验证， 特别是控制响应中返回记录数量的参数。

  • 为所有服务提供商/API 集成配置支出限额。当无法设置支出限额时， 应配置账单警报。

CodeIgniter 应对措施

API5:2023 功能级别授权失效

具有不同层级、组和角色的复杂访问控制策略， 以及管理功能和常规功能之间不清晰的分离， 往往会导致授权缺陷。通过利用这些问题， 攻击者可以获得对其他用户资源和/或管理功能的访问。

OWASP 建议

你的应用程序应有一个一致且易于分析的授权模块， 该模块从所有业务功能中调用。通常， 此类保护由一个或多个应用程序代码外部的组件提供。

  • 执行机制应默认拒绝所有访问， 要求对每个功能的访问都必须明确授予特定角色。

  • 在审查 API 端点时， 要针对功能级别授权缺陷，同时牢记应用程序的业务逻辑和组层级。

  • 确保所有管理控制器都继承自一个实现基于用户组/角色的授权检查的管理抽象控制器。

  • 确保在常规控制器内的管理功能实现基于用户组和角色的授权检查。

CodeIgniter 应对措施

API6:2023 对敏感业务流程的未受限访问

易受此风险影响的 API 暴露了业务流程（例如购买票务或发表评论）， 而没有考虑到该功能在自动化方式下被过度使用时可能对业务造成的损害。 这不一定源于实现缺陷。

OWASP 建议

缓解计划应在两个层面进行：

  • 业务层面 - 识别如果被过度使用可能对业务造成损害的业务流程。

  • 工程层面 - 选择合适的保护机制来缓解业务风险。

一些保护机制更简单，而另一些则更难实现。 以下方法用于减缓自动化威胁：

  • 设备指纹识别：拒绝向意外的客户端设备（例如无头浏览器）提供服务， 这会促使威胁行为者使用更复杂的解决方案， 从而增加他们的成本

  • 人类检测：使用 Captcha 或更高级的生物识别解决方案（例如打字模式）

  • 非人类模式：分析用户流程以检测非人类模式 （例如，用户在不到一秒钟内访问了“添加到购物车”和“完成购买”功能）

  • 考虑阻止 Tor 出口节点和知名代理的 IP 地址

保护并限制机器直接消费的 API（例如开发者和 B2B API）的访问。 它们往往是攻击者的易受攻击目标， 因为它们通常没有实施所有必需的保护机制。

CodeIgniter 应对措施

  • 暂无

API7:2023 服务端请求伪造

当 API 在未验证用户提供的 URI 的情况下获取远程资源时， 可能会发生服务端请求伪造 (SSRF) 缺陷。 这使攻击者能够强迫应用程序将精心制作的请求发送到意外的目的地， 即使受到防火墙或 VPN 保护也是如此。

OWASP 建议

  • 在网络中隔离资源获取机制：通常这些功能旨在检索远程资源，而非内部资源。

  • 在可能的情况下，使用以下项目的白名单：

    • 用户预期从其下载资源的远程来源（例如 Google Drive、Gravatar 等）

    • URL 协议和端口

    • 特定功能接受的媒体类型

  • 禁用 HTTP 重定向。

  • 使用经过充分测试和维护的 URL 解析器， 以避免因 URL 解析不一致而导致的问题。

  • 验证并净化所有客户端提供的输入数据。

  • 不要向客户端发送原始响应。

CodeIgniter 应对措施

API8:2023 安全配置错误

API 及其支持系统通常包含复杂的配置， 旨在使 API 更具可定制性。软件和 DevOps 工程师可能忽略这些配置， 或在配置时未遵循安全最佳实践， 从而为不同类型的攻击打开了大门。

OWASP 建议

API 生命周期应包括：

  • 一个可重复的加固流程， 以实现快速轻松地部署一个适当锁定的环境

  • 一项任务，即审查和更新整个 API 堆栈的配置。 审查应包括：编排文件、API 组件和云服务（例如 S3 存储桶权限）

  • 一个自动化流程， 以持续评估所有环境中配置和设置的有效性

此外：

  • 确保从客户端到 API 服务器以及任何下游/上游组件的所有 API 通信都通过加密通信通道 (TLS) 进行， 无论 API 是内部的还是面向公众的。

  • 明确每个 API 可以通过哪些 HTTP 动词访问：应禁用所有其他 HTTP 动词（例如 HEAD）。

  • 期望从基于浏览器的客户端（例如 WebApp 前端）访问的 API 应至少：

    • 实施适当的跨域资源共享 (CORS) 策略

    • 包含适用的安全头

  • 将传入的内容类型/数据格式限制为符合业务/功能要求的类型。

  • 确保 HTTP 服务器链中的所有服务器（例如负载均衡器、反向和正向代理以及后端服务器）以统一的方式处理传入请求， 以避免不同步问题。

  • 在适用的情况下，定义并强制执行所有 API 响应有效载荷模式， 包括错误响应，以防止异常跟踪和其他有价值的信息被发送回攻击者。

CodeIgniter 应对措施

API9:2023 不当的资产管理

API 倾向于比传统 Web 应用程序暴露更多的端点， 因此正确且最新的文档变得非常重要。 正确地对主机和已部署的 API 版本进行清点也至关重要， 以缓解诸如已弃用的 API 版本和暴露的调试端点等问题。

OWASP 建议

  • 清点所有 API 主机，并记录每个主机的重要方面， 重点关注 API 环境（例如生产、预发布、测试、开发）、 谁应拥有对主机的网络访问权限（例如公开、内部、合作伙伴）以及 API 版本。

  • 清点集成服务，并记录其重要方面， 例如它们在系统中的角色、交换的数据（数据流）以及它们的敏感性。

  • 记录 API 的所有方面， 例如认证、错误、重定向、频率限制、跨域资源共享 (CORS) 策略和端点， 包括它们的参数、请求和响应。

  • 通过采用开放标准自动生成文档。将文档构建包含在你的 CI/CD 管道中。

  • 仅向有权使用 API 的人员提供 API 文档。

  • 对所有暴露的 API 版本（而不仅仅是当前生产版本）使用外部保护措施， 例如特定的 API 安全解决方案。

  • 避免在非生产 API 部署中使用生产数据。如果无法避免， 这些端点应获得与生产环境相同的安全待遇。

  • 当 API 的新版本包含安全改进时， 执行风险分析以告知对旧版本所需采取的缓解措施。 例如，是否可以在不破坏 API 兼容性的情况下将改进回迁， 或者你是否需要快速淘汰旧版本并强制所有客户端迁移到最新版本。

CodeIgniter 应对措施

API10:2023 不安全地消费 API

开发人员倾向于比用户输入更信任从第三方 API 接收的数据， 因此往往采用较弱的安全标准。 为了破坏 API， 攻击者会针对集成的第三方服务，而不是直接尝试破坏目标 API。

OWASP 建议

  • 在评估服务提供商时，评估其 API 安全态势。

  • 确保所有 API 交互都通过安全的通信通道 (TLS) 进行。

  • 在使用从集成 API 接收的数据之前， 始终对其进行验证并正确净化。

  • 维护一个集成 API 可能将你的请求重定向到的知名位置的白名单：不要盲目地跟随重定向。

CodeIgniter 应对措施