众包代码示例中安全漏洞的性子和普遍性到底是什么？面对这些漏洞，我们又该如何选择安全的代码段？为了帮助提高共享代码段质量，研究者也开拓了一个工具，许可堆栈溢出用户在将代码段上载到平台时检讨个中的漏洞。雷锋网 AI 开拓者将该研究核心内容及结论整理编译如下，或许能够给广大开拓者重用共享代码时些许启示。
研究背景
一贯以来，软件开拓的一个紧张目标因此及时和经济高效的办法交付高质量的软件；以是代码重用也被视为一种公认的实践办法，共享代码片段和代码示例也是一种常见的学习办法。新手乃至更高等的开拓职员利用在这些平台上共享的代码示例和解释，学习如何实行新的编程任务以及利用某些 API。
个中，这些重用的代码片段来自许多不同的源代码和不同的形式，例如：第三方库、开源软件和问答（Q&A）网站等。但比来有研究表明，在问答网站以及 GitHub 中托管的开源软件存储库的知识流和知识共享中，一些代码片段不仅质量差，而且还是有病毒的；这些片段乃至还在 GitHub 上共计 2859 个项目中被重用。
安全性是质量的一个主要方面，如果易受攻击的代码片段从堆栈溢出迁移到运用程序，这些运用程序将随意马虎受到攻击。
历史创造及现状
此前，有很多研究职员通过对重用代码片段进行检测，创造了这些问题：
Xia 等人表明大量开源系统重用过期的第三方库，这可能会对软件造成有害影响，由于它们可能会在软件中引入安全毛病。
Abdalkareem 等人检讨了 f-droid 存储库，并确定了堆栈溢出 post 和 android 运用程序之间的克隆。他们创造，从 so posts 复制的代码会对运用程序的质量产生不利影响。
Yang 等人剖析了托管在 GitHub 上的 909k 个非 fork python 项目，个中包含 290m 个函数定义，以及在堆栈溢出中捕获的 190 万个 python 片段，并对块级代码克隆堆栈内和堆栈间溢出以及 GitHub 进行了定量剖析。
Akanda Nishi 等人研究了两种盛行的软件开拓信息源之间的代码复制：堆栈溢出问答站点和软件开拓教程，以理解重复信息随韶光的演化。
安等人调查了 399 个 Android 运用程序和堆栈溢出帖子之间的克隆。他们创造了 1226 个代码片段，这些代码片段被 68 个 Android 运用程序重用。代码片段的重复利用导致 1279 例潜在的容许证冲突。
Fischer 等人创造从堆栈溢出复制到 196403 个Android 运用程序的不屈安代码片段，已在 google play 上发布。
Zhang 等人通过检讨 API 调用的误用，研究了堆栈溢出代码片段的质量。他们报告说，大约 31% 的剖析代码片段可能包含可能导致失落败和资源泄露的 API 误用。
Rahman 等人检测到七种安全气味，表明 IAC 脚本中存在安全漏洞，并识别出 21201 次安全气味，包括 1326 次硬编码密码。
Zahedi 等人研究了 GitHub 存储库中的问题主题，创造个中只有 3% 与安全性干系。这些安全问题中的大多数是密码问题。
Pletea 等人研究了 GitHub 的安全干系谈论，并报告它们代表 GitHub 的所有谈论的大约 10%。他们还报告说，与安全有关的谈论每每与悲观感情有关。
Acar 等人对生动的 GitHub 用户进行了一项实验，以考验安全干系研究中招募便利样本的有效性。他们创造，参与者的自我报告状态（即学生或专业开拓职员）和参与者的安全背景都与他们成功完成安全任务的能力无关。
但目前，大多数在堆栈溢出上的代码片段安全性方面研究集中于 Java 和 Python；忽略了 C++——最盛行的第四种编程措辞（https://www.tiobe.com/tiobe-index/）。
它是嵌入式资源受限程序的首选措辞，并广泛运用于大型和分布式系统中；因此 C++非常随意马虎涌现误用（例如：内存破坏缺点），这很随意马虎导致易受攻击的代码和可开拓的运用程序，这表明 C++代码段中的漏洞可能会产生更严重的影响。本文则旨在补充 C++措辞代码共享的安全性研究空缺，并帮助更多开拓者理解堆栈溢出时共享的代码示例中安全漏洞的性子和普遍性。
研究维度及问题
研究职员创造，堆栈溢出问题是在编程问答（Q&A）社区被问得最多的。因此，对堆栈溢出的研究在软件界具有主要意义。为了使得研究结果更具代表性，研究职员从以下两个维度对堆栈溢出中共享的代码示例中的 C++漏洞进行了实证研究：
普遍性 紧张对堆栈溢出数据集中包含的某个称为 StoTrOrm 的 C++漏洞类型进行了深入研究；并剖析了它们随韶光，特殊是它们迁移到 GitHub 项目中的蜕变过程。
传播度 研究如何在 GitHub 存储库中重用易受攻击的代码片段。
理解在源代码示例中 C++漏洞的普遍性和传播度
环绕源代码示例中 C++漏洞的普遍性和传播度两个维度，研究职员磋商了以下问题：
1. 堆栈溢出代码段中的 C++漏洞有多普遍？
2.GitHub 存储库中如何重用易受攻击的堆栈溢出 C++共享代码？
研究过程及数据集
案例研究的总体步骤
为了研究堆栈溢出 posts 的演化及其与 github 的关系，利用了 sotorrent 数据集版本 2018-09-23。
这个版本的 sotorrent 包含了从 2008 年到 2018 年的帖子。统共有 41472536 个问答帖子和 109385095 个帖子版本，个中 206560269 个帖子版本包含 6039434 个软件项目链接。有 3861573 个链接指向公共 GitHub 存储库。
Sotorrent 供应对堆栈溢出内容十年的版本历史的访问。如图 2 所示，可以独立访问全体 post、单个文本或代码片段。
Sotorrent 供应的历史数据
研究结果
终极，研究职员从至少一个 GitHub 项目中重用的 72483 个 C++代码片段中，创造了属于 29 种不同类型的漏洞达到 69 个；而这 69 个易受攻击的代码片段，用于 Github 文件中的有 2589 个，并且从堆栈溢出传播到 Github 的最常见漏洞是 CWE150。
这里，CWE（Common Weakness Enumeration）是社区开拓的通用软件安全弱点列表。它可以作为一个软件安全工具的丈量棒，以及作为识别、缓解和预防弱点的基线。CWE 的目的是促进在程序分发给"大众之前，有效地利用能够识别、创造和解决打算机软件中的缺点和漏洞的工具。
问题一、堆栈溢出代码段中的 C++漏洞有多普遍？
总体上，所有 C++回答从 2008 到 2018 的分布如下图所示。2013 年既是 C++回答最多的一年，也是 C++在 GITHUB 项目中迁移最多的时候。
C++中按年份分布的回答
研究职员对代码片段的手动检讨创造，69 个回答中存在 99 个易受攻击的代码片段。通过查看易受攻击回答的分布，他们创造最易受攻击的答案是在 2011 年创建的，如下图所示。
每个回答中的 CWE 频率
代码片段中 CWE 的频率如下图所示，可以看到 CWE-1006 和 CWE-754 是最常见的安全隐患。
代码片段中 CWE 的频率
下表解释了已找到的 CWE 列表。有关 CWE 的完全解释，请拜会（https://cwe.mitre.org/）。
不同类型的 CWE C++漏洞及其频率，如我们在堆栈溢出数据集中所不雅观察到的，X 轴上的每一个刻度表示一年的末了一个/两个字母，例如 2016 对应 16，2008 对应 8
下面是研究职员所检讨代码片段中创造的一些漏洞示例。
漏洞示例一
下面这个代码片段可能很危险。
显示由于利用禁绝确的利用方法的 RAND 函数而导致的薄弱性（CWE-1006、CWE-477、CWE-193、CWE-754）
具有计数参数（如「len」）的函数应将终止的「null」作为额外字符考虑在内。但这个函数实际上是在实行 s[len]=0 时写入字符'len+1'。这便是 CWE-193:OffbyOne 缺点漏洞，它可能导致不可预测的行为、内存破坏和运用程序崩溃。如果产生一个分外的并且总是在最大长度上通报一个小于期望值的数字，函数就正常事情，否则就可能崩溃。
CWE-193:OffbyOne 缺点漏洞
https://cwe.mitre.org/data/definitions/193.html
行's[i]=alphanum[rand（）%size of（alphanum）-1]'也有问题，由于'alphanum'的大小是'63'，个中索引第 69 个字符串的末了一个字符是'null'。因此，偶尔会在天生的「随机」字符串中包含一个空值。此漏洞可归类为「CWE-754：非常或非常情形的禁绝确检讨」，个中禁绝确的数字可用于返回导致崩溃或其他意外行为的函数。另一个得当的种别是「CWE-1006：缺点的编码实践」。换句话说，利用此算法天生的随机字符串也会使得在字符串中间包含「null」。
CWE-754：非常或非常情形的禁绝确检讨
https://cwe.mitre.org/data/definitions/754.html
此外，在 C 和 C++中，「反汇编」是一个过期的函数。因此，另一个漏洞种别是「CWE-477：利用过期功能」，这是软件质量退化的一个紧张缘故原由。还有一个漏洞存在于代码中，由于开拓职员在调用函数之前没有利用随机种子。因此，天生的随机数根本不是「随机」的。此外，「rand%mod」不是一个好的做法，由于它返回的低位不再是随机的。
rand%mod：
http://c-faq.com/lib/randrange.html
漏洞示例二
显示了由于在不检讨返回分外条件的情形下利用 malloc 函数而导致的漏洞（CWE-1006、CWE-252、CWE-789、CWE-476）
此回答中的代码片段利用「malloc」分配内存，并将其指针通报给 qt 库中须要有效指针的函数。如果 malloc 失落败，malloc 返回指针可以设置为空。因此，纵然要求的内存量很小，也必须检讨 malloc 的返回指针 [54]。在本例中，不检讨 malloc 的返回值。此漏洞称为 CWE-252[55]；未经检讨的返回值。如果 malloc 失落败，则会发生空指针取消引用。
malloc 返回指针
https://docs.microsoft.com
CWE-252
https://cwe.mitre.org/data/definitions/252.html
漏洞示例三
显示了由于用户输入是 volved 而导致操作系统命令注入的漏洞（CWE-78，CWE-1019）
所示的函数易受代码注入（OS 命令注入）攻击，由于用户输入的命令是输入的，而不是检讨的。换言之，任何具有程序特权级别的命令都可以在没有任何缺点或警告的情形下实行。
漏洞示例四
显示由于此函数中的第二个参数可能包含多个由「；」分隔的路径而导致的漏洞（CWE-754、CWE-252、CWE-426）
以编程办法处理系统路径，或程序搜索的不同路径。这个操作很危险，该当小心操作。例如，此函数中的「path」可以包含由「；」分隔的多个路径，如：「/usr/share/lua/foo/bar/evil/path」。在路径中有一个不受信赖的搜索路径会产生以程序权限实行任意代码的可能性，并重定向到可能触发崩溃的缺点文件。此漏洞称为 CWE-426:不受信赖的搜索路径。搜索可能导致程序实行，进而导致非常或非常情形；即 CWE-754：对非常或非常情形的不当检讨。此外，不检讨代码段中函数的所有返回值。因此，代码片段还具有 CWE-252：未检讨的返回值。
CWE-426:不受信赖的搜索路径
https://cwe.mitre.org/data/definitions/426.html
漏洞示例五
显示了由于越界读取和短缺检讨变量大小而导致的漏洞（CWE-20、CWE-125、CWE-1019）
在漏洞示例五所示的代码中，由于「current index+size of（t）」可能会大于「vec」的大小，而存在 CWE1019:validate inputs 漏洞。此外，当索引超过限定时，可能会发生信息泄露或 CWE125；存在「越界读取」漏洞。
漏洞示例六
如果包含空值的输入字符串（CWE-158，CWE-1019）失落败，则所有定义的函数都有漏洞
所示关于如何验证文件名是否以「.txt」结尾的代码中，包含了 answer post 原始代码片段中六个方法的函数代码及其基准。此代码段中定义的其他函数的漏洞与这两个易受攻击的函数完备相同。但如果函数中的文件名包含空字符，则以上所有方法都将失落败。这是绕过 web 运用程序防火墙和文件上传程序的常见技巧。示例：对付以上所有函数，验证「shell.txt\0.php」将返回 true。
问题二、复制到 GitHub 的易受攻击的代码示例频率
我们创造的大多数易受攻击的代码段都是函数或函数的一部分。因此，研究职员利用了基于 sourcerercc 等克隆检测工具的一些启示式方法，在链接的 GitHub 项目中搜索并找到 10 个类似的代码。
下面给出了两种方法（选择关键字和随机关键字）的结果，并将其与基线方法进行了比较。
结果
69 个易受攻击的答案的 GitHub 文件总数为 2859 个 GitHub 链接，这些链接显示不才表中，由 CWE 定义分隔。研究职员通过干系的算法创造 287 个 GitHub 易受攻击的文件都可能存在安全漏洞。
GitHub 存储库中利用所选关键字算法的 CWES 检测
问题三、修复复制的易受攻击代码示例的概率
研究职员创建了一个新的 web 运用程序，使评审过程更加高效和系统。通过审查系统，他们评估了迁移到 GitHub 的易受攻击的堆栈溢出代码段是已修复还是仍包含该漏洞。
结果
在被检讨的 287 个 GitHub 文件中，有 34 个文件中的漏洞得到了纠正，其他 253 个 GitHub 文件仍旧存在漏洞。如下图代码所示，更正了 CWE-789 和 CWE-252 两个漏洞。
在 GitHub 文件中，堆栈溢出中回答的修复与部分代码改进
CWE-252
https://cwe.mitre.org/data/definitions/252.html
CWE-789
https://cwe.mitre.org/data/definitions/789.html
如下图代码所示，对 cwe-125、cwe-category-1019 和 cwe-20 进行了更正。
在注释提到的 GitHub 文件中修复了代码
CWE-125
https://cwe.mitre.org/data/definitions/125.html
CWE-category-1019
https://cwe.mitre.org/data/definitions/1019.html
CWE-20
https://cwe.mitre.org/data/definitions/20.html
用户对代码中存在漏洞的意见下图中显示了一些用户对其项目中的漏洞的相应。可以看到，有很多开拓者在重用这些代码片段时，并没有把稳到个中所包含的潜在威胁。
用户对其代码中的安全漏洞的相应
用户也针对自动检测漏洞的有用性，进行了个人意见的谈论。大部分人都认为检测漏洞是一个非常有用且重用的事情。
用户对有助于未来开拓的自动漏洞剖析的见地
用户也揭橥了对漏洞处理的最佳方法，大多数实践者赞许利用自动安全机制来检测代码中的漏洞。他们表示，利用浏览器扩展和脱机工具运行临时堆栈溢出方法比其他方法更有效，可以将代码示例中的漏洞奉告用户。
如何奉告开拓职员代码示例中的潜在漏洞见地
办理方案
在我们收到的针对 GitHub 所有者的 117 个问题的 15 个相应中，40% 指出了代码中存在漏洞的可能性，条件是他们的输入数据不是动态的，13.3% 承认代码中存在漏洞，但不愿意修复。
GitHub 所有者选择对其代码中存在的漏洞进行了注释
为了奉告用户代码中存在的漏洞，研究职员也开拓了浏览器扩展。该浏览器扩展旨在防止开拓职员重用此类易受攻击的代码段，并向他们推举更好的替代方案，即在其他堆栈溢出帖子中利用不易受攻击的代码段。
当开拓职员访问堆栈溢出 post 时，扩展将被激活。该扩展参考堆栈溢出中易受攻击的 C++代码片段的数据库，以确定在 POST 中供应的办理方案是否是不屈安。如果确实创造供应的办理方案易受攻击，则扩展将向开拓职员显示一条警告，并阐明代码片段易受攻击的缘故原由。
警告截图
然后，扩展将推举来自其他堆栈溢出帖子的不易受攻击的类似代码段，以便开拓职员可以重用这些安全代码段，而不是易受攻击的代码段。不过，该扩展目前也存在一定的有效性威胁，这也与之前所利用的检测方法有关，利用这一启示式方法来检测从堆栈溢出到 GitHub 的易受攻击的C++代码片段，可能会存在部分代码丢失的情形。
因此，在面对复制而得的代码时，只有小心严谨才是王道啊！
！
！
论文地址：
https://arxiv.org/pdf/1910.01321.pdf
浏览器扩展：
https://github.com/paper-materials-crowd-sourced/materials
干系资讯：
https://fossbytes.com/copying-codes-from-stack-overflow-leads-to-vulnerable-github-projects/
雷锋网 AI 开拓者
