代码审计：如何在全新编程语言中发现漏洞？

二，代码与数据可转换

一门新的编程语言，为了使用方便，常常需要把一些代码转化成数据，或者把一些数据转化成代码，这可能导致安全问题。下面我们将以几个案例演示这一点，

案例一 不安全的模板渲染

模板渲染是编程语言常见的功能，有时具有一些安全问题。

前端部分

对应代码

模板部分

我们可以看到，开发者已经殚精竭虑的做了安全限制，尽可能的避免漏洞，每一个变量的限制都在避免产生漏洞，然而，依旧产生了漏洞。这是因为这依旧没能完全分离数据与代码，导致安全问题。

我们可以在user部分输入)/*

接着在punc部分输入*/ 任意一个无字母数字的shell ?>

让punc从数据变成代码，跳出安全限制，顺利getshell。

要知道，开发者已经殚精竭虑的做了安全限制，却仍然被突破。错误的渲染方式可能导致数据与代码没有严格分离，造成漏洞。

案例二 跨语言的数据传递

这种新的编程语言有时需要与其他语言的脚本交互，传输数据时就可能采用标记语言，比如xml、json、yaml等等。或者是使用配置文件来储存一些关键常量。这样有时会造成安全问题。

yaml是一种可以储存数组、对象、列表等各种数据类型用于书写配置文件或者跨语言传输数据使用的标记语言。

以yaml反序列化漏洞为例。

python部分

功能是给在线解压的压缩包写一个配置文件

yaml部分

当我们以某种方式覆盖这个yaml文件，换成如下内容，就会形成反弹shell。

三，可预测的安全处理方式

一门新的编程语言，势必会有一些逻辑代码来提高安全性，当我们不是选择拒绝非法输入而是对非法输入进行安全处理时，就可能造成安全问题。

案例一 人性化矫正输入

有时我们会善意的为输入者可能的错误输入形式进行矫正，这可能为攻击者提供便利。

以CVE-2022-30333为例

在unRAR小于 6.12的版本中，存在一个由于人性化矫正输入引发的漏洞，简单的来说，我们可以输入解压后的文件路径，开发者已经在这里殚精竭虑的做了安全限制，会把../等尝试目录穿越的操作认为是危险。但是，仍然产生了漏洞。函数DosSlashToUnix()出于人性化的考虑把\（反斜杠）转化为/（正斜杠），使得..\能够变成../绕过安全检查，导致目录穿越。最终效果就是可以在任何目录下写入任意文件。

案例二 不安全的安全性过滤输入

我们如果修改非法输入而不是拒绝非法输入，就很可能产生问题。

以sql注入的不成熟防御为例。

有的人可能会说黑名单不全，事实上就算把sql所有保留字列入黑名单依旧存在问题，因为你并不是拒绝输入而是改写输入，这个情景下可以双写绕过。

输入?id=' oorr 1=1#

因为输入被改写了，可预测的改写形式能够被利用，造成绕过。

案例三 可预测的密钥加密

当我们把某个认为攻击者不可能获取的系统变量作为密钥，为程序的安全性沾沾自喜时，也许就会翻车。

以flask模块的session为例：

flask的session放在cookie中，通过密钥加密保证其未i被篡改。而这里密钥就是主机名，如果通过某种方式获取了这一变量，就会导致session被攻击者完全控制，攻陷网站所有的用户以及管理员。

后续服务中提供的下载功能具有缺陷，组合拳导致session也沦陷。

四，意外的可控变量

这门全新变成语言肯定需要与用户交互，从而控制一些变量。我们通常会对其进行安全检查，所以，出现意外的可控变量（我们认为不可控但实际上用户可控）就很容易导致安全问题。

案例一 把变量储存在两个地方

当我们把变量储存在两个地方，就可能导致安全检查失效。

以二次注入为例：

这里实现了一个用户登录功能，开发者已经在这里殚精竭虑的做了安全限制，各种转义处理。但是他把变量储存在了两个地方，导致漏洞仍然出现。

我们可以发现那个非法输入藏在session逃过了安全检查，如果构造username=' or 1=1#

就可以修改所有用户的密码。

案例二 认为某可控变量不可控

实际上编程语言中即使采用获取常量的方式获取一些变量，也不能大意，它们也许还是可控的。

以User-agent注入为例。

可以看到开发者已经在这里殚精竭虑的做了安全限制，安全意识很强，但是依旧出现问题。

这都是因为开发者使用的语言中，获取变量的方式也许是常量形式，开发者认为其不可控引起的。

结语

具有安全意识的开发者仍然可能产生漏洞，因为很多开发用不到的特性、甚至编程语言官方非预期的情景不是开发者掌握的知识，代码安全审计是必要的。这门全新的编程语言可能出现的问题却是任何编程语言代码安全审计需要注意的共通之处。