学完本课程后，你将能够：
- 识别并减少身份识别和身份验证错误
- 识别并减少软件和数据完整性故障
- 识别并减少安全日志记录和监控故障
- 识别并减少服务器端请求伪造
1.失效的访问控制
“访问控制”是一项安全准则，用于确保人员和自动化进程拥有特定、预期和授权的资源访问权限。当人员或自动化进程无视预期的访问控制策略而获得访问权限时，就会出现失效的访问控制风险。
常见原因有哪些？–
- 人为错误，比如：
- 用户公开敏感数据且不加以保护
- 错误分类或无意间解密敏感数据
- 主机、Web 服务器、防火墙、数据库等配置错误
- 应用程序代码中的授权检查存在缺陷或不够充分
- 不同类别或具有不同重要性的数据之间缺少保护性隔离，比如：
- 将多个租户的敏感数据存储在同一文件系统中
- 将财务数据与用户首选项数据存储在同一数据库中
如何避免这种风险？–
- 在实施前执行正式的威胁建模以发现设计缺陷
- 确保访问控制用例涵盖单元测试、集成测试和用户验收测试
- 打包安全配置，作为默认的部署配置
- 使用集中的身份和访问管理，以一致的方式应用访问决策
- 面向失败的设计：预测人为错误并降低出现错误的可能性和影响
2.加密机制失效
当数据的机密性或完整性受到破坏时，就会出现加密机制失效情况。机密性是一种对数据保密的能力，而完整性是一种证明数据真实性的能力
常见原因有哪些？–
- 主机、Web 服务器、防火墙、数据库等配置错误
- 使用不安全的协议传输敏感数据，如 HTTP、SMTP、FTP
- 通过文件系统权限、电子邮件或 git 提交意外泄露加密密钥
- 加密库的实施或配置不正确
- 未使用或正确实施数字签名
- 使用过时、已破解或自定义的加密算法
- 使用弱密钥或未通过安全方式生成的密钥
- 使用自签名证书而非适当的 PKI 证书管理
如何避免这种风险？–
- 在实施前执行正式的威胁建模以发现设计缺陷
- 始终保护私钥安全 — 制定严格的密钥处理政策并遵守这些政策
- 始终对静态数据和传输中的数据使用加密和数字签名
- 每小时扫描一次端点，确保配置始终安全
- 仅使用批准的加密库和配置
3.注入
当应用程序使用错误的关于输入安全性的假设来处理外部输入时，这称为注入漏洞。威胁主体可以利用此类漏洞来操纵应用程序以非预期和不安全的方式运行。
常见原因有哪些？–
- 对人为输入的验证不充分
- 依赖输入源的可信度
- 未能识别潜在的输入注入源
- 意外暴露未受保护的专用端点
- 渗透测试覆盖范围不足
- 安全测试技术不充分
- 未能正确处理字符编码（如非拉丁字符）
如何避免这种风险？–
- 在实施前执行正式的威胁建模以发现设计缺陷
- 将所有外部应用程序数据输入都视为潜在的恶意输入
- 包括但不限于：HTML 表单输入、文件路径、DNS 响应、HTTP 标头、API 请求/响应、消息队列负载以及数据库结果
- 利用 SAST 和 DAST 安全测试自动化工具
- 定期执行渗透测试，包括注入测试技术和模糊测试技术
4.不安全设计
未考虑项目所有阶段的安全要求是构成不安全设计的要素，这将导致安全缺陷。除技术安全实施和应用程序的安全运行外，必须尽早充分了解业务用例的访问和处理意图。
常见原因有哪些？–
- 将安全注意事项作为“事后补救措施”
- 只关注开发注意事项，而忽略软件供应链、部署以及软件的操作
- 未能将安全用例视为业务需求
- 团队内部缺乏安全意识
- 在开发的所有阶段未能执行威胁建模和其他安全分析
具体存在哪些风险？–
- 无法实现安全标准合规性，如 ISO
- 由于软件本身存在不安全性，因此需要进行成本高昂的返工和持续缓解风险的工作
如何避免这种风险？–
- 在实施前执行正式的威胁建模以发现设计缺陷
- 针对各项工作建立“安全思维”
- 不断学习和应用安全知识
5.安全配置错误
当服务、应用程序或技术具有加强安全性的手段，但由于部署不正确而变得无效时，这称为安全配置错误。安全配置错误往往无法察觉和缓解，因为它们不是天生的设计缺陷，而是软件部署和运行方面的缺陷。
常见原因有哪些？–
- 没有采用默认安全设置设计和运行模式
- 未审查第三方软件包、容器、API 等开箱即用的配置
- 因为应用程序被隐藏了就假设它是安全的（通过隐藏来实现安全性）
- 在正常开发过程中意外还原了代码或配置文件
- 在开发和运行期间缺少对配置的流程控制
- 例如：多个获得授权的人员未经协调更改同一文件
如何避免这种风险？–
- 在实施前执行正式的威胁建模以发现设计缺陷
- 针对生产部署执行经授权的正式渗透测试
- 在所有软件开发和运行阶段遵循一致的安全审查和扫描流程
- 仅使用经过独立安全验证的第三方组件
6.易受攻击和过时的组件
有意或无意使用易受攻击和过时的组件会给 SAP 带来重大风险。一旦漏洞被公开披露和进行修补，一群新的恶意行为者就会了解如何利用漏洞，并迅速将过时的部署作为攻击目标。修补时间对于预防安全事件至关重要。
常见原因有哪些？–
- 失职；假设他人在管理风险
- 低估了未主动监控新的安全补丁公告所带来的风险
- 假设没有人会知道你使用了易受攻击的组件
- 缺少对依赖项和版本的管理，导致难以洞悉风险
- 缺乏足够的时间来修补特定的漏洞风险级别
如何避免这种风险？–
- 对于直接和传递性依赖项，遵循持续的软件更新流程
- 使用有据可查的依赖项管理流程和自动化功能
- 针对生产部署执行经授权的正式渗透测试
- 主动监控安全漏洞公告
7.身份识别和身份验证错误
如果系统错误识别了行为者（无论是人还是机器）并授予非计划的权限，则会发生身份识别和身份验证错误风险。虽然风险发生在权限升级时，但权限降级 也会给用户带来糟糕的体验。
常见原因有哪些？–
- 主机、Web 服务器、防火墙、数据库等配置错误
- 不安全的会话管理（比如：请求重放、枚举、过期很长时间等）
- 混淆身份或权限的系统或应用程序缺陷
- 过于简单的身份验证机制（比如：用户 ID 作为身份验证令牌）
- 使用易受欺骗的身份验证方案（比如：MAC 地址、IP、GPS 等）
- 实施后门访问机制（这是 PSSEC 严格禁止的）
如何避免这种风险？–
- 在实施前执行正式的威胁建模以发现设计缺陷
- 针对生产部署执行经授权的正式渗透测试
- 使用至少两种身份验证方法。
- 用户知道的凭证（密码）；用户拥有的凭证（硬件令牌）；用户的生物特征（生物特征识别）
- 始终使用 SAP 批准的 SSO 集成和提供程序
8.软件和数据完整性故障
在未核实真实性的情况下就假设数据和软件是可靠的，这会导致软件和数据完整性故障。虽然加密签名是确保完整性最安全的方法，但在某些情况下可以使用更简单的完整性检查。可以联系团队的威胁建模负责人，确定正确的方法。
常见原因有哪些？–
- 在未核实真实性的情况下相信代码和数据
- 未遵循“最小权限原则”，授予人员不必要的访问权限，允许他们更改数据或代码
- 运行未签名的代码或反序列化不受信任的有效负载
- 未检查证书是否已吊销
- 使用自签名证书
- 加密机制失效
如何避免这种风险？–
- 在实施前执行正式的威胁建模以发现设计缺陷
- 核实所有代码和所有数据的真实性，不能绝对信任
- 通过 SAP 的可信 CA（证书颁发机构），利用 PKI（公钥基础架构）进行数据和代码签名
9.安全日志记录和监控故障
安全日志记录和监控故障会导致因取证数据不足而无法检测和纠正安全事件。如果没有适当的取证记录和监控，恶意行为者可能会在数月或数年内毫无阻碍地对系统进行无人察觉的攻击。
常见原因有哪些？–
- 安全配置错误（例如，禁用安全日志记录）
- 未能记录足够的详细信息来支持取证调查
- 基于资源类型或请求来源，有选择性地进行日志记录
- 未能以安全的方式存储和传输日志以及监控数据，使其被篡改
具体存在哪些风险？–
- 安全风险长期存在且无法察觉
如何避免这种风险？–
- 在实施前执行正式的威胁建模以发现设计缺陷
- 记录访问所有系统和应用程序资源的“人员”、“内容”、“时间”、“地点”以及“方式”
- 使用面向资源的设计视图将操作映射到数据
10.服务器端请求伪造（SSRF）
操纵远程资源代表攻击者发出请求，这称为服务器端请求伪造（SSRF）。
常见原因有哪些？–
- 在服务器端处理来自不安全或未净化源的数据。示例包括：
- 通过 XXE（XML 外部实体）注入的 XML
- SVG、X/HTML、JSON 和引用外部实体的序列化对象
- EXIF 元数据、REPL 语句、SQL 注入
- 用户提供的 Webhook 回调 URL
- 错误配置可用作开放代理的中间件
- 将攻击者精心编制的公共 DNS 记录解析成内部网络资源
如何避免这种风险？–
- 在实施前执行正式的威胁建模以发现设计缺陷
- 清理所有数据输入，防止处理外部实体或引用
- 对所有应用程序端点（包括内部端点）运用强身份验证和授权
- 始终从受信任区域以外的区域调用用户提供的 Webhook 回调
- 针对用户提供的 URL，禁用受信任区域中的 HTTP 重定向
- 确保主机和容器仅使用 SAP 批准的 DNS 名称服务器
- 定期扫描中间件，检查是否存在开放代理和其他错误配置