【问题标题】:Disadvantages of sharing Django sessions on multiple subdomains在多个子域上共享 Django 会话的缺点
【发布时间】:2012-02-04 14:01:42
【问题描述】:

我使用站点框架构建了一个 Django 站点,并且在不同的子域上有四个站点。让我们称他们为 one.mydomain.com; two.mydomain.com ...等

其中三个站点是产品站点,一个是商店。我希望能够跨站点共享会话,以便用户在从任何产品站点移动到商店时不必再次登录。我意识到我可以使用cas 来实现单点登录,但我认为这并不符合我的所有目的。

我已经阅读了 this postthis post 关于跨子域共享会话的内容,并且一致认为这是一个坏主意。

在我的情况下,我希望用户能够将商品添加到一个子域上的购物车,然后继续到购物车结帐。如果不共享会话,我看不到这样做的方法。用户还应该能够从另一个产品站点添加到他们的购物车,并且在结帐时会看到来自 one.mydomain.com 的产品、来自 two.mydomain.com 的产品等。

所以我的问题是,除了潜在的冲突之外,为什么共享会话不是一个好主意?假设我确保发生(并且应该发生)的唯一冲突是用户登录信息。

我的设置为所有网站和 SESSION_COOKIE_DOMAIN='.mydomain.com' 共享了 SECRET_KEY。此设置是否存在严重的安全漏洞?

谢谢./w

【问题讨论】:

    标签: python django session session-cookies django-sessions


    【解决方案1】:

    在我看来,当您不控制特定域的所有子域时,这是一个安全漏洞。例如,您有 one.mydomain.com 和 two.mydomain.com,但浏览器也会将您的 cookie 提供给名为 bad.mydomain.com 的网站,因为您的设置为 SESSION_COOKIE_DOMAIN='.mydomain.com'。

    如果您将开发环境保留为子域之一(例如 dev.mydomain.com),则会出现另一个潜在漏洞。如果是这样,你就不会被孤立了。

    就我对该主题的研究而言,最坏的情况似乎是将您的 cookie 泄露给恶意子域,因此可能有人会使用此 cookie 劫持真实会话。

    目前我正在进一步研究如何以更好的方式隔离不同的子域(由同一 Django 实例控制),但似乎除了重写 SessionMiddleware 之外没有真正的方法。

    【讨论】:

      【解决方案2】:

      从我读过的许多内容来看,这被认为是一个坏主意,如果您尝试在站点之间共享会话,似乎您可能会创建一些非常难以追踪的错误。据我所知,通常最好使事物尽可能无状态。

      【讨论】:

        猜你喜欢
        • 2011-04-14
        • 1970-01-01
        • 2021-12-26
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2015-01-05
        • 2013-12-04
        • 2011-08-26
        相关资源
        最近更新 更多