Feklickons.php文件也是某些方法定义，也有某些参数过滤，比如GET请求的ID和页面，POST请求的搜索等。我们也可以在这里关注一下，看能不能绕过他们。然后返回index.php，看一下default.php文件的内容。Default.php文件应该是渲染的前端页面。我就留在这里，但是我看到CMS的整个入口都已经在这里完成了，但是我没有看到URL跳转是怎么处理的。我只看到了默认页面的一次跳转，没有列表等其他细节。结合在线环境查看其他页面的网址。看到列表页面的网址是product.php，并返回到网站的根目录。根目录中没有product.php文件，但有一个。根目录中的htaccess文件。请检查该文件的内容。

那个。htaccess文件将product.php文件重定向到Templete目录。检查一下。

这个CMS是混合编写的，所以HTML里面有PHP代码。这里整个CMS的架构逻辑基本明白了。接下来看可能有漏洞的函数，分析代码。在梳理程序架构的时候可以看到，SQL注入防护只保护GET请求的数据，POST防护没有，那么我们先来看看整个程序在哪里使用POST提交。通过在搜索处查看POST提交的数据，在搜索处进行SQL注入的概率很大，所以先看一下搜索处有没有SQL注入。

先抓取包，看一下参数是如何传递的。

根据htaccess文件，该文件被直接特定为模板\默认\包括\search.php。查看文件。像index.php一样，我们已经介绍了web_inc.php和Feklickons.php文件、web_inc.php文件的定义，下面的变量$search应该是在Feklickons.php定义的，所以我们这里重点关注Feklickons.php文件。根据刚才搜索时提交的代码，搜索参数已经提交，这里判断先输入verify_str。根据前面的代码分析，这应该是参数过滤和跟踪。具体的词和符号比如select都是过滤的，但是这里的参数过滤显然不是很严格。比如ascii码可以用来绕过和返回检查test_input的内容。

先用str_replace函数替换%符号，然后用trim去掉两端多余的空格，再用stripslashes删除反斜杠，最后用htmlspecialchars把它们变成HTML实体。看到这里，感觉成功的可能性可能不大。然后往下看，看以后怎么过滤。替换为\_，%替换为\%，然后转到search.php文件。跟踪searchprolist方法，并在搜索位置检查查询方法。首先根据空格划分搜索条件，然后组装SQL语句，然后直接代入SQL语句中执行，也就是说不能使用空格。

到现在可以发现，某些字和符号是不能用的，所有数据都会物化输出，%会被百分比代替，前端和后端的空格会被清除，最后用空格进行SQL语句分段和拼接，但是这里的测试还是失败了很久。如果哪位大老板知道什么有效载荷可以绕过，可以问我。