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

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

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

0x00 大綱

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 鑑權認證的過程，看看問題可能發生在哪一步：

1. 從故障現象來看，步驟①出問題的可能性基本被排除，從前端請求和後端紀錄檔來看賬號和密碼的驗證過程已經正確完成；
2. 那麼步驟②有沒有可能出問題呢？當時也是懷疑過的，但是使用瀏覽器的 F12 開發者工具，看到 login 的網路請求響應中已經將後端生成的 JWT 返回來了；
3. 莫非是步驟③沒有將 JWT 正確攜帶，導致後續驗證不通過？但是檢視登陸後，對其他介面的請求，裡面確實已經攜帶了步驟②中提供的 JWT，而且數值也一致；
4. 驗證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小時，相關人員連夜跟老闆申請伺服器經費。（知道了，下次還是不批）。