如何防止tomcat會話劫持？

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>

1. 當我用http加載頁面時，我的cookie中有我的JSESSIONID ID1。
2. 當我更改為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

接下來，我嘗試訪問受保護的URL

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 都不同 ，如果您使用這些 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不是跟蹤（或幫助跟蹤）會話的可靠方式。