像http://www.site.com/user/1这样的URL结构，是否存在安全风险？
比如这里http://stackoverflow.com/users/edit/1
这不是安全漏洞吗？我怎样才能避免这种情况？
【问题讨论】：
$_GET 超全局无关。后一个只评估 GET 参数，即/somepage.php?var=value 会给你$_GET['var'] == 'value'。与任何用户输入一样，您需要验证它并确保它被正确使用；那么就没有真正的安全问题了。
请解释您认为这是安全漏洞的原因。
如果您的意思是用户只需更改号码即可访问其他用户的编辑页面，是的，他们可以。这也可以通过 POST 来完成，可以手动更改正文（例如，通过创建发布到页面的本地 html 文件，或使用浏览器插件更改正文）。
但是，您应该检查每个页面，以查看当前登录的用户是否有权执行在该页面上执行的操作。
可以通过以下方式完成：
$userIdToEdit = $_GET['ID'];
if ($userIdToEdit != $_SESSION['loggedOnUserId'])
{
redirect("/NotAllowed"); // Deny access to the page
}
// if we end up here, the user may perform this action, like store POSTed data in db
但是，尽管您拥有所需的所有灵活性，但您可能会在整个页面中重复检查。一个解决方案是使用RBAC，它会变成这样：
checkRole(EditOwnProfile); // only logged on users may do this, redirects to /NotAllowed if necessary
// and check for another role
$userIdToEdit = $_GET['ID'];
if ($userIdToEdit != $_SESSION['loggedOnUserId'])
{
checkRole(EditOtherProfile); // admins may do this for example
}
【讨论】：
这取决于。您应该拒绝不需要访问该页面的人访问。
【讨论】：
如果您不检查编辑（或任何操作）目标页面的权限，这只会带来安全风险。例如，在您的示例 URL 中，应该只允许用户 ID 1（或者可能是一些站点范围的管理员）编辑页面。其他人将被重定向，或以其他方式拒绝访问。
有些人认为增量整数 ID 存在轻微的安全风险，因为它们很容易被猜到并在循环中编写脚本以探测攻击者可以采取未经授权的操作的页面。但是，使用递增整数 id 的做法非常普遍，并且再次依赖于在每次页面加载时进行适当的访问检查。
最后，或许也是最重要的一点，在处理该 URL 的脚本中，您需要做的第一件事是验证数字 id 是否为数字并标识有效资源。
【讨论】：
只要您的脚本是安全的，使用 htaccess 重写规则就不会导致安全问题。您基本上需要使用会话来跟踪允许谁访问该页面，并且使用好的代码应该没问题。 user.php?id=1 和 /user/1 是相同的，它们需要相同的安全性
【讨论】：
一般来说，知道资源的 URI 不是安全问题。
如果 HTTP 请求可能导致在没有进行身份验证/授权步骤的情况下编辑数据，则会导致安全问题。
提供一个邀请用户编辑数据的表单而无需此步骤，然后仅在提交表单后才应用安全检查，这样可用性会很差。
您给出的特定示例可能属于较差的可用性类别。我不会尝试提交编辑请求以查看它是否属于安全问题类别，但我会假设它不属于（考虑到 SO 已经存在多长时间以及它有多受欢迎）。
【讨论】：
如果您正确检查用户权限，编辑操作http://stackoverflow.com/users/edit/1没有安全风险。
另一方面，像http://stackoverflow.com/users/delete/1这样的URL 是安全风险，因为攻击者可以欺骗授权用户打开此URL，这将导致删除具有ID的用户1. 这可以通过使用类似 bit.ly 的 URL-Shortening-Service 来实现。
您可以通过将 $_POST 用于删除和向请求添加令牌以验证请求来源等操作来避免这种情况。
【讨论】：
您必须注意 HTTP 协议本身的工作方式（潜在攻击者的可能性如何）。
简而言之 - 如果您决定将该 url 更改为 /change-user 之类的内容并在 post params 中隐藏诸如 id 之类的参数，那么攻击者的选项没有区别。
您需要对该 HTTP 请求进行安全身份验证（可能通过标准登录创建的会话，您有更多选择如何做到这一点）。
【讨论】：