漏洞挖掘中的“漏网之鱼”:测试员如何面对未发现的安全隐患

本文探讨了安全测试中遗漏漏洞的边界问题,分析了从ImageTragick、Heartbleed等社区级漏报到SQL注入等基础错误的差异,并反思测试者的技能评估与责任承担机制。

遗漏一个漏洞

测试员们,请举手示意——你是否曾在测试中遗漏过某个发现?如果你还把手放著,你确定吗?如果你是应用测试员,是否在2016年5月4日前测试过使用ImageMagick的网站?或者作为网络测试员,是否在2015年4月前测试过使用OpenSSL的网络?如果你做过这些测试却没有报告ImageTragick或Heartbleed,那么你遗漏了两个非常严重的问题——但你其实是和整个安全社区一起遗漏的。我认为这些是可接受的遗漏。

但如果你遗漏了网站首页搜索框中的SQL注入,或者遗漏了域控制器上的开放根共享呢?两者也都是严重问题,但我会认为遗漏这些是非常大的错误。

那么,从“可接受遗漏”到“不可接受遗漏”的界限在哪里?这里涉及很多因素:测试时间窗口的长度、网络规模、应用程序的复杂性以及其他各种条件。我们还必须接受我们都是人,总会有状态不好的时候。

我想答案类似于其他学科所用的标准:一个与被认为应具备相似技能的另一位测试员,是否会发现这个问题?我说“被认为应具备”是因为有些测试者会自诩技能水平远高于实际,有的是故意欺骗,有的则是真心认为自己比实际情况更强。

还有专业领域的问题:有些人在某些领域比其他人更擅长。一个做过大量PHP测试的人,比一个大部分时间都在研究.Net应用的人更有可能发现LAMP应用中的漏洞。对一个人显而易见的问题,对另一个人可能完全陌生。

每当我听说有认识的人测试了我曾测试过的应用——尤其是在两次测试之间没有变化的情况下——我就会紧张。如果我遗漏了什么呢?如果我遗漏了非常明显的东西呢?如果他们调查后发现客户正是通过这个漏洞被攻击了呢?这样的事情可能会终结职业生涯,或者至少是巨大的倒退。我确实偶尔会遗漏一些小问题,但至今还没有大的遗漏。我希望永远不会有,但担忧始终存在。

我和一位朋友聊过,他说他购买了非常高额的专业责任保险,如果他真的犯了大错,他会告诉客户提出全额索赔,然后转身寻找其他职业。这似乎有点极端,但我理解他的感受。

偶尔会发生的情况是,一位测试者发现了一个问题,而另一位测试者却不认为这是个问题,所以看到了却没有觉得需要写入报告。我有几次遇到第二位测试者报告了一些我认为风险不足以上报的内容。虽然从未因此出过问题,但有时不得不向新测试者和客户解释为什么原始报告中没有包含这些问题,并进行讨论。

我想说的是,每个人都会遗漏东西——有些是故意的,有些是出于无心的错误,有些是因为能力不足。有些你可以侥幸逃脱,有些却可能真的毁掉一段良好的职业生涯。我不喜欢担心,但认为这种担忧最终会让我保持警觉,帮助确保我在每项工作中都尽力而为。

那么,遗漏东西会让你担心吗?你认为什么是可接受的遗漏?你是否遗漏过重大的问题并不得不面对后果?本博客没有评论系统,但请发邮件给我,我会整理回复并撰写后续文章——获取其他人对这个问题的看法会很好。

最后,我认为值得记住的是:技术不断变化,新的攻击手法一直在出现。正如开头所说,有些问题的遗漏是可接受的,因为整个社区都在遗漏它们。只要你尽力工作、诚实地对待自己的技能水平、并保持良好的测试记录,那么即使出了问题,事情也 hopefully 会顺利解决。

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计