您好我最近阅读 JSP 并遇到了其技术，主要是会话。在会话中，我阅读了 URL重写之一已经完成的方法，以便维护与客户端的会话。但是，由于URL重写会使用会话ID更改URL，因此客户端可以看到它。 这不是安全问题吗？让我们举个例子说，如果任何一个注意到这个会话ID除了特定用户，并且可以很好地利用它？或者有防止这些的技术？
如果我错了，请纠正我。
答案 0 :(得分：7)
当然这是一个安全问题。如果您快速记下jsessionid值，可以是其他人错误地使用公共copypasted URL，也可以是公开发布的一些HTTP调试工具（Firebug）的屏幕截图，其中显示了请求/响应标头，以及网站有问题通过登录维护用户，然后您只需将jsessionid cookie附加到URL或请求标头即可在同一用户下登录。很快，因为这些会话在30分钟不活动后默认过期。这称为session fixation攻击。
您可以完全禁用网址重写，以便jsessionid永远不会出现在网址中。但是你仍然对会话固定攻击很敏感，一些黑客可能在公共网络中安装了HTTP流量嗅探器，或者某些木马/病毒，甚至使用XSS来了解这些cookie。需要明确的是，这个安全问题不是特定于JSP，PHP，ASP或任何通过基于cookie的会话维护登录的网站，对此非常敏感。
为了确保登录安全，请让登录和登录流量通过HTTPS而不是HTTP进行，并使cookie成为HTTPS（安全）。
答案 1 :(得分：1)
在大多数（如果不是全部）安全圈中，不鼓励对会话cookie进行URL重写。 OWASP ASVS明确不鼓励使用它，因为它会导致通过不安全的介质暴露会话标识符。
当启用会话cookie的URL重写时，URL可以（使用会话标识符）传输到其他站点，从而导致通过HTTP Referrer头部公开会话标识符。实际上，浏览器对位于另一个域的资源的简单请求将导致可能的劫持（通过中间人攻击）或会话的固定;这与站点中的跨站点脚本漏洞一样好。
另外，当网站执行URL重写时，不能再使用其他保护机制，例如HttpOnly和Secure-Cookie标志，这些标志引入各种浏览器以不同方式保护会话cookie。
答案 2 :(得分：0)
我相信你指的是无Cookie会话。虽然我在Java圈子中看到它被称为“url rewriting”。
还有一些额外的会话劫持问题（它们适用于所有支持无cookie会话的Web开发框架 - 而不仅仅是JSP）。但即使使用cookie，也可以进行会话劫持。
这是关于MSDN关于无cookie会话和风险/收益的非常好的深入文章。同样，这些都是平台无关的。