网址重写 - 这会导致安全问题吗？
您好，我最近阅读了 JSP 并了解了它的技术，主要是会话。在会话下，我阅读了 URL 重写 为维持与客户端的会话而执行的方法之一。但是由于 URL 重写改变了带有会话 ID 的 URL，并且它对客户端是可见的。 这不是安全问题吗？比方说，除了特定用户之外，是否有人注意到此会话 ID，并且可能会滥用它？或者有什么技术可以防止这些情况发生？
如果错了请纠正我。
Hi I have recently read JSP and came across its technologies, mainly session. Under session, I read URL rewriting one of the method that was been done in order to maintain the session with the client. But since the URL rewriting changes the URL with the session ID and it can be visible to the client.
Is that not a security issue? Lets say for example, if any one note this session ID apart from the particular user, and can make a bad use of it? Or else there are techniques for preventing these?
Correct me if am wrong.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
当然，这是一个安全问题。如果您快速记下
jsessionid值，该值可能来自其他人错误地在公共复制粘贴的 URL 中，也可能来自某些显示请求/响应标头的 HTTP 调试工具 (Firebug) 公开发布的屏幕截图，并且相关网站通过登录来维护用户，那么您只需将jsessionidcookie 附加到 URL 或请求标头，就可以使用同一用户登录。很快，因为默认情况下，这些会话在 30 分钟不活动后就会过期。这称为会话固定攻击。您可以完全禁用 URL 重写，以便
jsessionid永远不会出现在 URL 中。但您仍然对会话固定攻击很敏感，一些黑客可能在公共网络中或通过某些木马/病毒安装了 HTTP 流量嗅探器，甚至使用 XSS 来了解这些 cookie。需要明确的是，这个安全问题并不是 JSP 特有的，PHP、ASP 或任何通过基于 cookie 的会话维护登录的网站都对此非常敏感。为了真正保证登录安全，请让登录和登录流量通过 HTTPS 而不是 HTTP，并使 cookie 仅使用 HTTPS（安全）。
Certainly this is a security concern. If you quickly take note of the
jsessionidvalue, either from a by someone else mistakenly in public copypasted URL or a in public posted screenshot of some HTTP debugging tool (Firebug) which shows the request/response headers, and the website in question maintains users by a login, then you'll be able to login under the same user by just appending thejsessionidcookie to the URL or the request headers. Quickly, because those sessions expire by default after 30 minutes of inactivity. This is called a session fixation attack.You can disable URL rewriting altogether so that the
jsessionidnever appears in the URL. But you're still sensitive to session fixation attacks, some hacker might have installed a HTTP traffic sniffer in a public network or by some trojan/virus, or even used XSS to learn about those cookies. To be clear, this security issue is not specific to JSP, a PHP, ASP or whatever website which maintains the login by a cookiebased session, is as good sensitive to this.To be really safe with regard to logins, let the login and logged-in traffic go over HTTPS instead of HTTP and make the cookie HTTPS (secure) only.
大多数（如果不是全部）安全圈都不鼓励对会话 cookie 进行 URL 重写。 OWASP ASVS 明确不鼓励使用它，因为它会导致通过不安全的介质暴露会话标识符。
当启用会话 cookie 的 URL 重写时，URL 可以（带有会话标识符）传输到其他站点，从而导致通过 HTTP Referrer 标头泄露会话标识符。事实上，浏览器对位于另一个域的资源的简单请求将导致可能的劫持（通过中间人攻击）或会话固定；这与站点中的跨站点脚本漏洞一样好。
另一方面，当站点执行 Cookie 的 URL 重写时，无法再使用其他保护机制，例如引入各种浏览器以不同方式保护会话 Cookie 的 HttpOnly 和 Secure-Cookie 标志。
URL rewriting of session cookies is discouraged in most (if not all) security circles. OWASP ASVS explicitly discourages its use as it results in exposure of the session identifiers via an insecure medium.
When URL rewriting of session cookies is enabled, the URL could be transmitted (with the session identifier) to other sites, resulting in disclosure of the session identifier via the HTTP Referrer header. In fact, a simple request by a browser to a resource located on another domain will result in possible hijacking (via a Man-In-The-Middle attack) or fixation of the session; this is as good as a Cross Site Scripting vulnerability in the site.
On a different note, additional protection mechanisms like the HttpOnly and Secure-Cookie flags introduced into various browsers for protecting the session cookie in different ways, can no longer be used when URL rewriting of cookies is performed by a site.
我相信您指的是无 cookie 会话。虽然我在 Java 圈子里看到过它被称为“url 重写”。
还有一些额外的会话劫持问题（它们适用于所有支持 cookieless 会话的 Web 开发框架，而不仅仅是 JSP）。但即使使用 cookie，会话劫持也是可能的。
这是 MSDN 上一篇关于无 cookie 会话及其风险/好处的非常好的深入文章。同样，这些都是与平台无关的。
http://msdn.microsoft.com/en-us/library/aa479314.aspx （向底部）
I believe you're referring to cookieless sessions. Although I have seen it referred to as 'url rewriting' in Java circles.
There are some extra session hijacking concerns (and they apply across all web development frameworks that support cookieless sessions--not just JSP). But session hijacking is possible even with cookies.
Here's a pretty good in-depth article on MSDN about cookieless sessions and the risks/benefits. Again, these are all platform agnostic.
http://msdn.microsoft.com/en-us/library/aa479314.aspx (toward the bottom)
这就是我在检查 OWASP URL 重写规范时发现的，在 URL 中暴露会话信息是一个日益严重的安全风险（在 OWASP Top 10 列表中，从 2007 年的第 7 位到 2013 年的第 2 位）。
管理 URL 重写的选项包括：
在服务器级别禁用它们。
在应用程序级别禁用它们。
一个有吸引力的选择是 Servlet 过滤器。
过滤器使用替代版本包装响应对象，该版本将response.encodeURL(String) 和相关方法更改为无操作。
（WEB4J 工具包含这样的过滤器。）
This is what I came accross checking the OWASP specifications for URL rewriting and it Exposing session information in the URL is a growing security risk (from place 7 in 2007 to place 2 in 2013 on the OWASP Top 10 List).
Options for managing URL rewriting include :
disabling them at the server level.
disabling them at the application level.
An attractive option is a Servlet filter.
The filter wraps the response object with an alternate version, which changes response.encodeURL(String) and related methods into no-operations.
(The WEB4J tool includes such a filter.)