具有$ _GET请求的安全性

Question

使用类似http://www.site.com/user/1的URL结构，是否存在安全风险？

例如像这里http://stackoverflow.com/users/edit/1

这不是一个安全漏洞。我怎样才能避免这种情况？

Answer 1

请解释您为什么认为这是安全漏洞。

如果您的意思是用户可以简单地更改号码以访问其他用户的编辑页面，那么他们可以。这也可以通过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 
} 

Answer 2

这取决于。您应该拒绝不需要访问该页面的人员访问。

Answer 3

如果您没有检查编辑（或任何操作）目标页面的权限，那么这只是一个安全风险。例如，在您的示例网址中，只允许使用用户ID 1（或者某些站点管理员）编辑页面。其他人将被重定向，否则将被拒绝访问。

一些人认为增量整数ID是一个轻微的安全风险，因为它们可以很容易地在循环中猜测并脚本化，以便探测攻击者可以采取未授权操作的页面。但是，使用递增整数ID的做法非常普遍，并且依赖于对每个页面负载进行适当的访问检查。

最后，也许最重要的是，在处理该URL的脚本中需要做的第一件事是验证数字标识是数字标识还是标识有效资源。

Answer 4

只要脚本安全，使用htaccess重写规则不会导致安全问题。您基本上需要使用会话来跟踪哪些人被允许访问该页面，并且使用良好的代码您应该没问题。和user.php?id=1和/user/1都是相同的，他们需要相同的安全性

Answer 5

通常，知道资源的URI不是一个安全问题。

如果HTTP请求可能导致数据在未经认证/授权的情况下进行编辑，则会导致安全问题。

提供一个表单，邀请用户在没有这样的步骤的情况下编辑数据，然后仅在提交表单后才应用安全检查，可用性很差。

您给出的具体示例可能属于糟糕的可用性类别。我不会试图提交一个编辑请求来查看它是否属于安全问题类别，但我会认为它没有（考虑到SO已经存在了多长时间以及它的受欢迎程度）。

Answer 6

如果您正确检查用户权限，编辑操作http://stackoverflow.com/users/edit/1没有安全风险。

在另一方面，像http://stackoverflow.com/users/delete/1的URL是安全风险，因为攻击者可以愚弄授权用户打开这个网址，这将导致在删除用户的id为1。这是可以实现通过使用像bit.ly一样的URL-Shortening-Service。

您可以通过将$ _POST用于删除操作并向请求中添加令牌以验证请求源来避免此情况。

Answer 7

你必须小心HTTP协议是如何工作的（潜在的攻击者有多大的可能性）。 简而言之，如果您决定将该网址更改为/change-user之类的内容，并在后参数中隐藏参数（如id），则攻击者的选项没有区别。

您需要确保该HTTP请求的身份验证（可能通过标准登录创建的会话，您有更多选项如何执行该操作）。