【问题标题】:Is it better to store user data in a database rather than in cookies? [closed]将用户数据存储在数据库中比存储在 cookie 中更好吗? [关闭]
【发布时间】:2011-03-17 03:20:19
【问题描述】:

我们为什么不将网站访问者(订阅者)的 cookie 信息保存在数据库中,而不是在用户的机器上设置一个文件。是的,我知道我可能听起来很傻,原因如下:

  1. 很难为每个用户维护非常小的“块”数据的数据库信息。

  2. 当数据库服务器宕机时,可能难以检索数据。

  3. 对于每条小信息,都将向 Web 服务器发出持续请求。

我的观点是,如果我们要将用户的数据存储在数据库中而不是客户端计算机上的文件中,我们可以通过不允许其他组织或其他站点(甚至黑客)来为客户端提供安全性从 cookie 中访问用户的信息。

此外,我们可以跟踪用户的活动或行为。 (我的意思是,我们实际上不知道用户在做什么(客户端活动),比如数据篡改。)

如果您觉得连续向 Web 服务器发送请求可能很困难,那么这要归功于 Ajax。这为我的立场提供了一些支持:使用 Ajax 向 Web 服务器发送请求变得如此简单。

那么,将用户的敏感信息存储在数据库中而不是在用户的机器上设置一个小文件是个好主意吗?

具体来说,我不是在谈论会话!

【问题讨论】:

    标签: database security cookies tampering


    【解决方案1】:

    敏感信息不应该在 cookie 中,我同意你的看法。它应该存储在服务器端的某个地方,可以是服务器本身的平面文件,也可以是数据库。

    您在客户端计算机上需要的是一个小 cookie,其中包含对该敏感数据的一些晦涩难猜的引用。

    恭喜!您刚刚重塑了会话!

    (如果您愿意,可以将 Web 服务器设置为将会话数据存储在数据库中,而不是存储在服务器上的平面文件中。)

    【讨论】:

      【解决方案2】:

      通常我们使用 Cookie,因为我们不一定会在其中设置任何敏感数据。如果您的应用程序确实包含您不希望任何人摆弄的敏感数据,那么请务必使用您可以使用的每个服务器端和数据库工具来解决这个问题,但并非所有应用程序和实现都需要在这些方面的安全级别。设置 cookie 是为了方便,仅此而已。

      【讨论】:

        【解决方案3】:

        您的方法绝对有效,但存在一个基本问题(这可能是最初创建 cookie 的原因):识别。

        如何在不询问用户名/密码的情况下识别用户 A 和用户 B? Cookie 提供了一种简单的方法来进行这种区分。一旦用户被识别,您的积分就完全有效。

        一般来说,敏感信息并不意味着存储在 cookie 中。此类信息最好存储在服务器端(如您所述)。

        【讨论】:

          【解决方案4】:

          这已经完成,否则我们会将用户名、地址和信用卡信息存储在 cookie 中而不是数据库中。您必须评估什么是有意义的保留在数据库中,什么是有意义的存储为 cookie。服务器性能、带宽、可扩展性——所有这些都必须牢记。 请记住,我们在服务器端存储的越多,我们就越需要在客户端交付。

          您还提到了会话 - 会话 是 cookie(有点)。

          【讨论】:

            【解决方案5】:

            我在寻找与 cookie 与数据库参数相关的类似建议时偶然发现了这篇文章。

            比如说,我有一些整数列表形式的用户数据,即一些带有书签的产品,每个用户最多 80 个。

            在数据库中,这可以转换为 4 个表(每种数据类型 1 个),因此每个用户 20 行。

            如果您每年有 100 万唯一身份访问者,并且出于争论的原因,70% 是访客用户而不是成员,那么这可能会在一个表中添加 1400 万行,否则可能只有 600 万行。当然,您可以为来宾用户制定剔除政策,但这会变得难以准确管理 - 也就是说,用户在 9 个月后没有返回以发现他/她的数据已被擦除。

            硬币的另一面是访客数据存储在 cookie 中,因此存储多长时间并不重要。我很欣赏管理两种存储方法需要更多的工作,但这是我能想到的唯一缺点。

            任何人对此有任何看法,我将不胜感激。

            【讨论】:

              【解决方案6】:

              确实,传统智慧是避免将 cookie 用于敏感数据,因为它们存储在客户端上,黑客可以修改它们并可能造成损害。然而,cookie 值得重新审视有一个令人信服的理由:可扩展性。为任意数量的云服务器提供高性能的会话数据池是很困难的:

              http://aws.typepad.com/aws/2012/04/scalable-session-handling-in-php-using-amazon-dynamodb.html

              这是我找到的一个链接,其中详细介绍了如何构建安全的 cookie 系统:

              http://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.pdf

              所以可能是旧的又是新的了。

              【讨论】:

                猜你喜欢
                • 2014-08-12
                • 2010-11-24
                • 2011-02-10
                • 2013-07-15
                • 1970-01-01
                • 2013-02-20
                • 2022-11-04
                • 2010-11-07
                • 1970-01-01
                相关资源
                最近更新 更多