OWASP TOP 10 漏洞浅析
0x00 漏洞简述
注入攻击（Injection）：注入攻击是一种通过输入非法字符或者数据来欺骗程序自行执行恶意代码或者命令的攻击方式。最常见的注入攻击是 SQL 注入攻击和 OS 命令注入攻击。
失效的身份认证和会话管理（Broken Authentication and Session Management）：该漏洞主要是指应用程序中身份认证和会话管理方案的设计不够严密，导致攻击者可以盗取用户的身份凭证，包括用户名、密码、会话ID等，从而获取用户的权限。
敏感数据泄露（Sensitive Data Exposure）：该漏洞主要是指应用程序未能保护存储在数据库中的敏感数据，如信用卡号码、密码等，这些数据被攻击者盗取后可能会导致用户隐私泄露。
XML外部实体注入漏洞（XML External Entities, XXE）：XML外部实体注入漏洞是一种基于XML解析器的漏洞，攻击者可以通过注入恶意实体来读取文件、执行命令等，最终导致应用程序的机密数据泄露。
失效的访问控制（Broken Access Control）：失效的访问控制指应用程序中对资源的访问控制机制存在缺陷，攻击者可以通过暴力破解、会话劫持、参数篡改等方式绕过访问控制机制，访问未授权的资源。
安全配置错误（Security Misconfiguration）：安全配置错误指应用程序的安全配置不当，比如不安全的默认设置、过度授权等，导致攻击者可以通过轻松的方式获取系统的权限和机密数据。
跨站脚本攻击（XSS）：跨站脚本攻击是一种利用 Web 页面脚本漏洞实施的攻击，攻击者可以通过注入脚本代码，例如恶意 JavaScript 脚本等，来盗取用户的身份信息或者在用户的浏览器中执行恶意代码。
不安全的反序列化（Insecure Deserialization）：反序列化是将序列化后的对象还原成原始对象的过程。不安全的反序列化攻击是一种通过篡改序列化数据来执行任意代码的攻击。攻击者可以在序列化数据中注入恶意数据，当反序列化时，这些恶意数据会被解析并执行。
使用含有已知漏洞的组件（Using Components with Known Vulnerabilities）：许多 Web 应用程序使用第三方组件和库来实现特定功能，如图像处理、邮件发送等。如果这些组件和库存在已知漏洞，攻击者可以利用这些漏洞来攻击应用程序。
不足的日志记录和监控（Insufficient Logging and Monitoring）：不足的日志记录和监控使得应用程序很难检测和响应攻击事件。攻击者可以通过绕过日志记录、擦除日志等方式来隐藏攻击痕迹，从而逃避检测和追踪。
0x01 注入
原理： 注入攻击（Injection）是一种利用应用程序的输入验证不严格或缺乏输入验证机制，从而允许攻击者通过构造恶意输入，将恶意代码或命令注入到应用程序的后台数据库或操作系统中，访问敏感数据甚至获取系统权限。
1. 注入点
当应用在如下时点时，是脆弱的并易受到攻击：
- 用户提供的数据没有经过应用程序的验证、过滤或净化。
- 动态查询语句或非参数化的调用，在没有上下文感知转义的情况下，被用于解释器。
- 在ORM搜索参数中使用了恶意数据，这样搜索就获得包含敏感或未授权的数据。
- 恶意数据直接被使用或连接，诸如SQL语句或命令在动态查询语句、命令或存储过程中包含结构和恶意数据。
注入漏洞通常能在SQL、LDAP、XPath或是NoSQL查询语句、OS命令、XML解析器、SMTP包头、表达式语句及ORM查询语句中找到。
一些常见的注入，包括：SQL、OS命令、ORM、LDAP和表达式语言（EL）或OGNL注入。
注入类型
SQL 注入攻击：攻击者通过在 SQL 查询语句中注入恶意代码，从而获取数据库中的机密数据或者控制数据库的操作。例如，攻击者可以通过在用户名或密码输入框中输入 ‘ or ‘1’=’1 这样的语句，绕过验证，获取所有用户信息的权限。
OS 命令注入攻击：攻击者通过在应用程序的命令行参数中注入恶意代码，执行任意的操作，例如上传或者下载文件，执行系统命令等。例如，攻击者可以在应用程序的搜索框中输入 && ls，来执行系统命令 ls 并列出文件列表。
LDAP 注入攻击：攻击者通过在 LDAP 查询语句中注入恶意代码，从而获取目录服务器中的机密数据或者控制服务器的操作。例如，攻击者可以通过在用户名或密码输入框中输入
)(&(objectClass=))这样的语句，获取所有用户信息的权限。ORM注入攻击：ORM (Object-Relational Mapping) 是一种编程技术，用于将关系数据库中的数据转换为面向对象的编程语言中的对象。ORM 注入是指攻击者利用不当使用ORM的漏洞，向ORM框架注入恶意代码来获取或者篡改数据。
表达式语言（EL）或OGNL注入：表达式语言（EL）和OGNL (Object-Graph Navigation Language) 是一种用于在 Web 应用程序中动态执行表达式的语言。EL 和 OGNL 注入是指攻击者利用不当使用 EL 或 OGNL 的漏洞，向 Web 应用程序注入恶意代码来获取或篡改数据。
XPath 注入攻击：攻击者通过在 XML 数据中注入恶意代码，执行任意的操作，例如获取机密数据或者控制系统。例如，攻击者可以通过在搜索框中输入 ‘ or 1=1 or ‘a’=’a，来绕过验证并获取所有用户信息。
CRLF注入：CRLF注入攻击是通过在HTTP头中注入CRLF字符（Carriage Return和Line Feed），从而实现在Web应用程序中执行任意操作的攻击。
注入点
用户输入参数：包括用户名、密码、搜索查询、表单字段等。
HTTP 请求头：包括 Cookie、Referer 等。
SQL 语句参数：应用程序中直接使用用户输入的参数构建 SQL 语句。
LDAP 查询参数：应用程序中直接使用用户输入的参数构建 LDAP 查询语句。
操作系统命令参数：应用程序中直接使用用户输入的参数构建操作系统命令。
Cookie：如果攻击者能够注入Cookie值，就能够伪造用户身份并执行恶意操作。
2. 影响危害
注入能导致数据丢失、破坏或泄露给无授权方，缺乏可审计性或是拒绝服务。注入有时甚至能导致主机被完全接管。
3. 绕过姿势
使用编码绕过：攻击者使用特殊的编码方式对注入载荷进行编码，使得它可以绕过输入验证和过滤机制。例如，将特殊字符编码成十六进制或Unicode编码。
使用注释符绕过：攻击者可以使用注释符（例如 “–”）将载荷分成两部分，注释符后面的部分可以被忽略，这样就可以绕过输入验证和过滤机制。
使用空格绕过：攻击者可以在注入载荷中使用空格，从而使得输入验证和过滤机制无法识别注入载荷的存在。
混淆语句结构绕过：攻击者可以使用特殊的语句结构和关键字组合，使得注入语句可以绕过输入验证和过滤机制，例如使用UNION SELECT语句，或者使用特殊的MySQL函数等。
使用时间延迟绕过：攻击者可以在注入语句中使用时间延迟函数，使得注入语句的执行时间变长，从而绕过输入验证和过滤机制。
使用多重查询绕过：攻击者可以在注入语句中使用多重查询，使得注入语句可以绕过输入验证和过滤机制。
使用分段绕过：攻击者可以将攻击载荷分成多个片段，每个片段都可以通过WAF的检测，然后再将它们组合起来执行攻击。
使用代理绕过：攻击者可以使用代理服务器来转发攻击请求，以绕过WAF的检测。
4. 防御措施
使用参数化查询或预处理语句：在编写 SQL 查询语句时，应该使用参数化查询或预处理语句来减少 SQL 注入的风险。
验证与过滤用户输入：在接受和处理用户输入数据时，需要对数据进行过滤和验证，以确保输入数据符合预期的格式和类型，并不包含任何恶意代码。
限制数据库用户权限：应该将数据库用户的权限最小化，只赋予其必要的权限，以限制注入攻击的危害范围。
最小化信息泄露：系统应该尽可能减少对攻击者有用的错误信息和调试信息的泄露，例如，错误消息应该尽可能不包含敏感信息。
使用最新版本的软件和框架：使用最新版本的软件和框架可以减少已知漏洞的风险。
加强敏感数据保护：对于敏感数据，采用加密、隔离等措施，确保数据的机密性和完整性。
0x02 失效的身份认证和会话管理
原理：攻击者利用系统中存在的安全漏洞，绕过或破解身份认证或会话管理机制，从而获得未经授权的访问或操作权限。
1. 脆弱点
如果您的应用程序存在如下问题，那么可能存在身份验证的脆弱性：
- 允许凭证填充，这使得攻击者获得有效用户名和密码的列表。
- 允许暴力破解或其他自动攻击。
- 允许默认的、弱的或众所周知的密码，例如”Password1”或”admin/admin”。
- 使用弱的或失效的验证凭证，忘记密码程序，例如”基于知识的答案”，这是不安全的。
- 使用明文、加密或弱散列密码（参见：A3:2017-敏感数据泄露）。
- 缺少或失效的多因素身份验证。
- 暴露URL中的会话ID（例如URL重写）。
- 在成功登录后不会更新会话ID。
- 不正确地使会话ID失效。当用户不活跃的时候，用户会话或认证令牌（特别是单点登录（SSO）令牌）没有正确注销或失效。
2. 影响危害
失效的身份认证和会话管理漏洞可能导致攻击者窃取用户身份、越权访问、篡改数据等严重后果。
身份验证绕过：攻击者可以使用无效的身份验证绕过身份验证机制，获得未授权的访问权限。
帐户劫持：攻击者可以通过会话劫持或会话固定攻击获取已认证用户的会话令牌，并利用该令牌访问用户帐户。
数据泄露：攻击者可以访问未经授权的数据，例如，用户凭据、敏感数据和客户机存储的信息等。
篡改数据：攻击者可以使用劫持的会话令牌篡改数据，例如修改个人资料、更改密码等。
恶意用户假冒：攻击者可以使用劫持的会话令牌冒充认证用户，执行各种恶意操作，例如转移资金或修改订单等。
泄露机密数据：攻击者可以利用受攻击的会话绕过访问控制机制，访问敏感数据或机密信息。
3. 防御措施
在可能的情况下，实现多因素身份验证，以防止自动、凭证填充、暴力破解和被盗凭据再利用攻击。
使用强密码：强密码包括大小写字母、数字和特殊字符，避免使用易于猜测的密码，比如生日、常用数字、常见单词等。
实施多重身份验证：使用多因素身份验证可以提高系统的安全性，例如使用短信验证码、动态口令令牌等。
禁止使用默认密码：在部署新系统时，需要修改默认密码，否则可能被攻击者轻易破解。
限制登录尝试次数：在系统中设置登录失败次数限制，过多的失败尝试将锁定账号或者增加等待时间，以减少暴力破解的风险。
定期更新和轮换密码：对于敏感账号或者管理账号，建议定期更新和轮换密码，避免长期使用同一密码。
增强会话安全性：使用HTTPS协议传输会话数据，避免使用HTTP明文传输，同时确保会话仅在必要时才处于活动状态，并在会话过期后自动注销。
避免暴露会话ID：不要在URL中明文传递会话ID，因为URL可能会被攻击者窃取或者劫持。
在服务器端验证用户输入：始终在服务器端对用户输入进行验证和过滤，以确保输入的安全性。
0x03 敏感数据泄露
敏感数据泄露（Sensitive Data Exposure）漏洞指的是应用程序中存储的敏感数据没有得到足够的保护，导致攻击者非法获取这些敏感数据。敏感数据通常包括个人身份信息、财务信息、医疗记录等，如果这些数据被窃取，会造成严重的隐私泄露和经济损失。
1. 漏洞成因
加密不足：数据在传输或存储时未经加密或者加密方式不够强健，导致数据容易被窃取或者破解。
不安全的存储：应用程序将敏感数据存储在不安全的地方，如明文存储在数据库中、存储在可被公开访问的文件中等，使得攻击者可以轻松获取这些数据。
不安全的传输：应用程序在传输敏感数据时未经加密，使得攻击者可以通过网络嗅探等方式获取这些数据。
未及时更新软件或补丁：应用程序或相关组件存在漏洞时，攻击者可以利用这些漏洞来获取敏感数据。
2. 脆弱点
首先需要确认的是哪些数据是敏感数据（包含：传输过程中的数据、存储数据）而需要被加密。例如：密码、信用卡卡号、医疗记录、个人信息应该被加密，特别是隐私法律或条例中规定需要加密的数据，如：欧盟《通用数据保护条例》（GDPR）、 属于”金融数据保护条例”的《支付卡行业数据安全标准》（PIC DSS）。对于这些数据，要确定：
- 在数据传输过程中是否使用明文传输？这和传输协议相关，如：HTTP、SMTP和FTP。外部网络流量非常危险。验证所有的内部通信，如：负载平衡器、Web服务器或后端系统之间的通信。
- 当数据被长期存储时，无论存储在哪里，它们是否都被加密，包含备份数据？
- 无论默认条件还是源代码中，是否还在使用任何旧的或脆弱的加密算法？
- 是否使用默认加密密钥，生成或重复使用脆弱的加密密钥，或者缺少恰当的密钥管理或密钥回转？
- 是否强制加密敏感数据，例如：用户代理（如：浏览器）指令和传输协议是否被加密？
- 用户代理（如：应用程序、邮件客户端）是否未验证服务器端证书的有效性？
3. 防御措施
对一些需要加密的敏感数据，应该做到以下几点：
- 对系统处理、存储或传输的数据分类，并根据分类进行访问控制。- 熟悉与敏感数据保护相关的法律和条例，并根据每项法规要求保护敏感数据。
- 对于没必要存放的、重要的敏感数据，应当尽快清除，或者通过PCI DSS标记或拦截。未存储的数据不能被窃取。
- 确保存储的所有敏感数据被加密。
- 确保使用了最新的、强大的标准算法或密码、参数、协议和密匙，并且密钥管理到位。
- 确保传输过程中的数据被加密，如：使用TLS。确保数据加密被强制执行，如：使用HTTP严格安全传输协议（HSTS ）。
- 禁止缓存对包含敏感数据的响应。
- 确保使用密码专用算法存储密码，如：Argon2 、 scrypt 、bcrypt 或者PBKDF2 。将工作因素（延迟因素）设置在可接受范围。
- 单独验证每个安全配置项的有效性。
4. 攻击场景
场景一
一个应用程序使用自动化的数据加密系统加密信用卡信息，并存储在数据库中。但是，当数据被检索时被自动解密，这就使得SQL注入漏洞能够以明文形式获得所有信用卡卡号。
场景二
一个网站上对所有网页没有使用或强制使用TLS，或者使用弱加密。攻击者通过监测网络流量（如：不安全的无线网络），将网络连接从HTTPS降级到HTTP，就可以截取请求并窃取用户会话cookie。 之后，攻击者可以复制用户cookie并成功劫持经过认证的用户会话、访问或修改用户个人信息。除此之外，攻击者还可以更改所有传输过程中的数据，例如：转款的接接收者。
场景三
密码数据库使用未加盐的哈希算法或弱哈希算法去存储每个人的密码。一个文件上传漏洞使黑客能够获取密码文件。所有这些未加盐哈希的密码通过彩虹表暴力破解方式破解。 由简单或快速散列函数生成加盐的哈希，也可以通过GPU破解。
0x04 XML 外部实体（XXE）
原理： 攻击者利用 XML 解析器的功能，通过在 XML 文档中插入恶意实体来触发漏洞。
攻击者构造一个恶意XML文件，并将其提交到目标应用程序中进行解析。在解析过程中，攻击者在XML文档中注入一些恶意的实体和引用，利用这些实体和引用来读取文件、访问网络资源、执行系统命令等操作，从而导致敏感数据泄露、服务器被控制等危害。
成因： 在应用程序对XML文件进行解析时，没有对外部实体进行正确的限制或过滤。
1. 出现场景
应用程序和特别是基于XML的Web服务或向下集成，可能在以下方面容易受到攻击：
- 直接接受XML文件或上传XML文件，特别是来自不受信任的源。
- 将不受信任的数据插入XML文件并提交给XML处理器解析。
- 在应用程序或Web服务中，启用了文档类型定义（DTDs）并且处理器没有禁用DTDs。
- 使用SAML进行身份认证时，由于SAML使用XML进行身份确认，因此容易受到XXE攻击。
- 应用程序使用早于1.2版本的SOAP，并且将XML实体传递到SOAP框架。
2. 影响危害
XXE缺陷可用于提取数据、执行远程服务器请求、扫描内部系统、执行拒绝服务攻击和其他攻击。业务影响取决于所有受影响的应用程序和数据保护需求。
敏感数据泄露：攻击者可以读取服务器上的敏感数据并将其泄露给未授权的第三方。
拒绝服务攻击：攻击者可以通过恶意的XML文件来耗尽服务器的资源，导致服务不可用。
服务器被控制：攻击者可以通过注入恶意代码来控制服务器，并执行恶意操作，如删除、修改、上传等。
3. 攻击方式
XXE漏洞的攻击方式通常包括以下几种：
基于响应的攻击（Response-based attacks）：攻击者将恶意代码嵌入XML文件中，然后将文件上传到目标网站。当目标网站对该XML文件进行解析时，攻击者可以通过观察响应内容（如错误信息、返回时间等）来判断攻击是否成功，并从中获取敏感信息。
盲注攻击（Blind XXE attacks）：攻击者通过在XML文件中插入恶意代码并请求目标网站解析该文件，然后观察目标网站的响应来判断攻击是否成功，并获取敏感信息。与基于响应的攻击不同的是，攻击者无法直接从响应中获得有用的信息，而需要进行多次请求和观察。
带外攻击（Out-of-Band XXE attacks）：攻击者通过在XML文件中插入恶意代码并请求目标网站解析该文件，然后触发目标网站向攻击者控制的外部服务器发送请求，从而将敏感信息泄漏到攻击者的服务器上。这种攻击方式通常用于绕过目标网站的防火墙或其他安全设施。
直接攻击（Direct XXE attacks）：攻击者直接向目标网站发送包含恶意代码的XML请求，从而触发目标网站解析该请求并执行其中的恶意代码。这种攻击方式通常需要攻击者事先获取目标网站的XML解析器的相关信息（如URL、参数等），因此相对较难实施。
3. 防御措施
开发人员培训是识别和减少XXE缺陷的关键，此外，防止XXE 缺陷还需要：
禁用外部实体：禁用XML解析器中的外部实体可以有效防止XXE漏洞。对于一些语言和库，这可以通过设置特定选项或属性来实现。
白名单过滤输入数据：应用程序应该只接受预期格式的XML数据，并根据需要实现白名单过滤。可以在输入数据中排除任何不必要的元素，以减少攻击面。
使用最新版本的XML解析器和库：XML解析器和库的最新版本通常包含对XXE漏洞的修复和防御措施。因此，使用最新版本的库和解析器可以减少受到XXE攻击的风险。
使用安全的XML解析器：使用被广泛认可为安全的XML解析器，如SAX或DOM，以防止恶意XML数据的注入和攻击。
实现输入验证和过滤：应用程序应该对所有输入数据进行验证和过滤，以确保输入数据符合预期格式和模式。这可以减少攻击面，并提高应用程序的安全性。
4. 攻击场景
大量XXE缺陷已经被发现并被公开，这些缺陷包括嵌入式设备的XXE缺陷。 XXE缺陷存在于许多意想不到的地方，这些地方包括深嵌套的依赖项。最简单的方法是上传可被接受的恶意XML文件：
场景 1：攻击者尝试从服务端提取数据：
1 |
|
场景 2：攻击者通过将上面的实体行更改为以下内容来探测服务器的专用网络：
1 | ]> |
场景 3：攻击者通过恶意文件执行拒绝服务攻击：
1 | ]> |
0x05 失效的访问控制
失效的访问控制（Broken Access Control）是指在应用程序中缺乏恰当的访问控制措施，使得攻击者可以未经授权地访问系统资源或执行操作。一般来说，访问控制机制包括身份验证、授权和会话管理等方面，而失效的访问控制漏洞可能发生在这些方面的任何一个或多个环节。
1. 脆弱点
访问控制强制实施策略，使用户无法在其预期的权限之外执行行为。失败的访问控制通常导致未经授权的信息泄露、修改或销毁所有数据、或在用户权限之外执行业务功能。常见的访问控制脆弱点包括：
- 通过修改 URL、内部应用程序状态或 HTML 页面绕过访问控制检查，或简单地使用自定义的 API 攻击工具。
- 允许将主键更改为其他用户的记录，例如查看或编辑他人的帐户。
- 特权提升。在不登录的情况下假扮用户，或以用户身份登录时充当管理员。
- 元数据操作，如重放或篡改 JWT 访问控制令牌，或作以提升权限的cookie 或隐藏字段。
- CORS配置错误允许未授权的API访问。
- 以未通过身份验证的用户身份强制浏览的通过身份验证时才能看到的页面、或作为标准用户访问具有相关权限的页面、或API没有对POST、PUT和DELETE强制执行访问控制。
2. 影响危害
攻击者可以冒充用户、管理员或拥有特权的用户，或者创建、访问、更新或删除任何记录。
3. 防御措施
访问控制只有在受信服务器端代码或没有服务器的 API 中有效，这样这样攻击者才无法修改访问控制检查或元数据。
- 除公有资源外，默认情况下拒绝访问
- 使用一次性的访问控制机制，并在整个应用程序中不断重用它们，包括最小化跨域资源共享 (CORS) 的使用。
- 建立访问控制模型以强制执行所有权记录，而不是接受用户创建、读取、更新或删除的任何记录。
- 在域模型中强制执行业务限制。
- 禁用 Web 服务器目录列表，并确保文件元数据（如 Git）不存在于 Web 的根目录中。
- 记录失败的访问控制，并在适当时向管理员发出警报。
- 对 API 和控制器的访问进行速率限制，以最大限度地降低自动化攻击工具的危害。
- 当用户注销后，服务器上的 JSON Web Token (JWT) 令牌应失效。
0x06 安全配置错误
安全配置错误是系统管理员或开发人员在配置安全措施时出现了疏漏或错误，使得攻击者可以利用这些漏洞绕过安全控制，从而达到攻击的目的。
1. 脆弱点
您的应用程序可能受到攻击，如果应用程序是：
- 应用程序栈堆的任何部分都缺少适当的安全加固，或者云服务的
权限配置错误。 - 应用程序启用或安装了不必要的功能（例如：不必要的端口、服
务、网页、帐户或权限）。 - 默认帐户的密码仍然可用且没有更改。
- 错误处理机制向用户披露堆栈跟踪或其他大量错误信息。
- 对于更新的系统，禁用或不安全地配置最新的安全功能。
- 应用程序服务器、应用程序框架（如：Struts、Spring、
ASP.NET）、库文件、数据库等没有进行安全配置。 - 服务器不发送安全标头或指令，或者未对服务器进行安全配置。
- 您的应用软件已过期或易受攻击（参见A9：2017-使用含有已知
漏洞的组件）。
缺少一个体系的、可重复的应用程序安全配置过程，系统将处于高风险中。
2. 防御措施
应实施安全的安装过程，包括：
- 一个可以快速且易于部署在另一个锁定环境的可重复的加固过程。开发、质量保证和生产环境都应该进行相同配置，并且，在每个环境中使用不同的密码。这个过程应该是自动化的，以尽量减少安装一个新安全环境的耗费。
- 搭建最小化平台，该平台不包含任何不必要的功能、组件、文档和示例。移除或不安装不适用的功能和框架。
- 检查和修复安全配置项来适应最新的安全说明、更新和补丁，并将其作为更新管理过程的一部分，（参见A9：2017-使用含有已知漏洞的组件）。在检查过程中，应特别注意云存储权限（如：S3桶权限）。
- 一个能在组件和用户间提供有效的分离和安全性的分段应用程序架构，包括：分段、容器化和云安全组。
- 向客户端发送安全指令，如：安全标头。
- 在所有环境中能够进行正确安全配置和设置的自动化过程。
3. 攻击场景
场景1：应用程序服务器附带了未从产品服务器中删除的应用程序样例。这些样例应用程序具有已知的安全漏洞，攻击者利用这
些漏洞来攻击服务器。如果其中一个应用程序是管理员控制台，并且没有更改默认账户，攻击者就可以通过默认密码登录，从而接管服务器。
场景2：目录列表在服务器端未被禁用。攻击者发现他们很容易就能列出目录列表。攻击者找到并下载所有已编译的Java类，他们通过反编译来查看代码。然后，攻击者在应用程序中找到一个严重的访问控制漏洞。
场景3：应用服务器配置允许将详细的错误信（如：堆栈跟踪信息）返回给用户，这可能会暴露敏感信息或潜在的漏洞，如：已知含有漏洞的组件的版本信息。
场景4：云服务向其他CSP用户提供默认的网络共享权限。这允许攻击者访问存储在云端的敏感数据。
0x07 跨站脚本（XSS）
当应用程序的新网页中包含不受信任的、未经恰当验证或转义的数据时，或者使用可以创建 HTML或JavaScript 的浏览器 API 更新现有的网页时，就会出现 XSS 缺陷。XSS 让攻击者能够在受害者的浏览器中执行脚本，并劫持用户会话、破坏网站或将用户重定向到恶意站点。
1. XSS类型
1）反射式XSS：
应用程序或API包括未经验证和未经转义的用户输入，作为HTML输出的一部分。一个成功的攻击可以让攻击者在受害者的浏览器中执行任意的HTML和JavaScript。 通常，用户将需要与指向攻击者控制页面的某些恶意链接进行交互，例如恶意漏洞网站，广告或类似内容。
2）存储式XSS：
应用或者API将未净化的用户输入存储下来了，并在后期在其他用户或者管理员的页面展示出来。 存储型XSS一般被认为是高危或严重的风险。
3）基于DOM的XSS：
会动态的将攻击者可控的内容加入页面的JavaScript框架、单页面程序或API存在这种类型的漏洞。理想的来说，你应该避免将攻击者可控的数据发送给不安全的JavaScriptAPI。
2. 影响危害
典型的XSS攻击可导致盗取session、账户、绕过MFA、DIV替换、对用户浏览器的攻击（例如：恶意软件下载、键盘记录）以及其他用户侧的攻击。
XSS对于反射和DOM的影响是中等的，而对于存储的XSS，XSS的影响更为严重，譬如在受攻击者的浏览器上执行远程代码。
3. 防御措施
防止XSS需要将不可信数据与动态的浏览器内容区分开。这可以通过如下步骤实现：
- 使用设计上就会自动编码来解决XSS问题的框架，如：Ruby 3.0或 React JS。了解每个框架的XSS保护的局限性，并适当地处理未覆盖的用例。
- 为了避免反射式或存储式的XSS漏洞，最好的办法是根据HTML输出的上下文（包括：主体、属性、JavaScript、CSS或URL）对所有不可信的HTTP请求数据进行恰当的转义 。
- 在客户端修改浏览器文档时，为了避免DOM XSS攻击，最好的选择是实施上下文敏感数据编码。
- 使用内容安全策略（CSP）是对抗XSS的深度防御策略。如果不存在可以通过本地文件放置恶意代码的其他漏洞（例如：路径遍历覆盖和允许在网络中传输的易受攻击的库），则该策略是有效的。
0x08 不安全的反序列化
不安全的反序列化会导致远程代码执行。即使反序列化缺陷不会导致远程代码执行，攻击者也可以利用它们来执行攻击，包括：重播攻击、注入攻击和特权升级攻击。
1. 脆弱点
如果反序列化进攻者提供的敌意或者篡改过的对象将会使将应用程序和API变的脆弱。
这可能导致两种主要类型的攻击：
- 如果应用中存在可以在反序列化过程中或者之后被改变行为的类，则攻击者可以通过改变应用逻辑或者实现远程代码执行攻击。我们将其称为对象和数据结构攻击。
- 典型的数据篡改攻击，如访问控制相关的攻击，其中使用了现有的数据结构，但内容发生了变化。
在应用程序中，序列化可能被用于:
- 远程和进程间通信（RPC / IPC）
- 连线协议、Web服务、消息代理
- 缓存/持久性
- 数据库、缓存服务器、文件系统
- HTTP cookie、HTML表单参数、API身份验证令牌
2. 防御措施
唯一安全的架构模式是不接受来自不受信源的序列化对象，或使用只允许原始数据类型的序列化媒体。
如果上述不可能的话，考虑使用下述方法：
- 执行完整性检查，如：任何序列化对象的数字签名，以防止恶意对象创建或数据篡改。
- 在创建对象之前强制执行严格的类型约束，因为代码通常被期望成一组可定义的类。绕过这种技术的方法已经被证明，所以完全依赖于它是不可取的。
- 如果可能，隔离运行那些在低特权环境中反序列化的代码。
- 记录反序列化的例外情况和失败信息，如：传入的类型不是预期的类型，或者反序列处理引发的例外情况。
- 限制或监视来自于容器或服务器传入和传出的反序列化网络连接。
- 监控反序列化，当用户持续进行反序列化时，对用户进行警告
3. 攻击场景
场景 1：
一个React应用程序调用了一组Spring Boot微服务。作
为功能性程序员，他们试图确保他们的代码是不可变的。他们提
出的解决方法是序列化用户状态，并在每次请求时来回传递。攻
击者注意到了”R00”Java对象签名，并使用Java Serial Killer工
具在应用服务器上获得远程代码执行。
场景 2：
一个PHP论坛使用PHP对象序列化来保存一个”超级”cookie。该cookie包含了用户的用户ID、角色、密码哈希和其
他状态：
1 | a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user";i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";} |
0x09 使用含有已知漏洞的组件
组件（例如：库、框架和其他软件模块）拥有和应用程序相同的权限。如果应用程序中含有已知漏洞的组件被攻击者利用，可能会造成严重的数据丢失或服务器接管。同时，使用含有已知漏洞的组件的应用程序和API可能会破坏应用程序防御、造成各种攻击并产生严重影响。
1. 脆弱点
如果满足下面的某个条件，那么你的应用就易受此类攻击：
- 如果你不知道所有使用的组件版本信息（包括：服务端和客户端）。这包括了直接使用的组件或其依赖的组件。
- 如果软件易受攻击，不再支持或者过时。这包括：OS、Web服务器、应用程序服务器、数据库管理系统（DBMS）、应用程序、API和所有的组件、运行环境和库。
- 如果你不会定期做漏洞扫描和订阅你使用组件的安全公告。
- 如果你不基于风险并及时修复或升级底层平台、框架和依赖库。很可能发生这种情况：根据变更控制，每月或每季度进行升级，这使得组织在这段时间内会受到已修复但未修补的漏洞的威胁。
- 如果软件工程师没有对更新的、升级的或打过补丁的组件进行兼容性测试。
- 如果你没有对组件进行安全配置（请参考”A6:2017-安全配置错误”）。
2. 防御措施
应该制定一个补丁管理流程：
- 移除不使用的依赖、不需要的功能、组件、文件和文档。
- 利用如 versions、DependencyCheck 、retire.js等工具来持续的记录客户端和服务器端以及它们的依赖库的版本信息。持续监控如CVE 和 NVD等是否发布已使用组件的漏洞信息，可以使用软件分析工具来自动完成此功能。订阅关于使用组件安全漏洞的警告邮件。
- 仅从官方渠道安全的获取组件，并使用签名机制来降低组件被篡改或加入恶意漏洞的风险
- 监控那些不再维护或者不发布安全补丁的库和组件。如果不能打补丁，可以考虑部署虚拟补丁来监控、检测或保护。
0x0A 不足的日志记录和监控
不足的日志记录和监控，以及事件响应缺失或无效的集成，使攻击者能够进一步攻击系统、保持持续性或转向更多系统，以及篡改、提取或销毁数据。大多数缺陷研究显示，缺陷被检测出的时间超过200天，且通常通过外部检测方检测，而不是通过内部流程或监控检测。
1. 脆弱点
下列情况会导致不足的日志记录、检测、监控和响应：
- 未记录可审计性事件，如：登录、登录失败和高额交易。
- 告警和错误事件未能产生或产生不足的和不清晰的日志信息。
- 没有利用应用系统和API的日志信息来监控可疑活动。
- 日志信息仅在本地存储。
- 没有定义合理的告警阈值和制定响应处理流程。
- 渗透测试和使用DAST工具（如：OWASP ZAP）扫描没有触发告警
- 对于实时或准实时的攻击，应用程序无法检测、处理和告警
2. 防御措施
根据应用程序存储或处理的数据的风险：
- 确保所有登录、访问控制失败、输入验证失败能够被记录到日志中去，并保留足够的用户上下文信息，以识别可疑或恶意帐户，并为后期取证预留足够时间。
- 确保日志以一种能被集中日志管理解决方案使用的形式生成
- 确保高额交易有完整性控制的审计信息，以防止篡改或删除，例如审计信息保存在只能进行记录增加的数据库表中。
- 建立有效的监控和告警机制，使可疑活动在可接受的时间内被发现和应对。
- 建立或采取一个应急响应机制和恢复计划，例如：NIST 800-61 rev 2或更新版本。