是“不直接加载此页面”吗？ PHP 中真的有必要吗？
我本来想问最好的方法是什么，但后来决定我应该问这是否有必要。 我从未见过在 JSP 开发中这样做，但这似乎是 PHP 中的常见做法。 这背后的原因是什么？如果我不采取预防措施，我还应该考虑什么？
I was going to ask what the best way to do this is, but then decided I should ask whether or not it is even necessary. I have never seen it done in JSP development, but it appears to be common practice in PHP. What is the reasoning behind this, and if I do not protect against this, what else should I be taking into consideration?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
这种情况在 PHP 中比其他类似语言更常见的原因与 PHP 的历史有关。 PHP 的早期版本将“register_globals”设置作为默认设置（事实上，它甚至可能不是真正早期版本中的设置）。 Register_globals告诉PHP根据查询字符串定义全局变量。 因此，如果您这样查询这样的脚本：
...脚本将自动定义变量 $hello，其值为“world”，$foo 的值为“bar”。
对于这样的脚本，如果您知道关键变量的名称，则可以通过在查询字符串上指定这些变量来利用该脚本。 解决方案？ 在核心脚本中定义一些魔术字符串，然后让所有辅助脚本检查魔术字符串，如果不存在则退出。
值得庆幸的是，几乎没有人再使用 register_variables，但许多脚本仍然编写得非常糟糕，并且做出了愚蠢的假设，如果断章取义地调用它们，就会造成损害。
就我个人而言，我通过使用 Symfony 框架来避免整个事情，该框架（至少在其默认设置中）使控制器和模板完全远离 Web 根目录。 唯一的入口点是前端控制器。
The reason this is more common in PHP than other similar languages has to do with PHP's history. Early versions of PHP had the "register_globals" setting on as a default (in fact, it may not have even been a setting in really early versions). Register_globals tells PHP to define global variables according to the query string. So if you queried such a script thusly:
... the script would automatically define a variable $hello with value "world" and $foo with value "bar."
For such a script, if you knew the names of key variables, it was possible to exploit the script by specifying those variables on the query string. The solution? Define some magic string in the core script and then make all the ancilliary scripts check for the magic string and bail out if it's not there.
Thankfully, almost nobody uses register_variables anymore, but many scripts are still very poorly written and make stupid assumptions that cause them to do damage if they are called out of context.
Personally, I avoid the whole thing by using the Symfony framework, which (at least in its default setup) keeps the controllers and templates out of the web root altogether. The only entry point is the front controller.
我刚刚在 .Net MVC 系统中找到了一种方法，您可以使用 Apache Rewrites、.htaccess 文件复制 PHP，或者如果您使用 IIS，则使用 web.config 文件。
由于 MVC 模式不需要用户直接访问 aspx 文件，因此不会提供这些文件，而是发送 404。 如果您对包含的文件“inc.php”有命名约定，例如您可以将 *.inc.php 请求重定向到特定文件夹的 404 - 在 Apache Rewrite 中，规则末尾的 R=404 将返回该 HTTP 状态给你的客户。
其中一些示例可能会有所帮助：Apache 重写示例
I just found an approach in the .Net MVC system that you could replicate for PHP using Apache Rewrites, .htaccess files or if you are using IIS, a web.config file.
As the MVC pattern doens't need the user to directly access aspx files these are not served and a 404 is sent instead. If you have a naming convention for included files "inc.php" for example you could redirect *.inc.php requests to a 404 for specific folders - in Apache Rewrite supply R=404 at the end of the rule will return that HTTP status to your client.
Some of these examples may help: Apache Rewrite Examples
它也不仅仅是 php 中的一个安全功能，更多的是有多少基于 MVC 的 PHP 站点发挥作用。 例如，如果在 SugarCRM 中您直接调用模块文件，则页面加载将失败，因为控制器、视图和模型之前未加载，并且您也没有数据库配置/连接信息，因此要确保加载所有依赖项用户被迫通过已知的入口点 - 即index.php
It also isn't just a security feature in php but more of how many MVC based PHP sites function. If for example in SugarCRM you were to call a module file directly the page load would fail because the controller, view and model were not previously loaded and you'd have no db config/connection information either, so to make sure all dependencies are loaded the users is forced through a known entry point - i.e. index.php
我发出 404 页面，并不是作为一种严格的安全措施，而只是因为我不喜欢泄露有关站点内部的信息，甚至是内部文件的名称。
但如果文件只包含函数，那么省略检查并没有真正的危害。
I emit a 404 page, not as a serious security measure but only because I don't like leaking information about the internals of a site, even the names of internal files.
But if the file just contains functions then there's no real harm in omitting the check.
如果您包含来自外部 Web 根目录的所有内容，那么这不是问题，因为没有任何内容可以直接加载。
If you include everything from outside web root then it's not an issue as nothing can be loaded directly.
嗯，这是为了防止敏感内容直接发送到网络服务器。 这当然不是一个包罗万象的安全措施，但它可以帮助您完成特定的设置。
但是，如果您的用户能够从自己的脚本中包含该文件，那么它根本没有帮助
Well, This is to prevent sensitive includes from being sent to the web-server directly. It's certainly not an all-inclusive security measure, but it could help with your particular setup.
If however, your user was in a position to include the file from their own script, it won't help at all
正如其他一些答案中已经提到的，您不需要这样做。 如果某个文件不应由 Web 服务器提供，则不应将其保留在 Web 文件夹中。 包含内容应放置在 Web 根目录之外的目录中。
除此之外，告诉用户页面不存在的正确方法是发出状态 404，使用：
如果你不这样做，那么对于非人类来说很难（例如搜索引擎）区分常规页面和非页面。
As already mentioned in some of the other answers, you shouldn't need to do this. If a file isn't supposed to be served up by the web server, you shouldn't leave it within the web folder. Includes should be placed in a directory outside the web root.
Apart from that, the proper way to tell the user that a page doesn't exist, is by emitting a status 404, using:
If you don't do this, it is hard for non-humans (Eg. search-engines) to distinguish between a regular page and a non-page.
这非常重要，因为如果您正在编辑运行 Google 工具栏的网站，它会找到您内部的 php 文件，然后将它们放入搜索结果中。 这充其量会给用户带来尴尬的体验，但如果您是一个草率的程序员，则可能会泄露数据库连接信息。
This is very important because if you are editing your site running Google Toolbar, it will find your inner php files and then put them into search results. At best this will create an awkward experience for users but if you are a sloppy programmer, could reveal database connection information.