Asp.net mvc QueryString中的SessionID或GET请求的Cookie应该优先吗？

如果我收到对url

host.com/site directory/page slug.html？session={someValidNonExpiredSessionGuid}

的请求，并检测到值为：

{someOtherValidNonExpiredSessionGuid}

的会话cookie，则

哪个会话是与请求关联的正确会话？ 以下是一些背景：

我用于跨HTTP请求维护状态的模式是在querystring、表单集合和/或cookie中存储唯一的ID。然后，在每个请求中，我从数据库表中找到唯一Id并提取日期。如果id无效，或会话已过期，将创建一个新会话（使用新id、新cookie等）

默认行为是所有表单都有一个字段：

 <input type="hidden" name="session" value="{someGuid}" />

指向站点上其他页面的所有链接都将附加querystring参数

 <a href="site-directory/page-slug.html?session={someGuid}">a sample link</a>

而且，如果用户的浏览设备支持cookie，则cookie将被设置为具有会话的值

如果我已验证用户的浏览设备支持Cookie，则我的表单和查询字符串将不再需要会话id字段/参数

但是，在决定querystring的会话参数是否应优先于cookie值或反之亦然时，我遇到了一个概念上的问题。似乎在这两种情况下我都有可能得到坏数据。如果用户使用URL中包含的会话参数将页面添加到书签中，我可能会获得带有错误querystring参数的数据。如果用户关闭浏览器而不终止会话，并且会话过期窗口尚未关闭，我也可能从cookie中获取坏数据。这两个选项似乎都容易受到恶意用户拦截请求并发送具有相同会话信息的请求的攻击

所以，再一次，我的问题是 如果我收到对url

host.com/site directory/page slug.html？session={someValidNonExpiredSessionGuid}

的请求，并且我检测到一个值为：

{someOtherValidNonExpiredSessionGuid}

的会话cookie，那么哪个会话是与该请求关联的正确会话？

我倾向于cookie会话，因为最常见的场景似乎是包含会话的书签。我已经决定表单post数据应该具有最高的优先级，因为页面将始终使用正确的ID呈现表单，并且使用错误的、未过期的ID的唯一可能情况是非常快速地实施XSS攻击，通过包含请求范围的防伪令牌字段来规避该攻击

除了主要问题之外，我非常感谢您对我在本说明中表达的任何安全相关或逻辑疏忽的见解。我为这篇长篇大论道歉，但我觉得有必要解释一下情况。非常感谢您的投入

---

此外，这与问题不一定相关，但我在大多数情况下使用ASP.NET MVC，并使用

响应手动设置cookie。从安全角度来看，cookie

会话不应存储在查询字符串中

例如： 如果会话存储在查询中，并且您链接到同一页面上的远程主机，则可以通过referer头将用户有效会话发送到远程主机

---

会话应始终存储在cookie中。

您应尝试将其存储在cookie中（查看浏览器帽以查看浏览器是否支持cookie），然后返回查询字符串。

我也倾向于使用cookie会话ID，以防出现歧义。这主要是因为我相信cookie实现比我自己自制的会话跟踪实现更成熟、更经过测试、更能防止白痴。例如，在某些情况下，ASP.NET自动知道清除会话cookie、续订会话cookie等

此外，我会设计它，使cookies不会持久化，以最小化边缘情况。如果用户关闭浏览器，则会话将关闭

<> P>另一个简化是考虑cookies或基于URL的跟踪，而不是两者。如果浏览器支持cookie，那么实际上没有理由通过URL跟踪会话

想法

好奇。。。您排除使用库存ASP.NET无cookieless会话实现的原因是什么

如果我收到对url的请求 host.com/site directory/page slug.html？会话={someValidNonExpiredSessionGuid} 我检测到一个会话cookie 价值： {someotherValidNoneExpiredSessionGUID}， 那么哪个会话是正确的 要与请求关联的会话

为了回答您的具体问题，我建议将会话管理放在cookie中，而不是查询字符串中。如前所述，Cookie可以设置为过期，而querystring不能。这允许瘦客户机通过删除自己过期的cookie来协助自己的会话维护。此外，由于cookie被丢弃到特定的浏览器，因此可以减少另一个浏览器欺骗原始浏览器会话的机会

使用querystring传递会话信息的唯一方法是作为备份方法在新的浏览器实例上重新建立浏览器会话。下面是一个场景：您在机器a上有一个使用浏览器的活动会话，它遇到了一些灾难性错误。您需要一种在同一台计算机或另一台计算机上的另一个浏览器实例上重新建立同一会话的方法。如果您的代码隐藏可以识别会话cookie不存在，但querystring中存在有效的会话id，则可以启动质询响应以验证该会话id的完整性，然后在新机器上丢弃新的会话cookie。我的嗡嗡声有点极端