gpt4 book ai didi

java - 如何防止tomcat session 劫持?

转载 作者:太空狗 更新时间:2023-10-29 22:55:55 25 4
gpt4 key购买 nike

在我的 web.xml 中,我为一些资源定义了一个用户数据约束:

<security-constraint>
<web-resource-collection>
<web-resource-name>Personal Area</web-resource-name>
<url-pattern>/personal/*</url-pattern>
</web-resource-collection>
<web-resource-collection>
<web-resource-name>User Area</web-resource-name>
<url-pattern>/user/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
  1. 当我使用 http 加载页面时,我的 cookie 中有我的 JSESSIONID ID1。
  2. 当我更改为 context/user/sample.faces 时,Tomcat 将 302 重定向到 HTTPS。但是我的 JSESSIONID 仍然是 ID1。

我认为这是一个漏洞?还是我配置错误?

我看到的问题如下:在使用 cookie ID1 通过 HTTP 浏览时,有一个攻击者正在监听我的网络流量。他“窃取”了我的 cookie ID1。现在我切换到 HTTPS,我的 cookie 仍然是 ID1。我登录。然后攻击者能够接管我的 session ,因为他知道我的 cookie...

最佳答案

如果是最新版本的 Tomcat,您可能没有问题。但是,这取决于您检查与 session 关联的 SSL ID。这可以使用诸如

之类的代码
String sslId = (String) req.getAttribute("javax.servlet.request.ssl_session");

(请注意,属性键将来可能会更改为 javax.servlet.request.ssl_session_id - 作为 Servlet 的一部分3.0 规范)。

我使用以下 doGet 方法设置了一个 servlet:

protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
HttpSession session = request.getSession(true);
String sid = session.getId();
String sslId = (String) request.getAttribute(
"javax.servlet.request.ssl_session");
String uri = request.getRequestURI();
OutputStream out = response.getOutputStream();
PrintWriter pw = new PrintWriter(out);
HashMap<String, Object> secrets;
Object secret = null;
Object notSecret;
Date d = new Date();

notSecret = session.getAttribute("unprotected");
if (notSecret == null) {
notSecret = "unprotected: " + d.getTime();
session.setAttribute("unprotected", notSecret);
}
secrets = (HashMap<String, Object>) session.getAttribute("protected");
if (secrets == null) {
secrets = new HashMap<String, Object>();
session.setAttribute("protected", secrets);
}
if (sslId != null) {
if (secrets.containsKey(sslId))
secret = secrets.get(sslId);
else {
secret = "protected: " + d.getTime();
secrets.put(sslId, secret);
}
}
response.setContentType("text/plain");
pw.println(MessageFormat.format("URI: {0}", new Object[] { uri }));
pw.println(MessageFormat.format("SID: {0}", new Object[] { sid }));
pw.println(MessageFormat.format("SSLID: {0}", new Object[] { sslId }));
pw.println(MessageFormat.format("Info: {0}", new Object[] { notSecret }));
pw.println(MessageFormat.format("Secret: {0}", new Object[] { secret }));
pw.println(MessageFormat.format("Date: {0}", new Object[] { d }));
pw.close();
}

然后,我使用 Firefox 和 Live HTTP Headers 扩展调用了一个合适的未 protected URL,以获取 session cookie。这是我导航到时发送的响应

http://localhost:8080/EchoWeb/unprotected

(我的 web.xml 和你的一样,只保护/user/* 和/personal/*):

URI: /EchoWeb/unprotectedSID: 9ACCD06B69CA365EFD8C10816ADD8D71SSLID: nullInfo: unprotected: 1254034761932Secret: nullDate: 27/09/09 07:59

Next, I tried to access a protected URL

http://localhost:8080/EchoWeb/personal/protected

而且,正如预期的那样,我被重定向到

https://localhost:8443/EchoWeb/personal/protected

响应是

URI: /EchoWeb/personal/protectedSID: 9ACCD06B69CA365EFD8C10816ADD8D71SSLID: 4abf0d67549489648e7a3cd9292b671ddb9dd844b9dba682ab3f381b462d1ad1Info: unprotected: 1254034761932Secret: protected: 1254034791333Date: 27/09/09 07:59

Notice that the cookie/session ID is the same, but we now have a new SSLID. Now, let's try to spoof the server using the session cookie.

I set up a Python script, spoof.py:

import urllib2

url = "https://localhost:8443/EchoWeb/personal/protected"
headers = {
'Host': 'localhost:8080',
'User-Agent': 'Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3',
'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8',
'Accept-Language': 'en-gb,en;q=0.5',
'Accept-Charset': 'ISO-8859-1,utf-8;q=0.7,*;q=0.7',
'Cookie' : 'JSESSIONID=9ACCD06B69CA365EFD8C10816ADD8D71'
}
req = urllib2.Request(url, None, headers)
response = urllib2.urlopen(req)
print response.read()

现在,您不需要了解 Python,尤其是 - 我只是尝试向 Cookie 中具有相同 session ID 的(不同的) protected 资源发送 HTTP 请求。这是我运行我的欺骗脚本两次时的响应:

C:\temp>spoofURI: /EchoWeb/personal/protectedSID: 9ACCD06B69CA365EFD8C10816ADD8D71SSLID: 4abf0eafb4ffa30b6579cf189c402a8411294201e2df94b33a48ae7484f22854Info: unprotected: 1254034761932Secret: protected: 1254035119303Date: 27/09/09 08:05C:\temp>spoofURI: /EchoWeb/personal/protectedSID: 9ACCD06B69CA365EFD8C10816ADD8D71SSLID: 4abf0eb184cb380ce69cce28beb01665724c016903650539d095c671d98f1de3Info: unprotected: 1254034761932Secret: protected: 1254035122004Date: 27/09/09 08:05

请注意,在上面的响应中,在第一个未 protected 请求中设置的 session 数据(时间戳为 1254034761932 的值)已在整个过程中发送,因为 Tomcat 使用相同的 session 因为 session ID 相同。这当然不安全。但是,请注意 SSL ID 每次都不同,如果您使用 那些 键入您的 session 数据(例如如图所示),您应该是安全的。如果我刷新我的 Firefox 选项卡,响应如下:

URI: /EchoWeb/personal/protectedSID: 9ACCD06B69CA365EFD8C10816ADD8D71SSLID: 4abf0d67549489648e7a3cd9292b671ddb9dd844b9dba682ab3f381b462d1ad1Info: unprotected: 1254034761932Secret: protected: 1254034791333Date: 27/09/09 08:05

请注意,SSLID 与之前的 Firefox 请求相同。因此,服务器可以使用 SSL ID 值区分 session 。请特别注意,“ protected 数据”对于从 Firefox session 发出的每个请求都是相同的,但对于每个欺骗 session 都不同并且也不同于 Firefox session 。

关于java - 如何防止tomcat session 劫持?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/1422977/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com