index.php及其内容的保护

Question

黑客有什么机会从服务器下载index.php文件(不是结果,而是index.php文件的内容)？您是否建议将index.php的内容放入modules/index_content.php,其中modules文件夹是.htaccess protected AND index.php包含唯一的字符串<?php require_once('modules/index_content.php') ?>？是否有意义？

Answer 1

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

然而，您仍然可能容易受到以下影响：

可通过备份访问脚本源

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

本地文件包含

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

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

目录浏览

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

通过备用服务器泄露源代码

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

SQL注入

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

我确信还有很多其他方式，但这些是我看到这种披露的最常见方式。请记住，安全是一个过程，并且范围广泛。通常，问题的根源在于被视为独立实体的关注点、系统或应用程序的交互。