Question

在我的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>

当我用http加载页面时，我的cookie中已经有了我的JSESSIONID ID1。
当我更改为context / user / sample.faces时，Tomcat会将302重定向到HTTPS。但是我的JSESSIONID仍然是ID1。

我认为这是一个漏洞？或者是我的配置错误？

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

Answer 1

如果它是Tomcat的最新版本，您可能没有问题。但是，这取决于您检查与会话关联的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扩展调用了一个合适的不受保护的URL，以获取会话cookie。这是我导航到

时发送的响应

http://localhost:8080/EchoWeb/unprotected

（我的web.xml与您的一样，仅保护/ user / *和/ personal / *）：

URI: /EchoWeb/unprotected
SID: 9ACCD06B69CA365EFD8C10816ADD8D71
SSLID: null
Info: unprotected: 1254034761932
Secret: null
Date: 27/09/09 07:59

接下来，我尝试访问受保护的网址

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

并且正如预期的那样，我被重定向到

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

，回复是

URI: /EchoWeb/personal/protected
SID: 9ACCD06B69CA365EFD8C10816ADD8D71
SSLID: 4abf0d67549489648e7a3cd9292b671ddb9dd844b9dba682ab3f381b462d1ad1
Info: unprotected: 1254034761932
Secret: protected: 1254034791333
Date: 27/09/09 07:59

请注意，cookie /会话ID是相同的，但我们现在有一个新的SSLID。现在，让我们尝试使用会话cookie来欺骗服务器。

我设置了一个Python脚本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，特别是 - 我只是尝试将HTTP请求发送到Cookie中具有相同会话ID的（不同的）受保护资源。这是我两次运行恶搞脚本时的响应：

C:\temp>spoof
URI: /EchoWeb/personal/protected
SID: 9ACCD06B69CA365EFD8C10816ADD8D71
SSLID: 4abf0eafb4ffa30b6579cf189c402a8411294201e2df94b33a48ae7484f22854
Info: unprotected: 1254034761932
Secret: protected: 1254035119303
Date: 27/09/09 08:05


C:\temp>spoof
URI: /EchoWeb/personal/protected
SID: 9ACCD06B69CA365EFD8C10816ADD8D71
SSLID: 4abf0eb184cb380ce69cce28beb01665724c016903650539d095c671d98f1de3
Info: unprotected: 1254034761932
Secret: protected: 1254035122004
Date: 27/09/09 08:05

请注意，在上述响应中，第一个未受保护的请求中设置的会话数据（时间戳为1254034761932的值）已在整个过程中发送，因为Tomcat正在使用相同的会话，因为会话ID是一样的。这当然是不安全。但请注意，每次SSL ID 都不同，并且如果您使用那些来键入会话数据（例如，如图所示），那么您应该是安全的。如果我刷新我的Firefox选项卡，这是响应：

URI: /EchoWeb/personal/protected
SID: 9ACCD06B69CA365EFD8C10816ADD8D71
SSLID: 4abf0d67549489648e7a3cd9292b671ddb9dd844b9dba682ab3f381b462d1ad1
Info: unprotected: 1254034761932
Secret: protected: 1254034791333
Date: 27/09/09 08:05

请注意，SSLID与早期的Firefox请求相同。因此，服务器可以使用SSL ID值来区分会话。特别注意，对于每个从Firefox会话发出的请求，“受保护数据”是相同的，但每个欺骗会话的不同，也与Firefox会话不同。

Answer 2

我认为它的设计就像这样。您无法在会话中建立访问控制。您需要使用其他参数。您需要添加身份验证并使用基于角色的控制。

在Tomcat中，有保护但完全相反。如果您在安全区域中进行会话，则该会话不会转移到不受保护的区域。 Tomcat通过在cookie上设置“secure”标志来实现这一点，因此cookie不会发送到HTTP连接。

Answer 3

我建议您在验证会话时更改sessionId 通过这种方式，旧的sessionId变得无用，并且会话劫持是不可能的要更改servlet容器中的sessionId：

复制临时集合上当前会话的所有属性
session.invalidate（）
session = req.getSession（true）
使用临时集合中的属性填充新会话

关于SSLID，请注意客户端和服务器可以随时关闭连接。关闭时，将发生新的SSL握手并生成新的SSID。因此，IMO SSLID不是跟踪（或帮助跟踪）会话的可靠方式。

如何防止tomcat会话劫持？

3 个答案: