A1：注入
简介
将不受信任的数据作为命令或查询的一部分发送到解析器时，注入漏洞产生
注入漏洞通常发生 在SQL、LDAP、XPath或NoSQL查询语句、OS命令、XML解析器、SMTP包头、表达式语句及ORM查询语句中
攻击可以诱使解析器在没有适当授权的情况下执行非预期命令或访问数据
- 导致数据丢失、破坏或泄露给无授权方，缺乏可审计性或是拒绝服务
- 甚至能导致主机被完全接管
防止
将数据与命令语句、查询语句分割开来
- 最佳选择：使用安全的API，完全避免使用解释器，或提供参数化界面的接口，或迁移到ORM或实体框架
- 使用正确的或“白名单”的具有恰当规范化 的输入验证方法有助于防止注入攻击，但这不是一个完整的防御，因为许多应用程序在输入中需要特殊字符，例如文本区域或移动应用程序的API
- 对于任何剩余的动态查询，可以使用该解释器的特定转义语法转义特殊字符——OWASP的Java Enconder
A2：失效的身份认证
简介
通过错误使用应用程序的身份认证和会话管理功能，攻击者能够破译密码、密钥或会话令牌，或利用其它开发缺陷来暂时性或永久性冒充其他用户身份
攻击方式
- 凭证填充（撞库攻击）
- 暴力破解或其他自动攻击
- 默认的、弱的或众所周知的密码
- 使用弱的或失效的验证凭证，忘记密码程序
- 使用明文、加密或弱散列密码
- 缺少或失效的多因素身份验证
- 成功登录后不更新会话ID
- 不正确地使会话ID失效。当用户不活跃时，用户会话或认证令牌（特别是单点登录（SSO）令牌）没有正确注销或失效
防止方式
- 多因素身份验证：防止自动、凭证填充、暴力破解和被盗凭据再利用攻击
- 执行弱密码检查：测试新或变更的密码，以纠正弱密码
- 设置合适的密码长度、复杂性和循环策略
- 确认注册、凭据恢复，通过对所有输出结果使用相同的消息，用以抵御账户枚举攻击
- 限制或逐渐延迟失败的登录尝试。记录所有失败信息并在凭据填充、暴力破解或其他攻击被检测时提醒管理员
- 使用服务器端安全的内置会话管理器，在登录后生成高度复杂的新随机会话ID，会话ID不能再URL中
A3：敏感信息泄露
简介
许多Web应用程序和API都无法正确保护敏感数据，例如：财务数据、医疗数据、个人敏感信息（PII）
攻击者可以通过窃取或修改未加密的数据来实施信用卡诈骗、身份盗窃或其他犯罪行为
未加密的敏感数据容易受到破坏，因此需要对敏感数据加密，包括：
- 传输过程中的数据（是否明文传输）
- 存储的数据（是否被加密）
- 浏览器的交互数据
案例
- 应用程序加密数据库中的信用卡信息，但数据库设置为对信用卡表列的查询进行自动解密，使得SQL注入漏洞能够获得所有信用卡信息的明文
- 需要身份验证的网页都没有使用SSL，攻击者只需要嗅探网络数据流，并窃取已验证者的会话cookie，然后利用cookie执行重放攻击并接管用户会话从而访问用户的隐私数据
- 密码数据库使用unsalted的Hash算法。文件上传漏洞使黑客能够过去密码文件，所有unsalted哈希密码可通过彩虹表暴力破解方式破解
防止
- 对系统处理、存储或传输的数据分类，并根据分类进行访问控制
- 熟悉与敏感数据保护相关的法律和条例，并根据法规要求保护敏感数据
- 对于没必要存放的、重要的敏感数据，应尽快清楚，或者通过PCIDSS（支付行业数据安全标准）标记或拦截
- 确保存储的敏感数据被加密
- 确保使用了最新的、强大的标准算法或密码、参数、协议和密钥，并且密钥管理到位
- 确保传输过程中的数据被加密，如TLS。确保数据加密被强制执行，如HTTP严格安全传输协议（HSTS）
- 禁止缓存包含敏感数据的响应
A4：XML外部实体（XXE）
简介
XXE漏洞（XML外部实体注入攻击）：如果可以上传XML文档或在XML文档中添加恶意内容，通过易受攻击的代码、依赖项，攻击者就能够攻击含有缺陷的XML处理器。
攻击者可以利用外部实体窃取使用URI的文件处理器的内部文件和共享文件、监听内部扫描端口、执行远程代码和实施拒绝服务攻击
XML
- 可扩展标记语言
- 类似HTML
- 设计宗旨是传输数据，而非显示数据
- XML标签没有被预定义，需要自行定义标签
防止
- 尽可能使用简单的数据格式（JSON），避免对敏感数据进行序列化
- 及时修复或更新应用程序或操作系统使用的XML处理器和库
- 在XML解析器中禁用XML外部实体和DTD进程
- 在服务器端实施积极的（白名单）输入验证、过滤和清理
- 验证XML或XSL文件上传功能是否使用XSD验证或其他类似验证方法来验证上传的XML文件
- 使用SAST工具检测源代码中的部分XXE漏洞
- 使用API安全网关、WAF检测、监控和防止XXE攻击
A5：失效的访问控制
简介
未对用户实施恰当的访问控制。
攻击者可以访问未经授权的功能或 数据：
- 访问其他用户账户
- 查看敏感文件
- 修改其他用户的数据
- 更改访问权限等
攻击场景举例
应用程序再访问账户信息的SQL调用中使用未经验证的数据：
pstmt.setString(1,request.getParameter("acct")); ResultSetresults=pstmt.executeQuery();http://example.com/app/accountInfo?acc=notmyacct1
2
3
4
* 攻击者 知需修改“acct”参数即可发送想要的任何账号信息：
*
A6：安全配置错误
简介
- 最常见，通常包括
- 不安全的默认配置
- 不完整的临时配置
- 开源云存储
- 错误的HTTP报头配置
- 包含敏感信息的详细错误信息
- 不仅需要对操作系统、框架、库和应用程序进行安全配置，而且必须及时修补和升级
实例
- 服务器管理员控制台自动安装后没有被删除，默认账户没有被改变。攻击者发现标准的管理员页面，通过 默认密码登录，从而接管服务器
- 目录列表功能未被禁用。攻击者发现只需列出目录就可以找到服务器上的任意文件
- 应用服务器配置允许堆栈跟踪返回给用户，暴露潜在的漏洞
- 应用服务器自带的示例应用程序没有从 生产服务器中删除
A7：跨站脚本（XSS）
简介
- 当网页中包含不受信任的、未经恰当验证或转义的数据，或使用可以创建HTML或JavaScript的浏览器API更新现有的网页时，会出现XSS缺陷
- 攻击者能够在受害者的浏览器中执行脚本，并劫持用户会话、破坏网站或将用户重定向到恶意站点
A8：不安全的反序列化
A9：使用含有已知漏洞的组件
使用含有已知漏洞的组件简介
使用组件开发的多数团队根本不了解其应用或API中使用的组件，更谈不上及时更新
组件（库、框架和其他软件模块）拥有和应用程序相同的权限
使用含有已知漏洞的组件后果
- 如果应用程序中含有已知漏洞的组件被攻击者利用，可能会造成严重的数据丢失或服务器接管
- 使用含有已知漏洞的组件的应用程序和API可能会破坏应用程序防御、造成各种攻击并产生严重影响
应用程序脆弱性
- 不知道所有使用 的组件版本信息（包括服务端和客户端），包括直接使用的组件或其依赖的组件
- 软件易受攻击，不再支持或者过时。包括：OS、Web服务器、应用程序服务器、数据库管理系统给（DBMS）、应用程序、API和所有的组件、运行环境和库
- 不做漏洞扫描和订阅使用组件的安全公告
- 不基于风险并及时修复或升级底层平台、框架和依赖库。很可能发生的情况：根据变更控制，每月或每季度进行升级，这使组织在这段时间内会受到已修复但未修补的漏洞和威胁
- 工程师没有对更新的、升级的或打过补丁的组件进行兼容性测试
- 没有对组件进行安全配置
A10：不足的日志记录和监控
简介
- 不足的日志记录和监控，以及事件响应缺失或无效的集成，使攻击者能够进一步攻击系统、保持持续性或转向更多系统，以及篡改、提取或销毁数据
- 研究显示，缺陷被检测出的时间超过200天，且通常通过外部检测方检测，而不是通过内部流程或监控检测
导致不足的日志记录、检测、监控和响应的情况
- 未记录可审计性事件，如：登录、登录失败和高额交易
- 告警和错误事件未能产生或产生不足的和不清晰的日志信息
- 没有利用应用系统和API的日志信息来监控可疑活动
- 日志信息仅在本地存储
- 没有定义合理的告警阈值和制定响应处理流程
- 渗透测试和使用工具（如ZAP）扫描没有触发告警
- 对于实时或准实时的攻击，应用程序无法检测、处理和告警
开发人员
建立并使用可重复使用的安全流程和标准安全控制
应用程序安全需求
定义安全对该应用程序的意义
应用程序安全架构
与其费力去提升应用程序和接口的安全，不如在应用程序开发阶段就进行安全设计，更能节约成本
标准的安全控制
提供一套标准的安全控制会极大简化应用程序和接口的安全开发过程
安全开发生命周期
遵循应用程序开发流程
应用程序安全教育
为开发人员提供安全培训
建立持续性的应用安全测试
理解威胁模型
测试之前，了解企业中需要耗时的重要部分。优先级来源于威胁模型
理解SDLC
测试方法必须与软件开发流程（SDLC）中的人员、工具和流程高度匹配
测试策略
选择最简单、快速、准确的方法去验证每项需求
实现全面性和准确性
不需要一切都要立刻测试，先关注重要的方面，然后随着时间扩展全面性
体现报告的价值
有效于别人沟通，清楚描述漏洞的滥用风险，然后在某场景下实现展现攻击