AKun Wallpaper 代码审计实战分析5

Posted 2022-02-06 rpsate

前言

前面四篇文章已经分析出了大部分的严重和高危漏洞，同时分析了这些漏洞的原理和修复方法。在这一篇文章中将继续分析fortify扫描出的漏洞。

AKun Wallpaper 代码审计实战分析1：https://blog.csdn.net/rpsate/article/details/122354690

AKun Wallpaper 代码审计实战分析2：https://blog.csdn.net/rpsate/article/details/122387998

AKun Wallpaper 代码审计实战分析3：https://blog.csdn.net/rpsate/article/details/122400520

AKun Wallpaper 代码审计实战分析4：https://blog.csdn.net/rpsate/article/details/122417856

漏洞分析1

在fortify的左边漏洞视图中看到了 Header Manipulation:Cookies，fortify的解释是： Including unvalidated data in Cookies can lead to HTTP Response header manipulation and enable cache-poisoning, cross-site scripting, cross-user defacement, page hijacking, cookie manipulation or open redirect.，翻译成中文是：在 Cookie 中包含未经验证的数据可能会导致 HTTP 响应标头操作并启用缓存中毒、跨站点脚本、跨用户破坏、页面劫持、cookie 操作或开放重定向。

判断此处是否存在漏洞就要分析数据的来源和去向，其数据来源是数据库 admin_root表中的id和用户名，其中户名在写入数据库时已经过滤了特殊字符，但是为了避免 CRLF注入，也需要吧 %0d%0a和 (\\r\\n)过滤。其中id是数据库自动生成的，不会存在危险数据。

CRLF注入：https://blog.csdn.net/rpsate/article/details/120601703

再看cookie数据的去向，通过全局搜索 $_COOKIE可以得知cookie的去向。通过全局搜索发现只有 admin/index.php的40行使用了cookie数据，而且也对js特殊字符过滤（前面已经修复），所以此处没有其他漏洞了。

漏洞分析2

不安全的随机数生成函数 mt_rand。这个函数每生成一个随机数就要更换一次随机数种子，不然可以通过已得到的随机数反推出随机数种子，然后再通过随机数种子推算出随机数。此处随机数的作用是获取随机的字体大小，验证码在图片种的随机的位置，随机的字体等等。这些随机数据给用户知道也无关紧要，最重要是的不能让用户推算出验证码。

随机数是根据随机数种子计算得到的，而且随机数与随机数种子是一一对应的关系。随机数生成函数：R=f(x)，其中x就是随机数种子，R就是随机数。

再举一个通俗易懂的例子：我们把随机数种子比作一颗种子，随机数比作一个小树苗， mt_rand()执行一次那么树苗就长大一岁。基因一样的种子长大后长得到的树苗一模一样，但是每个年龄段的容貌是不同的。所以同样的随机数种子获得的随机数是一样的（基因一样，所以容貌相同），不更换随机数种子的情况下，每次mt_rand获取的随机数是不同的（每个年龄段的树苗容貌不同）。

看到 lib/string.func.php，这个文件中 buildRandomString函数是生成验证码的函数。此处验证码生成方式是通过 str_shuffle函数随机打乱字符串，然后取前4位字符。此处没有用到 mt_rand函数，所以不可以推算出验证码，不存在漏洞。

漏洞分析3

使用了Hardcoded password（硬编码密码），意思就是将密码直接写在了代码中。这是数据库的连接密码，只能写在代码中，所以此处代码没有问题。但是要注意的是在真实的业务环境中不能如下图所示一样使用弱口令。

漏洞分析4

此处如果在浏览器上记录密码，那么下次访问此页面时浏览器会自动填入。自动填入密码有一定泄密风险，但是用户可以选择不记录密码，这与代码无关（也可以通过特殊的代码让浏览器不自动填入），所以这需要用户养成良好的习惯。

漏洞分析5

看到 admin/doImageAction.php的145行左右，此处存在一个函数 move_uploaded_file，这个函数的作用是保存用户上传的文件。我们只要过滤了非法文件就可以避免文件上传漏洞。

该文件上传功能设置了扩展名白名单，然后去除了上传目录的执行权限，通过md5设置唯一文件名，所以该处文件上传不存在漏洞。

漏洞分析6

看到 admin/doLogin.php的10行和23行，fortify是检测到了addslashes函数对获取的用户名进行了过滤，但是怀疑存在sql注入漏洞。我们看到23行，在sql语句中可控参数 $get_username两边是有引号的，所以对 addslashes对引号过滤是可以防止sql注入。我们要知道某些情况下 addslashes函数可以通过宽字节绕过。虽然我们现在数据库现在用的是utf-8编码，无法通过宽字节绕过，但是该套系统部署在其他用 GBK的环境中就可以通过宽字节绕过 addslashes函数了，所以此处应该把 addslashes换成 mysql_real_escape_string。

要注意：mysql_real_escape_string要与 mysql_set_charset搭配用，且 mysql_real_escape_string需要用在 mysql_set_charset后面。前面修复漏洞时已经将mysql_set_charset写在了 mysqlConnect函数中，所以修改代码应该如下图所示：

$get_username = $get_username;
$get_username = mysql_real_escape_string($get_username);

漏洞分析7

看到 core/core.php的128行，此处的 $searchContent也是仅仅使用addslashes过滤，其中 $offset和 $pageSize来自 getPageImageInfo函数，该函数把$offset转化成了整数，所以无恶意数据，$pageSize用户不可控。所以此处我们只要处理好searchContent即可。

修改后的代码如下图所示，还有其他sql注入漏洞和此处一样，大家可以用同样的方法修复。

$searchContent = mysql_real_escape_string($searchContent);