代码之家 › 专栏 › 技术社区 › Mez

返回“正确”错误代码,还是保护隐私?

authentication security

Mez · 技术社区 · 16 年前

好吧,最好在这里举个例子说明我的意思。

想象一下一个基于Web的论坛系统,其中用户身份验证是通过系统意识到的某种外部方法完成的。

例如,现在,用户输入了他们无权访问的线程的URL。为此,我应该返回403(禁止),让用户知道他们应该尝试另一种身份验证方法,或者404,而不是让他们知道有什么东西可以访问。

假设我返回403,当他们访问一个还不存在的主题的URL时,我是否还应该返回403?

编辑:上面的例子更像是一个IRL的例子。

另一个例子,假设我暴露了

/adminnotes/user

如果有关于用户的管理员注释。现在,返回403会让用户知道他们说了些什么。404什么也不会说。

但是,如果我要返回403—我可以将它返回给adminnotes/*—这可以解决这个问题。

编辑2:另一个例子。这里的软删除问题返回404。但是,通过正确的身份验证和访问,您仍然可以看到它们(我想是这样的)。

9 回复 | 直到 15 年前

John Millikin 16 年前

最重要的是, 符合HTTP规范。 返回403代替404不是一件好事。把404换成403也许没问题(或者不是一个大错误),但我只是 让软件说出真相 . 如果用户只知道一个主题的ID,那么它就不多了。他可以尝试 定时攻击 以确定此主题是否存在。

David Waters 16 年前

我会转到一个307重定向到nosuchpageornopermissions.html,在那里你很好地告诉用户他们输入了错误的URL或者没有权限。

这不会破坏合规性,也不会发出错误的消息。

如果你非常偏执,你可以在返回重定向之前随机等待,这样时间分析就更难了。

至于这里所有的人,问为什么要保护目录,试试这些例子。

1。用户名

假设我们是一个ISP,我们会给每个用户一个网页,网址为www.isp.example/home/username,电子邮件地址为username@isp.example。如果攻击者进行字典攻击,向www.isp.example/home/[random]发送请求,并可以判断这是否是有效的用户名,那么我们现在可以生成一个有效电子邮件地址列表,将其出售给坏人。

2。什么文件夹

鲍勃正在竞选公职,他在海报上开了一个账户,用他的网站存储个人信息。但他通过将其设为私人文件夹来保护它,他的公共页面位于: www.example.com/bob,他的秘密文件夹是www.example.com/bob/icecream。他已将此标记为私有,因此任何请求的人都可以获得403。然而,www.example.com/bob/cake返回404,因为bobs的秘密是冰淇淋而不是蛋糕。

爱丽丝,记者在Bobs网站上做了一个字典攻击

www.example.com/bob/cake-404
www.example.com/bob/donuts-404
www.example.com/bob/lollies-404
www.example.com/bob/icecream-403

现在艾丽丝知道了鲍布的秘密,并且可以把他当成一个吃冰淇淋的人。

KovBal 16 年前

我认为您应该发送307(临时重定向)请求,请求“/adminnotes/user”将非特权客户端重定向到“/adminnotes/”。因此客户端请求“/adminnotes/”,因此您可以发送回403,因为它是禁止的。

这样,您的应用程序就可以保持HTTP兼容,而非特权用户对受保护数据不会了解太多。

John Millikin 16 年前

什么“隐私”是通过向用户隐藏特定线程的存在来保护的?

我想说,在他们无法访问的线程上返回403或404是可以的。在不存在的线程上返回403是坏的想法。

1800 INFORMATION 16 年前

世界上没有一个网站按照你的建议行事,因此通过这个例子,我们看到,最好遵循标准,当资源不存在时返回404,当资源被禁止时返回403。

Community THelper 7 年前

我不明白你为什么担心URL上的隐私问题。在stackoverflow的情况下,可以在questionID号之后放置任何文本。例如, Return "correct" error code, or protect privacy? 还是回到这个问题上。

16 年前

别忘了404在技术上也会泄露信息。例如,您可以告诉谁没有管理员笔记。根据具体情况,这可能和指示资源确实存在一样糟糕。

在我看来,错误不应该说谎。如果给出404,那么资源不存在的情况应该总是如此。

如果您处理的是敏感信息,那么您总是可以说用户没有该资源的权限。这不一定要求资源存在。客户机甚至可能没有权限知道资源是否存在。因此,您需要为/adminnotes/的任何组合提供一个拒绝权限的错误。

也就是说,官方规范似乎不同意,下面是官方的RFC对错误的看法。 http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html :

10.4.4 403禁止服务器理解请求,但拒绝完成请求。授权没有帮助,请求不应重复。如果请求方法不是head,并且服务器希望公开未满足请求的原因,那么它应该描述实体中拒绝的原因。如果服务器不希望将此信息提供给客户机,则可以使用状态代码404(未找到)。

10.4.5 404未找到服务器未找到任何与请求URI匹配的内容。没有说明这种情况是暂时的还是永久的。如果服务器通过一些内部可配置的机制知道旧资源永久不可用且没有转发地址,则应使用410(消失)状态代码。当服务器不希望确切地揭示请求被拒绝的原因,或者没有其他响应适用时,通常使用此状态代码。

我不是专家,但我认为在资源可能存在的时候给出一个“找不到”是愚蠢的。我更喜欢“禁止”,没有保证资源存在的保证,这意味着您需要以某种方式进行身份验证才能找到答案。

computinglife 16 年前

假设您在检测到用户没有正确的访问权限时返回了“找不到页面”错误。一个恶意的黑客很快就会发现你会把这个放在拒绝访问的地方。

但是,那些错误输入网址或使用错误登录等的真正用户会感到困惑,他们会不厌其烦地解释和发布注释,向客户、TAC等解释您的立场,以换取什么?

意图是好的,但我担心你提出的这项政策可能无法达到你想要的效果。

Gravstar 16 年前

我的建议是:

如果不存在线程,则返回404
如果用户不能访问这个线程,那么返回403