网页模型（构建动态网页的方法）- 安全和实用（清晰）视图

Posted 2023-03-05

【中文标题】网页模型（构建动态网页的方法）- 安全和实用（清晰）视图

【英文标题】：Web page models (approaches to build dynamic web) - security and practical (clarity) view

【发布时间】：2013-11-14 04:26:59

【问题描述】：

这种根据 url 向用户查看页面的特定方法的优点和缺点是什么？ 据我所知，构建网页有两种基本方法：

www.whatever.com/index.php?page=userProfil.php www.whatever.com/userProfil.php 好吧，我将第 1 点和第 2 点称为模型，并假设我想使用 php + mysql + apache + 客户端 javascript（用于用户检查） - 仅用于背景信息。如果我使用 sererlets、jsp 和 Tomcat，模型的基本思想将几乎相同，但我认为会有一些小的差异。所以以我的平台结束它是 php +mysql ... 另一件事是，出于安全和未来证明的目的（将平台从 php 更改为另一个）不是好主意（听说过）显示“.php”或“.html”或任何文件类型。 所以可以选择使用这个（漂亮的 url）： www.whatever.com/userProfile/

如果我用谷歌搜索得很好，它叫做 mod_rewrite，我会使用一些规则将我的模型（参见 add 1 和 2）转换为 add 3。 老实说，我现在对 add 3 还不太了解。

所以：

我认为模型 1 和 2 可以称为 “文件结构模型”。我的意思是 add1 我有一页（一个文件）并包含一些模块。所以在 add 1 中我每次调用一个文件。添加 2 我每页都有新文件。因此，对于 add 2 我调用多个文件 - 对于不同的页面不同的文件。 对于 add 3，第 1 点和第 2 点对用户来说有点隐藏 - 我认为这很好，因为他不知道我的文件结构（它的 + 是为了安全），而且它看起来更好并且用户可读性更好。李>

结论和问题：

add 1和2的优缺点——文件结构

add 3的优缺点

add 1 和 2 结合 add 3 的基本概述（1,2 文件结构 + add 3 的样子）

我知道如何使用 add 1 和 2，所以我可能会使用其中一个，然后我想添加 add 3（当我学会它时） - 可以吗？

【问题讨论】：

更好地使用Front Controller Pattern，使用简单的.htaccessfile 你有漂亮的url和你想要的任何路由，从你的文件系统结构which should follow [common autoloading约定中解耦]。

@moonwave99 我有点困惑，前端控制器模式 = my add 1？

是的，有点。但是你不应该依赖文件名，而应该依赖更好的路由 see [this router library 例如]。

【参考方案1】：

第一种方法有一个明显的安全问题：恶意用户很清楚您包含基于用户输入的文件，因此您应该正确清理您的 page 变量并确保包含密码等敏感数据的文件'不可包含（即在page 中仅省略字母数字字符[没有.、..、/、空字节、unicode 特殊字符等]，仅允许将 '.php' 文件扩展名为包括在内，将敏感数据放在与调用脚本不同的目录中，甚至不在 www-root 之外等等）。

第二种方法更好 IMO，没有明确的文件包含。但这表明您使用的 PHP 不一定是坏事，但理论上可以缩小攻击者对可能漏洞的搜索范围（想象一下，有人发现 PHP 中的一个严重漏洞，然后世界各地的网站都因为脚本小子搜索而遭到攻击受害者通过谷歌inurl:index.php）。

两种方式都有其 SEO 问题 (the first has more gotchas than the second)。就像您希望迁移到另一个平台一样，正如您所写的那样，您要么需要模拟“.php”扩展名，要么由于 URL 更改而丢失一些流量（即使设置了重定向）。

我个人更喜欢第三种方法。在 Apache 服务器上设置并不难，基本上需要 .htaccess 中的几行代码（当然，您可以自定义所有内容）：

RewriteEngine On
RewriteCond %REQUEST_FILENAME !-f
RewriteCond %REQUEST_FILENAME !-d
RewriteRule ^(.*) index.php

在引入这些行之后，您将获得对不存在文件的所有请求，这些文件将被馈送到您的 index.php。然后，您需要在应用程序中解析和清理$_SERVER['REQUEST_URI'] 变量，并从数据库、文件或其他任何地方检索页面。这样，您将获得对 SEO 友好的 URL，并且向攻击者披露的信息更少（至少对于没有经验的攻击者而言，除了查看文件扩展名之外，还有很多其他方法可以知道您的网站在哪个平台上运行）。

【参考方案2】：

好的，所以您的问题是有道理的，但是使用您的编号和描述以您描述的方式构建 PHP 站点的最佳和最实用的方法是通过选项 1 添加选项 3 来获得通常所谓的 SEO 友好（又名：人类可读、美观、简单等）URL。

从实际的角度来看，构建一个系统以使所有调用都通过一个通用的index.php 文件对你来说是一个更繁重的工作。但猜猜怎么了？您是一名程序员，正在创建一个应该具有尽可能多的长期稳定性和安全性的工具。因此，尽可能多地针对选项 1 进行编码符合您的最大利益（也是您网站的最大利益）。

从安全的角度来看，很容易解释为什么选项 1 总是胜出。通过index.php 解析内容请求，您可以轻松地针对您在某个区域可能遇到的任何安全问题进行编程，而不是将自己分散在大量文件和功能中。因此，假设您发现了一个安全漏洞并知道如何修复它。通过让这一切都通过index.php——以及它所依赖的文件——你可以为你的网站核心代码添加一个补丁，这样无论你有 1、10、100 甚至 1000 页或更多页面，漏洞都会得到修补。

另外，在 2013 年，您不应该在 URL 调用中使用文件名。创建“好” URL 的选项 3 解决了这个问题。它从世界上掩盖了您的实际文件系统 URL。它隐藏了您确实在使用 PHP 的事实。请注意，任何安全计划的一部分都应确保您的网站不会通过标头向全世界宣布您正在使用 PHP，但该概念超出了此问题的范围。

此外，使用漂亮的 URL 来掩盖代码的好处是：假设您对 PHP 感到厌烦，并希望转向 Python 或 Ruby 进行编码。好吧，现在由于底层编程语言被掩盖了，你现在可以用另一种语言重新编程你的网站，只要你确保你的脚本对错误的网站 URL 做出预期的反应，你就可以开始了。