owasp top 10的思考

1. 失效的访问控制

概述

• 访问控制实施策略以防止用户超出其指定权限范围进行操作。

• 由于访问漏洞，未经身份验证或不受欢迎的用户可能会访问机密数据和进程以及用户权限设置。

• 元数据操作，包括篡改或重放 JSON Web 令牌 (JWT) 访问控制令牌，或修改 cookie 或隐藏字段以提高权限或利用 JWT 失效，都是访问控制漏洞的一个示例。

• 第二个例子是违反默认拒绝原则。必须仅向特定角色、能力或用户授予访问权限，但每个人都可以访问。此类错误可能使攻击者可以轻松访问他们想要的一切。

防御手段

1. 多因素身份验证
2. 仅强制执行一次访问控制机制，并在应用程序期间重复使用它们，以减少跨域资源共享
3. 限制对应用程序编程接口 (API) 和控制器的访问，以减轻自动攻击工具的影响。
4. 在访问控制中记录故障并根据需要向管理员发出警报。
5. 模型访问控制必须强制执行记录所有权，而不是授予用户创建、查看、修改或删除任何信息的权限。

---

2. 加密机制失效

概述

• 加密机制失效重点在于经常暴露敏感数据的密码错误或缺少密码错误

• 应用程序可以使用自动数据库加密来安全地加密信用卡数据。不幸的是，当访问此信息时，它会立即未加密，从而导致 SQL 注入错误以明文形式提取信用卡信息，入侵者可能会利用这些信息。

防御手段

1. 使用加盐和哈希算法存储密码
2. 不使用明文传输的协议传输敏感数据

---

3. 注入

概述

• 注入（或SQL 注入）是针对网站的数据库攻击，该网站使用结构化查询语言 (SQL) 来获取信息或执行通常需要经过身份验证的用户帐户的活动。程序很难从自己的代码中解释这些代码，从而允许攻击者进行注入攻击以访问受保护区域和伪装成受信任用户的敏感数据。

• 注入包括SQL注入、命令注入、CRLF注入、LDAP注入等

防御手段

1. 根据业务特性进行针对性转义 例如有业务需求需要输入特殊字符，但为了防御XSS注入等注入；根据HTML特性先解析实体编码的特性在解析实体编码后再进行转义
2. 在查询中使用 LIMIT和其他 SQL 约束避免 SQL 注入情况下大量数据暴露

---

4. 不安全的设计

概述

• 不安全的设计是一个广泛的类别，包含各种问题，例如“缺失或不充分的控制设计”。这并不意味着不安全的设计是所有其他十大风险类别的根源。

• 不安全的设计与不安全的实现不同。即使设计是安全的，实施缺陷也可能导致漏洞。另一方面，有缺陷的设计不能通过完美的实现来弥补，因为不存在必要的安全保护措施来防御特定的威胁。

防御手段

1. SDL安全开发周期
2. 对关键验证、访问控制、应用程序逻辑和基本流程进行威胁建模

---

5. 安全配置错误

概述

• 一般的安全设置问题，就像配置错误的访问控制一样，通过为攻击者提供对关键数据和站点区域的快速和轻松的访问而造成重大危险。

---

6. 易受攻击和过时的组件

概述

• 大多数在线应用程序都是在第三方框架的帮助下创建的。未知的应用程序代码可能会导致不良结果和不良情况，例如违反口音控制、SQL 注入等。

• 如果程序不安全、不受支持或过时，则可能存在与漏洞相关的危害。该软件包包括应用程序/Web 服务器、操作系统、应用程序、数据库管理系统 (DBMS)、API、其他元素、库和运行时环境。

• 自动化方法可帮助攻击者找到配置不当或未打补丁的机器。例如，Shodan IoT 搜索引擎可以帮助用户发现易受 Heartbleed 威胁的设备，该威胁已于 2014 年 4 月修复。

防御方法

1. 留意那些不起作用或不为旧版本提供安全更新的模块和元素。如果无法进行修补，请考虑开发虚拟补丁来观察、识别或防范观察到的漏洞。
2. 删除任何过多的要求、功能、元素、文件夹或文档。
3. 即时更新

