用 IRify 深入探索 WebShell 中的 Source/Sink 挖掘

?()表达式：

在之前的规则中，常常会像下面这样写。

__GET as $sourceaa(* #{include: <<<CODE* & $sourceCODE}-> as $sink)

比较诟病的是，这样找到的sink 点并非真正的sink 点，而是topdef之后的结果。?()的出现类似于?{}，都是对中间结果进行过滤，然后影响结果的值。

样例：

<?phpa(1,2);a($a,2);//参数中含有consta?(*?{opcode: const}) as $sink//参数1为consta?(*?{opcode: const},) as $sink//参数1，2均为consta?(*?{opcode: const},*?{opcode: const}) as $sink

Webshell 大家并不陌生，无论是红蓝中对 webshell 的检测还是免杀，也是老生常谈的问题。在2023年，我也参加过伏魔挑战赛，我也会用一部分我对 webshell 的理解和 ssa 结合，重新对 WebShell 审视 source  和 sink ，并且针对 WebShell 实现一些规则。

在 PHP 漏洞挖掘的过程中，我们常常认为 Source 点为 $_GET、$_POST、$_REQUEST、headers 等一系列全局可控函数，sink 点尝尝为 eval、system 等一系列常见的代码执行 /命令执行的代码中，但是在 PHP 是动态运行。支持 php 中的常见间接函数调用。

那么从 WebShell 的编写来说，我们常常需要绕过一些常规的 Sink 点，像REQUEST、POST、GET 等一些常规的 source 点都会被 ban 掉，那么是否存在一些冷门的 source 点呢？

冷门 source 点：

• phpinfo()

在phpinfo中，会打印出这次请求的全部信息，可以当作一个非常规source点去用。