php - index.php 及其内容的保护

Question

黑客能够从服务器下载 index.php 文件的机会有多大(不是结果，而是 index.php 文件的内容)？您是否建议将 index.php 的内容放入 modules/index_content.php，其中 modules 文件夹受 .htaccess 保护并且 index.php 包含唯一的字符串 <?php require_once('modules/index_content.php') ?> ？有道理吗？

Answer 1

源代码泄露可能发生在配置良好的服务器上，并不像您想象的那么罕见。正如其他人所说，如果您的服务器配置合理，那么直接请求 PHP 文件的人就不会有问题。

但是您仍然可能容易受到以下攻击:

可通过备份访问脚本源

许多编辑留下的备份文件带有常见的文件扩展名，例如~ 或.bak。您的服务器可能不会通过 PHP 解释器运行它们，因为它们通常配置为通过文件扩展名运行。留下这些备份文件，您可能会泄露您的来源。

本地文件包含

如果您有一个使用用户输入来读取其他文件的网络应用程序，也可能会出现问题。如果脚本没有正确验证用户输入，它可能容易受到 LFI 的攻击。诸如此类的脚本应该只读取列入白名单的文件，或者至少限制在某个目录中。如果“../”被接受，那么你就有了一个目录遍历漏洞，这会加剧上述两个漏洞的严重性。

除此之外，许多服务器已启用

目录浏览

如果默认文件不存在(index.html、index.php、default.htm 等)，您的服务器将列出目录中的文件。这本身不会泄露任何来源，但确实允许将服务器上的许多文件(服务器端处理或未处理)枚举给恶意用户，从而很容易集中进一步的攻击。<​​/p>

通过备用服务器的来源披露

另一种意外情况可能是当两个 Web 服务器指向(可能是间接地)同一个文档根目录时。如果其中一个 Web 服务器未配置为处理 PHP，则可以公开源。当 Web 服务器配置为针对某些 URL 模式(通常按目录)反向代理到链接的应用程序服务器时，我已经多次偶然看到这种情况发生。例如让 Tomcat 处理/forum 下的一切。

SQL 注入(inject)

几乎每个严肃的 DBMS 都有一个允许它读取系统上的文件的功能。如果您不保护您的数据库输入(请只使用参数化查询)，您可能容易通过此机制泄露源代码。请注意，在这种情况下，源代码泄露是您最后关心的问题。

我敢肯定还有很多其他方式，但这些是我看到的此类披露的一些最常见方式。请记住，安全是一个过程，其范围很广。通常，引起问题的是被视为独立实体的关注点、系统或应用程序之间的交互。