生產事故-走近科學之消失的JWT

入職多年，面對生產環境，儘管都是小心翼翼，慎之又慎，還是難免捅出簍子。輕則滿頭大汗，面紅耳赤。重則系統停擺，損失資金。每一個生產事故的背後，都是寶貴的經驗和教訓，都是項目成員的血淚史。為了更好地防範和遏制今後的各類事故，特開此專題，長期更新和記錄大大小小的各類事故。有些是親身經歷，有些是經人耳傳口授 ...

入職多年，面對生產環境，儘管都是小心翼翼，慎之又慎，還是難免捅出簍子。輕則滿頭大汗，面紅耳赤。重則系統停擺，損失資金。每一個生產事故的背後，都是寶貴的經驗和教訓，都是項目成員的血淚史。為了更好地防範和遏制今後的各類事故，特開此專題，長期更新和記錄大大小小的各類事故。有些是親身經歷，有些是經人耳傳口授，但無一例外都是真實案例。

註意：為了避免不必要的麻煩和商密問題，文中提到的特定名稱都將是化名、代稱。

0x01 事故背景

2021年11月26日01時10分，P公司正在進行某業務系統的生產環境部署操作，但其實早在00時30分的時候，他們已經完成過一次部署了，但是奇怪的是無論如何都通不過驗證，無奈只好推倒重來，如此反覆了有若幹次。為何反覆嘗試，卻不嘗試去尋找問題呢？問題就在於該系統同一份代碼在開發環境和 UAT 環境均一切正常，唯獨部署到生產環境上面就不行。這是一個前後端分離的業務系統，前端與後端介面基於 JWT 而不是傳統 Session 進行鑒權認證。故障的現象也很簡單，就是無法登錄——準確的說，是登錄後不能維持登錄狀態，一訪問其他需要鑒權的資源立馬又被重定向到登錄頁面。2020年10月25日02時30分，在運維人員多次嘗試無果，開發人員排查代碼也未發現問題後，P公司不得不直呼見鬼。那麼真相究竟是什麼呢？

0x02 事故分析

在 RFC 7519 規範中對於 JWT 是這樣描述的：

JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code(MAC) and/or encrypted.

JWT (JSON Web Token) 是一種緊湊、URL 安全的表示方式，用於表達要在兩個參與方之間傳輸的安全聲明。JWT 中的聲明被編碼為 JSON 對象，作為 JSON Web Signature (JWS) 結構的有效載荷或 JSON Web Encryption (JWE) 結構的明文，使得聲明可以使用消息認證碼 (MAC) 進行數字簽名或完整性保護和/或加密。

說人話呢意思就是 JWT 是一種安全令牌的標準化實現，用於參與雙方之間的可信交互認證。既然不好定位是環境還是代碼的問題，不妨先捋一捋 JWT 鑒權認證的過程，看看問題可能發生在哪一步：

JWT鑒權認證流程

從故障現象來看，步驟①出問題的可能性基本被排除，從前端請求和後端日誌來看賬號和密碼的驗證過程已經正確完成；
那麼步驟②有沒有可能出問題呢？當時也是懷疑過的，但是使用瀏覽器的 F12 開發者工具，看到 login 的網路請求響應中已經將後端生成的 JWT 返回來了；
莫非是步驟③沒有將 JWT 正確攜帶，導致後續驗證不通過？但是查看登陸後，對其他介面的請求，裡面確實已經攜帶了步驟②中提供的 JWT，而且數值也一致；
驗證JWT的代碼邏輯會不會有問題呢？可能性不大，因為在測試環境和 UAT 環境已經反覆驗證過。

那麼問題還是出在步驟③攜帶 JWT 這一步。前面分析過前端發起請求時，已經攜帶了 JWT，那麼有沒有可能是後端沒收到或者收到的值不正確呢？很可惜，後端收到 JWT 後沒有列印相關的日誌……只有簡單的提示驗證失敗的信息。但其實到這裡，已經可以懷疑是環境的問題了，因為同樣的代碼只在生產環境出錯。

隨機抽取一個運維小伙子，讓他說說生產的系統結構，從他口中得知，生產上除了為了部署多個節點，使用了 Nginx 作為負載均衡和反向代理外，其他地方沒有區別。憑藉往常的經驗呢，P公司的員工們首先呢就沒有懷疑過反代和負載會影響這個業務功能，但是我們的理性分析又提示我們問題很有可能出在這裡。

不妨找個機器驗證一下，安裝和生產環境相同版本的 Nginx，然後配置一下反代和負載。對了，這回啊，在後端把列印 JWT 的Debug日誌加上。然後果不出所料，前端雖然在請求頭中攜帶了 JWT，但是到了後端，卻顯示沒有這個信息，這個頭，它丟到哪裡去了呢？

