【问题标题】:check user security for modifying objects检查用户修改对象的安全性
【发布时间】:2017-02-25 04:24:58
【问题描述】:

我正在考虑我的 python web 应用程序的安全实施。 例如,我有用户和个人资料。 每个用户都可以通过在 /profile/user_id 发送 POST 来编辑他的个人资料

在每个请求上,我都可以获取会话 user_id 并将其与 profile.user_id 进行比较,如果它们不同 - 引发 SecurityException()。

但我也可以使用另一种更常见的方式: 为每个配置文件生成

secret = hash(profile_data+secret_key)

并为身份验证渲染。用户链接如下:

/profile/4?key=secret

所以想法是根据可编辑的对象数据生成密钥并在服务器端检查此密钥。如果用户不知道密钥,则无法获取编辑其他配置文件的链接,因此无法修改它们。

这种保护方法怎么叫? 与基于会话的 user_id 检查相比有什么问题吗?

【问题讨论】:

  • 取决于是否允许用户修改其他用户的配置文件,秘密方法可能起作用,请记住,您应该了解一些安全攻击以及如何防范它们,例如定时攻击.另一个问题是用户体验,如果用户编辑他的个人资料,从而修改了他的密钥,那么之前的所有 URL 都会失效,这很麻烦。另外,我不知道这是否只是因为它是一个示例,但要注意内置的 hash 函数,它在密码学上并不安全。
  • 链接无效的问题可以通过只在像 ID 这样的持久数据上生成哈希来解决......所以哈希(id+secret),是不是比在可变数据上生成更不安全?
  • 我只是看不到专业人士,您会得到更丑陋的 URL,如果机密泄露,您必须更新所有用户的 URL。
  • ...如果用户点击外部链接,秘密将与推荐人一起泄露。

标签: python security web-applications


【解决方案1】:

/profile/4?key=secret

实际问题:

  • 在 URL 中放置秘密通常是个坏主意。 URL 很容易通过日志、历史记录、引用者等泄漏。它还会破坏导航。最好将秘密放在 cookie 或 POST 数据中。
  • 您通常会在签名数据中包含时间限制,因此令牌不会永远有效
  • 您通常会在用户信息和签名数据中包含某种标志/计数器/状态,以便用户可以更新某些内容(例如更改密码)以使之前发布的令牌无效
  • 您还必须确保签名数据的生命周期不能长于令牌的生命周期,例如,您不能删除用户 4 并创建令牌仍然有效的新用户 4
  • 您将使用的哈希将是使用服务器端密钥作为密钥的 HMAC

出于性能或操作原因,签名身份验证令牌通常用作数据库支持的会话存储的替代方案。使用签名令牌安全地进行会话当然是可能的,但是如果您已经将存储的会话用于其他目的,那么您将没有太多收获。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2010-10-12
    • 2014-04-29
    • 1970-01-01
    • 2014-05-19
    • 2018-11-13
    • 1970-01-01
    • 2015-05-23
    • 1970-01-01
    相关资源
    最近更新 更多