在 Web 应用程序的上下文中，用户连接到此应用程序并设置会话 id cookie 来验证用户的下一个请求。由于 cookie 在提交登录表单之前实际存在，因此登录成功时不会生成新值，而是按原样获取 cookie 中存在的值。例如，普通用户可以选择将该值设置为“0000000000000000000000000000”。
现在我不知道，但也许攻击者有办法在他/她登录之前设置受害者的 cookie 值，一旦登录成功，该值就会变为有效并被服务器接受，然后可以使用由攻击者进入受害者的账户。
那么，会话 id cookie 的值不一定由服务器选择，是否存在安全风险？
编辑： 关于第一个答案的一些精度。我删除了“攻击预防”标签，因为我只想评估所描述场景的风险。我知道 HTTPS 可以解决许多安全问题，但这并不是问题所在。
是的，这是有风险的，因为这是一个经典的会话固定问题（OWASP Page）。Web 应用程序会话管理的标准良好实践总是在用户提交登录时重新发出随机会话令牌。其他任何事情（在登录时不重新发布或允许用户设置会话令牌值）都不是一个好主意。
这是一个多大的问题取决于应用程序的工作方式和用户环境。这就是风险的一些例子
许多网站都有未经身份验证的未加密区域。因此，如果在这些上设置了令牌，然后没有重新发出，则令牌可以在用户登录之前被数据包嗅探攻击（例如通过无线网络）劫持，然后可以劫持经过身份验证的会话
如果应用程序是从共享 PC 环境访问的，那么可以在打开的浏览器中设置令牌值的攻击者，如果他们使用系统而不关闭并重新打开浏览器，就能够劫持用户会话（假设关闭浏览器时删除令牌）。
这是一个安全问题，但不是您可以做任何事情的，因为客户端始终可以设置他们想要的任何会话 ID。如果没有具有该 ID 的会话服务器端，则用户可能会看到会话过期消息并被迫进行身份验证。
如果攻击者能够获得合法用户的会话 ID，则可能会通过在攻击者浏览器上设置相同的会话 ID 并导航到相关站点来进行会话劫持。
HTTPS 通过阻止一个传统的人在会话 ID 的盗窃中采取某种方式来防止这种攻击。
攻击者还有其他方法可以获取受害者的会话 ID，例如易受攻击的 Web 应用程序中的跨站点脚本攻击。在这样的应用程序中，欺骗受害者打开一个可能运行一些攻击者提供的 javascript 的页面是微不足道的，这些 javascript 向他们发送会话 ID 并允许他们使用该服务假设您的身份。
我不太担心黑客能够在登录之前设置会话 ID，因为当受害者使用 Web 应用程序进行身份验证时，响应将设置服务器提供的新会话 ID。
如今，大多数 Web 应用程序还包含辅助措施，以防止通过其他包含校验和的 cookie 劫持会话，其中包含机器特定信息的哈希值。Facebook 等网站允许您指定安全设备列表以防止此类攻击。