是否需要成为一名优秀的程序员才能执行安全的源代码分析？

#1 楼

它取决于“安全源代码分析”的含义。一个人可以做任何一件令人高兴的事。我认为，问题是当其他人要求进行“安全源代码分析”时，又想知道为什么没有资格进行此分析。

在许多情况下，必须进行这种分析由主题专家（SME）。在最终产品中，中小型企业将提供一个声明，基本上说“我声明此代码是安全的”，但要理解的是，该声明比“我正在寻找一堆已知模式，但没有发现问题”更为深刻。 br />
如果您对中国哲学的真实译本感兴趣，您是否会信任一个对哲学有很多了解的人，并且拥有一大堆备忘单来帮助理解它，但实际上却不知道是中文吗？

想到的一个很好的例子是击中SQL引擎的错误。原谅我没有提供哪个引擎或哪个版本的名称，以便您可以验证，此后我一直找不到它。但是，该错误是严重的。错误出在如下代码中：

int storeDataInCircularBuffer(Buffer* dest, const char* src, size_t length)
{
    if (dest->putPtr + length < dest->putPtr)
        return ERROR; // prevent buffer overflow caused by overflow
    if (dest->putPtr + length > dest->endPtr) {
        ... // write the data in two parts
        return OK;
    } else {
        ... // write the data in one part
        return OK;
    }
}

该代码旨在作为循环缓冲区的一部分。在循环缓冲区中，当到达缓冲区的末尾时，会回绕。有时这会迫使您将传入的消息分为两部分，这没关系。但是，在此SQL程序中，他们担心length可能足够大而导致dest->putPtr + length溢出的情况，这为缓冲区溢出创造了机会，因为下一次检查无法正常进行。因此他们进行了测试：if (dest->putPtr + length < dest->putPtr)。他们的逻辑是，只有在发生溢出的情况下，该语句才是正确的，这样我们才能捕获到溢出。

这创建了一个实际上被利用的安全漏洞，必须对其进行修补。为什么？好吧，对于原始作者不为人知的是，C ++规范声明指针的溢出是未定义的行为，这意味着编译器可以执行其所需的任何操作。碰巧的是，当原始作者对其进行测试时，gcc实际上发出了正确的代码。但是，在以后的几个版本中，gcc确实进行了优化以利用这一点。它发现if语句没有可以通过其测试并对其进行优化的已定义行为！

因此，在少数版本中，即使代码进行了明确的检查以阻止所说的利用，人们仍然拥有带有漏洞利用的SQL服务器！

基本编程语言非常强大可以轻松咬住开发人员的工具。分析是否会发生这种情况确实需要所使用语言的扎实基础。

（编辑：Greg Bacon足够擅长对此进行CERT警告：漏洞注意VU＃162289 C编译器可能会默默地放弃一些环绕式检查，以及与此相关的检查。谢谢Greg！）

#2 楼

我认为您需要成为一名优秀的程序员才能成功，所以我建议成为一名程序员。您的工具包/扫描仪可能遗漏了很多东西。老实说，我不建议您完全依赖工具为您扫描代码，因为漏洞利用会不断变化，并且有人可能以某种方式使扫描程序无法检测到漏洞。

单步执行代码，看看它如何工作以及不应该如何工作，这是确保软件开发安全的基础。让开发人员知道安全问题，这正是生产可靠产品时想要的，也是在代码审查期间真正需要的。

是的，您可以指向并单击并检查扫描仪和工具包的安全漏洞，在宏大的计划中并不是很有效。您是否知道自己看一下代码并确定代码的好坏，会更有效吗？ Waaaay更好。

如果您不知道自己在做什么，请不要尝试通过安全的代码审查，但是如果您觉得自己不对，就不要完全放弃这个想法。在这里您可以进行良好的审查。我建议尝试通过创建自己的模型安全代码审查来学习，并进行几次以确保一切正常。

但是，您仍然不仅应该学习编码，而且还应该学习良好的代码。

#3 楼

值得怀疑的是，安全专家在没有熟练的程序员的情况下能否有效地执行源代码分析。许多漏洞是技术或语法编码实践的结果，这些实践以较小的方式被滥用。缺少分号，等号而不是双等号，在第一天被双重定义的数组边界，但在后续发行版中更改了一个版本，缺少括号，内存泄漏，所有这些都导致了漏洞。有经验的开发人员可能会看到这些，但新手可能不会。

您的安全专家应该做的是鼓励工程师使用自动扫描工具，例如静态代码分析器，模糊测试器和动态应用程序。验证者。帮助工程团队了解输入验证，注入攻击，信任边界。建立意识，即需要适当地对安全缺陷进行优先排序并迅速解决。安排并进行笔测试。而且最重要的是，让工程师对彼此的工作进行代码审查。是的，安全专家应该能够读取代码，但这并不意味着他有资格担任仲裁员。代码安全性。

#4 楼

这取决于您的期望。如果测试人员对安全概念有深入的了解，即使设计人员仅能够遵循代码流程而又不了解其设计问题（例如缺少CSRF保护，仅协议的基本实现等）而导致的安全漏洞，也很可能会发现。对特定的编程语言有更深入的了解。

但是特定于语言的安全性问题，例如缓冲区溢出，一字不漏的错误，unicode或q4312079q的处理，由数据类型的大小和如果测试人员对语言，不当行为以及特定于该语言的典型不安全模式没有更深入的了解，则将找不到签名与未签名等。以Java漏洞的历史为例，即使Java专家开发人员也没有注意到他们通过增加对语言的反射而在语言的沙箱中打出的漏洞，而只有对语言内部有深刻理解的外部专家才发现了漏洞。

#5 楼

是否需要成为一名优秀的程序员才能执行安全的源代码分析？


号。


他能做到吗？在不了解多种编程语言并精通它们的情况下执行安全的代码审查？


否。

在编程方面，除了各种语言的详细知识外，还有很多专业知识工作。这是成为一名优秀的程序员所需要的事情之一，也是从安全角度（或其他质量）角度分析源代码所需要的事情之一。

您不需要成为一名优秀的程序员，就需要精通所涉及的语言。

#6 楼

安全的代码审查不仅需要高级语言的知识，还需要编译器选项的知识，以及代码如何在CPU上真正起作用！高级语言可以高效地编写代码，因为它们隐藏了很多复杂性。但是许多错误和错误隐藏在复杂性之内。正如另一个答案中指出的那样，编译器会尝试做正确的事情，但是您确实需要通过反汇编代码并深入了解其工作原理来了解正在发生的事情。

这种理解也是JavaScript之类的脚本语言所必需，这些语言可将高级代码解释为CPU指令和内存分配。不幸的是，该评论将取决于平台。参见例如https://en.m.wikipedia.org/wiki/Interpreted_language。

#7 楼

为了正确计算出旁道攻击的危险，您需要了解硬件。确实存在丑陋的旁通道攻击，例如在多CPU设置上并行运行一个非特权进程，并与一个特权进程并行执行一些加密/解密任务，并探究哪些共享缓存行以哪种时间模式或以何种方式被弄脏了。定时对特定模式序列的各自传送进行加密。

随着加密算法受到数学家和其他理论家的严格审查，旁道攻击已成为重新打开游戏的越来越重要的方式。缺点是它们必须针对特定的实现，代码和硬件而设计。