FastCGI: Giao thức 30 năm tuổi vẫn vượt trội hơn HTTP cho Reverse Proxy

Reverse proxy bằng HTTP thực sự là một bãi mìn.

Chỉ mới tuần trước, một nhà nghiên cứu đã công bố lỗ hổng desync trong proxy truyền thông của Discord, cho phép theo dõi các tệp đính kèm riêng tư. Đây không phải là trường hợp hiếm gặp; các lỗ hổng này cứ liên tục xuất hiện. Vấn đề nằm ở việc sử dụng rộng rãi HTTP làm giao thức giữa reverse proxy và backend, dù nó hoàn toàn không phù hợp cho nhiệm vụ này.

Tuy nhiên, chúng ta không bắt buộc phải dùng HTTP ở đây. Có một giao thức 30 năm tuổi dành cho giao tiếp giữa proxy và backend giúp tránh được các cạm bẫy của HTTP. Đó gọi là FastCGI, và thông số kỹ thuật của nó được phát hành chính xác vào ngày này cách đây 30 năm.

Đúng là một số máy chủ web có thể tự động khởi chạy các tiến trình FastCGI để xử lý yêu cầu cho các tệp có phần mở rộng .fcgi, giống như cách chúng xử lý .cgi. Nhưng bạn không nhất thiết phải dùng FastCGI theo cách đó — bạn cũng có thể sử dụng giao thức FastCGI giống hệt như HTTP, với các yêu cầu được gửi qua socket TCP hoặc UNIX đến một daemon chạy lâu dài xử lý chúng như thể chúng là các yêu cầu HTTP.

Ví dụ, trong ngôn ngữ Go, tất cả những gì bạn cần làm là nhập gói thư viện chuẩn net/http/fcgi và thay thế http.Serve bằng fcgi.Serve:

Mọi thứ khác về ứng dụng của bạn vẫn giữ nguyên — thậm chí cả trình xử lý (handler) của bạn, vốn tiếp tục sử dụng các kiểu tiêu chuẩn http.ResponseWriter và http.Request. Các proxy phổ biến như Apache, Caddy, nginx và HAProxy đều hỗ trợ backend FastCGI, và cấu hình rất đơn giản.

HTTP/1.1 có đặc điểm "bi kịch" là nhìn thì đơn giản (chỉ là văn bản!) nhưng thực tế lại là ác mộng để phân tích cú pháp một cách mạnh mẽ. Có quá nhiều cách khác nhau để định dạng cùng một thông điệp HTTP, và quá nhiều trường hợp ngoại lệ cũng như sự mơ hồ để các triển khai xử lý một cách nhất quán.

Kết quả là, không có hai triển khai HTTP/1.1 nào hoàn toàn giống nhau, và cùng một thông điệp có thể được phân tích khác nhau bởi các trình phân tích khác nhau. Vấn đề nghiêm trọng nhất là không có khung (framing) rõ ràng cho các thông điệp HTTP — chính thông điệp đó mô tả nơi nó kết thúc, và có nhiều cách để một thông điệp làm điều đó, tất cả đều có các trường hợp ngoại lệ riêng.

Các triển khai có thể không đồng thuận về nơi một thông điệp kết thúc, và do đó, nơi thông điệp tiếp theo bắt đầu. Đây là nền tảng của các cuộc tấn công desync HTTP, còn được gọi là request smuggling, trong đó reverse proxy và backend không đồng thuận về ranh giới giữa các thông điệp HTTP, gây ra mọi loại vấn đề bảo mật ác mộng, chẳng hạn như lỗ hổng Discord mình đã liên kết ở trên.

Rất nhiều người dường như nghĩ rằng bạn chỉ cần vá các sự khác biệt của trình phân tích, nhưng đây là một chiến lược thua cuộc. James Kettle cứ liên tục tìm ra các cái mới. Sau khi tìm thấy một lô khác vào năm ngoái, ông đã tuyên bố "HTTP/1.1 phải chết".

HTTP/2, khi được sử dụng nhất quán giữa proxy và backend, khắc phục desync bằng cách đặt ra các ranh giới rõ ràng xung quanh thông điệp, nhưng FastCGI đã làm điều đó từ năm 1996 với một giao thức đơn giản hơn.

Để bạn dễ hình dung, nginx đã hỗ trợ backend FastCGI kể từ bản phát hành đầu tiên, nhưng chỉ mới hỗ trợ backend HTTP/2 vào cuối năm 2025. Hỗ trợ backend HTTP/2 của Apache vẫn ở trạng thái "thử nghiệm".

Nếu các cuộc tấn công desync là vấn đề duy nhất, bạn có thể chỉ cần dùng HTTP/2 và coi như xong việc. Thật không may, còn có một vấn đề khác: HTTP không có cách mạnh mẽ để proxy chuyển tiếp thông tin tin cậy về yêu cầu, chẳng hạn như địa chỉ IP thực của máy khách, tên người dùng đã xác thực (nếu proxy xử lý xác thực), hoặc chi tiết chứng chỉ máy khách (nếu sử dụng mTLS).

Lựa chọn duy nhất là đưa thông tin này vào các tiêu đề HTTP, cùng với các tiêu đề được ủy quyền từ máy khách, không có sự phân biệt cấu trúc rõ ràng giữa các tiêu đề tin cậy từ proxy và các tiêu đề không tin cậy từ một kẻ tấn công tiềm năng.

