一个空值：评估AWS中断的根本原因及未来预防措施
你是否验证代码中的所有值？你应该这样做。我原本考虑撰写一本关于应用安全的书籍，但基于上一本书的销售情况（在本文底部），我决定将时间投入其他更有价值的领域。
我像上一本书那样开始了这个系列：
安全代码设计 预防漏洞并防御网络攻击的编程策略 medium.com
我原本打算为书籍保留的一个章节是关于减少数据库泄露风险的首要方法，可以用一句话总结：
❗️❗️❗️❗️❗️❗️❗️❗️❗️❗️❗️❗️❗️❗️❗️❗️❗️ 验证代码中的每个值。 ❗️❗️❗️❗️❗️❗️❗️❗️❗️❗️❗️❗️❗️❗️❗️❗️❗️
在应用安全方面，我主要讨论的是可能被不可信源注入的值，例如插入登录表单、API或网页表单中的值。我在这里解释了其工作原理：
为我妈妈准备的网络安全 为非网络人士考虑的网络安全 medium.com
对于lambda函数的情况：
导致XSS和注入的Lambda函数参数 ACM.56 如果你没有正确保护输入，我在渗透测试中可能会如何滥用你的Lambda函数 medium.com
但每当关键系统执行…任何操作时，检查有效值也很重要。
关于AWS中断，如果你真的想知道发生了什么，这里有一个非常详细的解释：
弗吉尼亚北部（US-EAST-1）区域Amazon DynamoDB服务中断摘要 我们想为您提供有关北弗吉尼亚地区服务中断的一些额外信息… aws.amazon.com
你也可以用它来评估停机时间对业务的影响，并决定如何处理，正如我在这里解释的：
应对AWS中断 有条不紊地处理实际问题 medium.com
但在那长篇的错误解释中，我们可以找出导致这一系列事件的单一问题，这导致了AWS近期最具影响力的中断之一。（在此我提醒大家，Azure、GCP、CloudFlare和其他公司也有过同样多或更多的情况。）
以下是所有内容中的关键句子：
此问题的根本原因是DynamoDB DNS管理系统中存在一个潜在的竞态条件，导致服务的区域端点（dynamodb.us-east-1.amazonaws.com）出现错误的空DNS记录[并忽略“自动化未能修复”部分，因为这不是原因，而是事后试图预防原因的方式。]
那个空值或null值导致了之后的一系列事件，并且可以通过缺失值检查来预防。
老实说，竞态条件是真正的罪魁祸首。而竞态条件很难发现、测试和预防。更多关于竞态条件的信息：
并发无处不在 当事物顺序导致网络安全问题时 medium.com
但null或缺失值很容易预防。检查空值。如果你无法以某种方式修复空值，那么你需要向调用系统抛出错误，或阻止由于无效值可能导致未来操作无法按预期执行。
在DNS记录的情况下，额外的检查可以验证将要使用的DNS记录在继续之前返回正确的DNS响应，例如返回在正确区域和服务AWS IP范围内的IP地址的响应。顺便说一句，我不喜欢“全局”IP范围。我希望所有范围都定义它们操作的区域，但这是一个单独的话题。
AWS IP地址范围 使用ip-ranges.json文件中发布的IP地址范围来识别和控制进出AWS服务的流量… docs.aws.amazon.com
请注意，我并不是在责怪编写未检查缺失值的代码的开发人员，因为确保你永远不会缺少null值检查并非易事。你编写了大量代码，很容易忽略这样的事情，或者你可能认为它并不重要，因为你信任所有输入源。
除了编写代码的人之外，为什么没有人测试该值未设置的场景？不容易。可能没有一个明确的方法让单个测试人员产生导致缺失值的场景。该条件可能发生在应用程序内部，由线程而非人类操作。
可能最初基于给定的代码路径，该值不可能未设置，但对代码的更改使这种情况成为可能，而这在代码更改之前并不存在。这就是编写原始代码并为此类依赖关系和警告提供大量文档的OG们有帮助的地方。
我并不是说这些事情容易，也没有人应该犯错。我只是说修复是微不足道的。在代码的那一点添加null值检查，并确保不触发后续处理。
并且发送大约一百万个警报，因为在那个时候你的DNS记录可能是错误的，并导致一大堆其他问题。
不准确的DNS记录完全是另一个巨大的问题，所以任何时候缓存了错误的DNS值或DNS记录未更新，每个人都 everywhere 都需要知道并调查原因。立即。
将Teri Radichel的故事发送到你的收件箱 免费加入Medium以获取此作者的更新。 订阅 订阅
为什么？ 阅读DNS安全： DNS安全 Teri Radichel关于DNS安全的文章 medium.com
以下是一个在bash中检查空值的示例，它检查未设置的值和空字符串，这是你需要检查的两种不同情况：
|
|
未设置的值是指你使用一个从未被赋值的变量。在某些语言中，这被称为NULL或EMPTY值。以下是一些代码，其中MY_VARIABLE_1从未被设置。
|
|
空字符串是被设置为零长度字符串的字符串值。在以下代码中，MY_VARIABLE被设置为空字符串。
|
|
在上面的代码中，log_and_send_alert将是一个在健壮系统上在单独线程中记录错误的函数，这样即使应用程序挂起或失败，日志和警报也能正确写入和发送。
handle_error()函数将采取适当的系统操作，例如退出应用程序或跳过后续操作，因为数据已损坏。
这再次显示了代码中正确错误处理的关键性质。真正应该发生什么，以及看到错误消息的人（他们确实看到了，对吧？！）将如何知道如何处理它？
周到的错误处理 你的错误处理程序是你最重要的安全防御之一 medium.com
我们不要忘记测试。测试每条可能的路径和故障场景。不仅仅是快乐路径。
更好的测试以获得更好的结果 基础设施、灾难恢复、产品和渗透测试 medium.com
这就是我的职业——安全测试。在执行安全测试时，我会在报告的附录中记录不一定是安全错误但由于未验证值而以奇怪方式搞乱系统的错误。
除了检查缺失值外，还应验证所有值以确保它们包含有效字符。攻击者通过向代码中插入不正确的值来做他们的事情。顺便说一句，我谈论的是所有值，尤其是DNS值（AWS的一些人知道我在说什么🤨，即使我们在这些事项的重要性上意见不一致😁。）
所以，看看我猜测AWS出了什么问题的文章，我对触发问题的猜测有点正确，但我认为它发生在故障链的稍后点。某个系统从一开始就没有正确处理损坏的数据。
除了严重依赖DNS记录和DynamoDB表（这些可能可以更改，也可能无法更改）之外，听起来有些系统需要在故障发生时重新测试以进行优雅恢复。我在银行系统中经常遇到这个问题。当处理一批财务记录的批处理过程失败时，你必须确保在重新启动时，如果有一个记录被半处理或缺失，它能正常工作。它需要正确处理和记录错误，同时继续处理其余记录。
我不确定，因为我不在AWS工作，但听起来可能是一个类似的问题，存在某种数据损坏，系统在修复损坏的数据之前无法继续。所有系统都需要测试重启和正确记录错误，而不是被它们卡住。我猜所有这些系统和其他系统将被重新审视，以在未来正确处理此类故障。
现在对问题有了更多了解，我认为你可能希望在这种情况下阻止DNS更新，而不是处理一些错误一些正确的半生不熟的DNS条目，因为这将导致一大堆奇怪的问题和随机故障，难以排除。
但无论如何。现在这些足以让你思考你应该在整个代码中验证的所有那些值，以确保它们被正确设置。如果你在QA或渗透测试工作，你会理解null值或空字符串可能引起的潜在问题及其对关键系统的影响。
这个故事的寓意是：
- 验证你所有的值。
- 一个空值可能造成严重破坏。
- 未设置的值和空字符串是两件不同的事情。
- 测试所有可能的故障场景以查找竞态条件。
- 总是DNS的问题。
关注更新。 Teri Radichel | © 2nd Sight Lab 2025
关于Teri Radichel：
|
|
🔒 请求渗透测试 关注更多类似故事：
|
|