MySQL数据库是否在同一台机器上？如果是这样，您可以只提取数据库文件并在您的机器上重建数据库吗？

正如其他人所说，您可以提取 /etc/passwd ，其中包含有关用户布局的大量信息。如果您可以访问 /etc/shadow，您可以尝试离线破解密码。

如果 Web 应用程序有一个登录门户，则使用密码尝试 mysql 凭据以及“admin”、“root”等。

源代码或配置文件是否包含任何其他访问凭据/API 密钥？网站 SSL 证书是否可读 - 如果可以，您可以在中间连接吗？

您还可以从 /proc/version、/etc/issue 等和网络服务器版本中提取详细信息以查找其他已知漏洞。

最后，来源应该是公开的吗？如果不是，源代码通常被认为是有价值的。您可以检查它是否存在进一步的漏洞。

赫克托的回答有一些很好的例子，但我想强调另一个非常重要的一点：

这不是一个小漏洞

您似乎有这样的印象，如果您能做的“所有”事情就是读取他们系统上的任意文件，那么该漏洞并不是真正的漏洞。我的观点恰恰相反。您必须认识到从纵深防御的角度来处理安全性是最好的。拥有一个无漏洞的系统几乎是不可能的，因此目标是在尽可能多的领域拥有尽可能多的防御层，这样如果恶意行为者发现某个领域的弱点，整个系统的防御将防止他们造成任何真正的损害。现实世界中发生了许多违规行为，不是因为有人利用了某个漏洞，而是因为有一个漏洞可以让他们利用另一个漏洞，让他们做其他事情，直到他们发现了什么真的很危险。

这个小漏洞为恶意行为者提供了对您系统的完全读取权限。这是一个相当明显的安全错误，这一事实使情况更加复杂。如果有问题的公司拥有训练有素的开发人员并定期进行代码审查，那么（IMO）此类代码不太可能进入生产系统。这一事实的意义在于，它表明这不是唯一存在的安全漏洞。您现在可以直接查看系统源代码这一事实意味着发现更多安全漏洞要容易得多。很可能游戏结束了。如果我是一个恶意的演员，我发现我会：

1. 下载整个系统的源代码（可能需要一天，但几乎可以肯定）
2. 寻找任何 SQLi 漏洞（可能有很多），并使用这些漏洞下载整个数据库。我想说他们很可能没有使用适当的密码安全性。从他们的源代码中可以明显看出，这意味着如果他们没有正确保护他们的密码，SQLi 漏洞将允许我：
3. 暴力破解管理员密码。现在我在你的门户网站。但猜猜怎么了？我还没说完
4. 大多数企业用户一直重复使用密码。所以现在我要使用管理员密码，看看我是否可以登录到他们自己的电子邮件帐户。从那里，如果运气好的话，我也许可以进入他们的托管帐户管理。或者可能是工资单或银行账户。一旦我有你的电子邮件密码，天空就是极限，尤其是对于管理员帐户。如果公司的电子邮件由云托管提供商（Office 365 等）托管，那就更好了，我破解的管理员密码让我可以访问电子邮件托管提供商。这使我可以访问公司中的每个电子邮件地址。
5. 也许虽然我发现了一个 SQLi 漏洞并下载了数据库，但他们的密码安全性很好，我无法破解任何东西。现在我开始在你的源代码中寻找 XSS 漏洞。一些简单的社会工程电子邮件，我使用 XSS 在不知道密码的情况下访问系统上的管理员帐户。现在怎么办？
6. 我敢打赌，管理员可以使用系统的某些区域来更新系统。他们有CMS吗？它是否具有诸如 wordpress 等允许管理员从门户网站编辑模板的功能？因为如果是这样我已经用它在机器上安装了一个后门来直接访问底层系统。我将被 Web 服务器执行的任何人的权限所困扰。希望服务器没有以 root 身份运行。如果不出意外，我会安装一个几个月后不会启动的门罗币挖矿机器人，一个隐藏得很好的后门，然后开始花费你的 CPU 时间和金钱来赚钱。除非他们在实时服务器之外拥有系统的干净副本（许多小公司没有），否则他们永远不会让我离开。
7. 在此期间，我将安装一些代码，这些代码会自动向我发送登录到 Web 门户的每个人的电子邮件地址和密码。返回到上面的第 4 步。
8. 如果他们在系统中拥有自己有价值的东西，天堂会帮助他们。社保号码？信用卡？如果他们为员工或客户保留任何此类信息，那么现在就是我的了。

这不是一个孤立的安全问题。这样的事情在实践中从来不存在。

其他答案中有很多好的信息，其中包括很多可能发生的现实，应该认真对待。

不确定您的托管设置，但假设您在 whm 服务器上使用其他帐户，并且该功能用于获取其中的内容，/etc/passwd其中包括系统上的用户这样的行：

username:x:123:654::/home/username:/usr/local/cpanel/bin/noshell
username:x:123:654::/home/username:/usr/local/cpanel/bin/noshell
username:x:123:654::/home/username:/usr/local/cpanel/bin/noshell
etc...

然后，您可以为每个用户名传递：

/home/username/public_html/wp-config.php 

最后得到每个 wp 站点的配置文件。这只是一个例子......最终，您应该尽最大努力保护高于代码的东西 - 作为另一层。

如果向函数提供像 /etc/passwd 这样的本地路径会发生什么：

<br />
<b>Warning</b>:  file_get_contents(): open_basedir restriction in effect. File(/etc/passwd) is not within the allowed path(s): (/home/uservalue/public_html) in <b>/home/uservalue/public_html/test.php</b> on line <b>2</b><br />
<br />
<b>Warning</b>:  file_get_contents(/etc/passwd): failed to open stream: Operation not permitted in <b>/home/uservalue/public_html/test.php</b> on line <b>2</b><br />

“open_basedir 限制生效。”