基础

首先，我假设您了解最基本的会话 ID 安全权限：

• 您正在使用具有足够熵的 ID，并且
• 您使用传输级安全性 (HTTPS)。

任何不正确的会话 ID（URL、cookie 等）方法都是易受攻击的，您的问题专门针对 URL 中的 ID，因此我不会进一步讨论。

网络浏览器泄漏

ID 泄漏最明显的风险在于RefererHTTP 标头。对此的简单解决方案是：

• 禁止传出所有链接（<a href和其他）、所有外部嵌入内容（<img>、<object>...）和其他外部依赖项（<script>...），或
• 更改所有传出链接以转到内部重定向页面（这可能是另一个安全问题，具体取决于您如何实现）。

许多 Web 应用程序的传出链接为零，并且没有来自其他用户的内容（尤其是 HTTP 资源）（这通常存在潜在的安全/隐私问题，例如电子邮件中的 Web 错误）。

这个问题通常被描述为一个严重的风险，但我不同意；如果很好理解，它很容易管理。

与用户行为相关的泄漏

自愿与其他用户共享 URL

另一个实际问题是用户可能无法将 URL 识别为页面的访问密钥，并通过电子邮件或论坛与他人共享。如果文档是公开的，但用户可能对它有一些特权访问（例如在 SE 中），则风险会更高，因此发送 URL 是与朋友共享页面最明显的做法。

当页面本质上是私有的并且包含敏感的个人信息，例如管理您的帐户的界面时，风险较低，但仍然存在。

我亲眼目睹了不止一个非公共 URL 被发布在公共论坛上的案例，其中 URL 指定了一个随机用户无法合法访问的网页：

• 显然链接到网络邮件：链接不起作用，我想是因为会话是基于 cookie 而不是基于 URL；
• 链接到 ISP 的管理 Web 应用程序中调制解调器盒的配置页面；管理应用程序位于公共 Web 服务器上并且需要身份验证（这允许 ISP 客户端从任何地方查看或更改他们的某些帐户信息）。授予他人访问此界面的权限包括：提供银行帐户信息、更改帐户密码、更改帐户电子邮件联系地址、购买可选功能、终止帐户……或只需单击“断开连接”按钮即可终止会话。

我在这里指出的问题不是 Web 应用程序设计，而是一些未受过教育的用户的行为是复制 URL 并发布它，即使该帐户管理一些严肃的东西（不仅仅是一个蹩脚的论坛帐户）。

在第二个例子中，它清楚地表明一些用户根本不去想他们在做什么：共享的 URL 要么对愿意提供帮助的人毫无用处，要么存在安全风险。这只是简单的逻辑，需要零技术知识才能理解：一个信息足以访问其他一些信息，或者不是，所以显然这个链接是无用的或者是一个严重的风险。

通常当这样的 URL 发布在公共场所时，一些好人看到 URL，复制它，如果会话仍然有效，则单击“断开连接”；然后他向用户解释了这个严重的问题。大多数人都是诚实的，但也有风险。

共享屏幕截图（显示 URL）

另一个风险是，当用户想要共享显示在一个管理网页上的某些数据（而不是他们对该页面的访问权限）时，他们制作了一个管理网页的屏幕截图，而没有意识到 URL 栏中的神秘信息是秘密。将 URL 设置得很长以使其在用户屏幕上不可见可以降低这种风险。

这种情况非常不同，因为信息的共享是自愿的，但事实是包含 URL 不是由用户实现的。

技术和用户问题

URL 中的 ID 存在一些技术问题；HTTP cookie 中的 ID 存在其他问题。在这两种情况下，开发人员都需要了解问题并修复它们。

“URL 中的秘密”方法存在用户期望问题。问题不在于用户可以看到秘密信息，而在于 URL 栏通常不包含秘密。

如果用户被说服安装（非常好的）Firebug 插件，然后激活它，转到cookie 面板并从那里复制会话 cookie，您可能会想到一种社会工程攻击。但是，即使是愿意按照您告诉他的所有事情去做的用户，也可能无法正确完成这些步骤中的每一个！

复制 URL 的内容不仅很容易（在 Web 上下载恶意软件并安装对许多用户来说也很容易）；用户用于复制和发送 URL。一些更有经验的用户可能已经向初学者解释了如何发送新闻文章的链接。初学者可能会认为他可以在任何网站和任何 web 应用程序上做到这一点（即使更有经验的用户从未告诉过他这样的事情）。

这里的问题是你可以审查你的 webapp 设计，你可以从安全专家那里获得帮助并付钱让他们对你的应用程序进行完整的分析（从设计到每一行代码），但是你不能对你的应用程序进行安全分析用户（除非此 webapp 仅适用于您的高素质员工和安全顾问）。

组合？

您可以将 cookie 中的 ID 和 URL 中的 ID 结合起来，如果：

• 两个 ID 都是不同的、独立的加密随机数
• 如果另一个 ID 泄露，每个 ID 都包含足够的熵以进行安全保护。

我建议您查看web-keys，这是一种将无法猜测的令牌插入 URL 的方法。

Web-keys 包括几种与您直接相关的技术。例如，该设计通过将令牌放置在 URL 片段中来确保令牌不会通过 Referer 标头泄漏，如下所示http://www.example.com/orderform.aspx#lit3py55t21z5v55vlm25s55：在这里阅读论文：

• 网络密钥：许可混搭，Tyler Close，W2SP 2008。

除了@curiousguy 的出色答案概述了一些需要考虑的安全风险，让我再提一个：会话固定。当会话标识符在 URL 中时，防御会话固定是一项挑战。两个候选解决方案是：在用户登录时更改会话标识符（但是，这还不足以击败登录 CSRF），并使用 TLS 会话标识符作为您的会话标识符。

风险在于包含会话 ID 的 URL 被泄露。URL 不应该包含秘密信息，因此由服务器、代理和用户代理存储，并由用户共享。

缓解措施是：

• 始终使用 TLS 来防止嗅探攻击和代理存储 URL
• 总是更喜欢 cookie，并且只有在用户代理不支持 cookie 时才设置无 cookie 会话。
• 在会话 ID 上使用较短的超时来减少 URL 有效的窗口。
• 将会话绑定到客户端的 IP 地址，如果从不同的 IP 访问会话，则该会话无效。