Ví dụ, tiêu đề X-Real-IP thường được dùng để chuyển tiếp địa chỉ IP thực của máy khách. Về lý thuyết, nếu proxy của bạn xóa chính xác tất cả các phiên bản của tiêu đề X-Real-IP (không chỉ cái đầu tiên, và bao gồm cả các biến thể viết hoa như x-REaL-ip) trước khi thêm của chính nó, bạn sẽ an toàn. Trong thực tế, đây là một bãi mìn và có vô số cách backend của bạn có thể kết thúc việc tin vào dữ liệu do kẻ tấn công kiểm soát.

Proxy của bạn thực sự cần xóa không chỉ X-Real-IP, mà bất kỳ tiêu đề nào được dùng cho mục đích này, phòng trường hợp một phần nào đó của ngăn xếp của bạn dựa vào nó mà không có kiến thức của bạn. Ví dụ, middleware Chi xác định địa chỉ IP thực của máy khách bằng cách nhìn vào tiêu đề True-Client-IP trước. Chỉ khi True-Client-IP không tồn tại, nó mới dùng X-Real-IP. Vì vậy, ngay cả khi proxy của bạn làm đúng với X-Real-IP, bạn vẫn có thể bị tấn công bởi một kẻ gửi tiêu đề True-Client-IP.

FastCGI hoàn toàn tránh được loại vấn đề này bằng cách cung cấp sự phân tách miền (domain separation) giữa các tiêu đề từ máy khách và thông tin được thêm bởi proxy. Mặc dù dữ liệu tin cậy từ proxy và các tiêu đề yêu cầu HTTP được truyền đến backend trong cùng một danh sách tham số khóa/giá trị, tên tiêu đề HTTP có tiền tố là chuỗi HTTP_, làm cho việc cấu trúc không thể để máy khách gửi một tiêu đề sẽ được hiểu là dữ liệu tin cậy.

FastCGI định nghĩa một số tham số tiêu chuẩn như REMOTE_ADDR để chuyển tiếp địa chỉ IP thực của máy khách. Gói net/http/fcgi của Go tự động sử dụng tham số này để điền trường RemoteAddr của http.Request, làm cho middleware trở nên không cần thiết. Nó "chỉ hoạt động" (Just Works). Các proxy cũng có thể sử dụng các tham số không tiêu chuẩn để báo cáo liệu HTTPS có được sử dụng hay không, bộ mã hóa TLS nào đã được thương lượng, và chứng chỉ máy khách nào đã được trình bày (nếu có).

Go tự động đặt trường TLS của Request thành một giá trị khác nil (nhưng rỗng) nếu yêu cầu sử dụng HTTPS, rất hữu ích để thực thi việc sử dụng HTTPS. Hàm fcgi.ProcessEnv có thể được dùng để truy cập tập hợp đầy đủ các tham số tin cậy được gửi bởi proxy.

Nếu FastCGI là giao thức tốt hơn, tại sao nó không phổ biến hơn? Có lẽ là cái tên — trong khi việc tận dụng sự phổ biến của CGI có ý nghĩa vào năm 1996, CGI cảm thấy lỗi thời vào năm 2026. Cũng còn sự thiếu hụt nhận thức kéo dài về các vấn đề bảo mật với reverse proxy HTTP.

Watchfire đã mô tả các cuộc tấn công desync vào năm 2005 và đưa ra cảnh báo tiên tri về tính không thể giải quyết của chúng, nhưng các cuộc tấn công này đã bị bỏ qua một cách khó hiểu trong hơn một thập kỷ. Trong một dòng thời gian thay thế, nghiên cứu của Watchfire được nghiêm túc tiếp nhận và mọi người bắt đầu tìm kiếm các giao thức khác cho reverse proxies.

FastCGI vẫn rất hữu dụng ngày nay và đã được sử dụng trong môi trường sản xuất tại SSLMate hơn 10 năm. Tuy nhiên, việc sử dụng một công nghệ cũ kỹ có một số nhược điểm. Nó không bao giờ được cập nhật để hỗ trợ WebSockets. Công cụ hỗ trợ không tốt bằng. Ví dụ, curl không có cách nào gửi yêu cầu đến máy chủ FastCGI. Nó hỗ trợ FTP, Gopher, và thậm chí SMTP (dù nó hoạt động thế nào), nhưng không có FastCGI.

Khi mình benchmark máy chủ FastCGI của Go đằng sau một loạt các reverse proxy khác nhau, một số khối lượng công việc có thông lượng kém hơn so với HTTP/1.1 hoặc HTTP/2. Mình không nghĩ đó là vốn có của giao thức, mà là sự phản ánh rằng các đường dẫn mã FastCGI không được tối ưu hóa nhiều như HTTP.

Mặc dù có những thiếu sót này, mình vẫn nghĩ FastCGI đáng để sử dụng. Mình không dùng WebSockets, và nó đủ nhanh cho trường hợp sử dụng của mình (và có thể cả của bạn). Nếu nó từng trở thành nút thắt cổ chai, mình thà mua thêm phần cứng còn là phải đối mặt với cơn ác mộng của reverse proxy HTTP.