---

7. 识别和认证失败

概述

• 现在包含与识别问题相关的 CWE。当攻击者获取用户信息、密码恢复、ID 会话和其他登录凭据时，就会产生安全问题。顾名思义，身份和身份验证失败包括黑客利用此类漏洞利用身份验证不足。

• 如果应用程序允许自动攻击，例如凭证填充（当攻击者可以访问真实用户和密码列表）或预定义的、较弱的和常见的密码（例如“Password1”或“admin/admin”），这些可能是身份验证缺陷的迹象

防御手段

1. 必须在可行的情况下使用多因素身份验证，以避免自动凭证填充、暴力攻击和被盗凭证的重复使用。
2. 通过对照包含 10,000 个最差密码的数据库检查新密码或修改密码，可以提高密码安全性。
3. 对每个结果使用相同的消息有助于防止对密码恢复、注册和 API 路径的帐户枚举攻击。
4. 不要安装任何默认凭据，尤其是对于管理用户。

---

8. 软件和数据完整性故障

概述

• 随着越来越多的敏感信息存储在数据库中，容易受到安全漏洞的影响，数据完整性问题对于软件来说变得至关重要。

• 这是一个新类别，它侧重于假设软件更新、重要数据和 CI/CD 程序的完整性，而无需对其进行验证。一个例子是当应用程序使用来自内容交付网络 (CDN) 或未经授权的来源的扩展、模块或存储库时。未受保护的持续集成/持续交付 ( CI/CD ) 流程可能会增加恶意代码、系统受损或未经授权访问的风险。

防御手段

1. 人们可能会使用诸如数字签名之类的措施来确认数据或软件来自预期的来源而没有任何篡改。
2. 软件供应链的安全工具，如 OWASP CycloneDX 或 OWASP Dependency-Check，可用于保证组件不包含设计缺陷。
3. 有必要确保 CI/CD 工作流具有所需的分段、访问控制和参数化，以在整个设置和部署操作过程中保护代码完整性。
4. 未经签名或未加密的编译数据不应发送给不受信任的客户端，除非已进行完整性测试或数字签名以识别数据更改或重复。

---

9. 安全日志记录和监控失败

概述

• 在存在可疑行为和事件的情况下缺乏跟踪可能会扩大不受监控的时间间隔，从而使安全漏洞被忽视的时间比使用更好的日志记录的时间更长。

• 如果没有记录和监控，就不可能检测到安全漏洞。

防御手段

1. 确认所有身份验证、访问安全系统和服务器端数据验证问题都记录有足够的用户信息，以检测可疑或欺诈帐户，并存储足够长的时间以进行延迟的全面调查。
2. 确保以日志管理系统可使用的格式创建日志。
3. 创建或应用用于事件恢复和响应工作的策略。
4. 确保对日志数据进行适当编码，以避免对监控系统的入侵或网络威胁。

---

10.服务器端请求伪造

概述

• 该类别的结果显示了高于平均水平的测试覆盖率、合理的低发生率以及高于平均水平的影响和利用评级。SSRF 是在服务器端查询未验证用户提供的 URL 的情况下开发的。这允许攻击者诱使应用程序将伪造请求传输到不希望的位置，即使该位置受到虚拟专用网络 (VPN)、防火墙或网络访问控制列表 (ACL) 的保护。

• 随着新的在线应用程序为最终用户提供方便的功能，获取 URL 已成为一种典型情况。因此，SSRF 患病率正在增加。此外，由于云服务和设计复杂性，SSRF 的强度正在增加。

防御手段

1. 为了限制 SSRF 的影响，应该将远程资源访问功能分离到不同的网络中。
2. 安装“默认拒绝”防火墙设置或网络访问控制规则，以阻止除必需的内部流量外的所有 Web 流量。
3. 在 (TOCTOU) 情况下，为了防止 DNS 重新映射和“检查时间、使用时间”等攻击，最好注意 URL 的准确性。