0x03 事故原因

前端在步驟③請求頭中攜帶的 JWT 如下，HTTP_HEADER_NAME 為 “JWT_TOKEN”，HTTP_HEADER_VALUE 為 JWT 的值：

JWT_TOKEN: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJkYXRhIjpbb2x0...

在後端日誌中，除了 JWT_TOKEN 以外，其他的頭部信息都正常傳遞，我們註意到，它的 HTTP_HEADER_NAME 包含了下劃線，這是它與眾不同的地方。難道是被 Nginx 過濾了？

在 Nginx 的官方文檔里，有這麼一段話：

Missing (disappearing) HTTP Headers

If you do not explicitly set underscores_in_headers on;, NGINX will silently drop HTTP headers with underscores (which are perfectly valid according to the HTTP standard). This is done in order to prevent ambiguities when mapping headers to CGI variables as both dashes and underscores are mapped to underscores during that process.

消失的 HTTP Headers

如果你沒有顯式設置 underscores_in_headers on;，NGINX 會靜悄悄地幹掉帶有下劃線的 HTTP 請求頭（雖然它們符合 HTTP 規範，毀滅你與你何干……）。這樣做是為了防止在將請求頭映射到 CGI 變數時出現歧義，因為在此過程中，短劃線和下劃線都映射到下劃線。

在 ngx_http_parse.c 中，這個開關是這樣處理的：

/* header name */
case sw_name:
    c = lowcase[ch];

    if (c) {
        hash = ngx_hash(hash, c);
        r->lowcase_header[i++] = c;
        i &= (NGX_HTTP_LC_HEADER_LEN - 1);
        break;
    }

    if (ch == '_') {
        if (allow_underscores) {
            hash = ngx_hash(hash, ch);
            r->lowcase_header[i++] = ch;
            i &= (NGX_HTTP_LC_HEADER_LEN - 1);

        } else {
            r->invalid_header = 1;
        }

        break;
    }
    // ……（太長只截取關鍵部分）
    break;

如果沒有開啟underscores_in_headers開關，對應變數allow_underscores，則預設情況下，帶有下劃線的 HTTP_HEADER 會被標記為 INVALID_HEADER.而標記為 INVALID_HEADER 的信息預設情況下，會被忽略掉，為什麼說預設呢？因為這個行為同時還受到另一個開關ignore_invalid_headers控制，如果它被開啟，那麼帶有下劃線的 HTTP_HEADER 就真的神秘消失了。

關於 underscores_in_headers 選項：

Syntax: underscores_in_headers on | off;

Default: underscores_in_headers off;

Context: http, server

Enables or disables the use of underscores in client request header fields. When the use of underscores is disabled, request header fields whose names contain underscores are marked as invalid and become subject to the ignore_invalid_headers directive.

關於 ignore_invalid_headers 選項：

Syntax: ignore_invalid_headers on | off;

Default: ignore_invalid_headers on;

Context: http, server

Controls whether header fields with invalid names should be ignored. Valid names are composed of English letters, digits, hyphens, and possibly underscores (as controlled by the underscores_in_headers directive).

可以看到underscores_in_headers選項預設情況下是關閉的，而ignore_invalid_headers選項預設情況下是開啟的，這也就導致了我們 JWT_TOKEN 的神秘失蹤，至此問題已經定位完畢。

0x04 事故復盤

這次可以說是純純的意外，但是這個意外本可以發現的更早：

再窮也好，至少也要申請一個與生產環境相同/相仿的復刻環境。
統一且規範的命名，或許可以避免很多不必要的麻煩。
所謂Debug日誌就是，沒事的時候，你看到它嫌它煩；出事的時候，你煩看不到它……

排查問題時，還是大意了，沒有去看 Nginx 的日誌，因為通過源碼可以發現 INVALID_HEADER 預設情況下是會觸發 ERROR 日誌的：

if (rc == NGX_OK) {

    r->request_length += r->header_in->pos - r->header_name_start;

    if (r->invalid_header && cscf->ignore_invalid_headers) {

        /* there was error while a header line parsing */

        ngx_log_error(NGX_LOG_INFO, c->log, 0,
                      "client sent invalid header line: \"%*s\"",
                      r->header_end - r->header_name_start,
                      r->header_name_start);
        continue;
    }
    // ……（太長只截取關鍵部分）
}

0x05 事故影響

使P公司新業務系統上線時間延長了3小時，相關人員連夜跟老闆申請伺服器經費。（知道了，下次還是不批）。