Echo WebSocket proxy có thể bỏ qua xác thực tuyến: cách xử lý

Một dịch vụ Go dùng Echo có thể đặt middleware xác thực rất đúng ở từng tuyến nhưng vẫn để lọt yêu cầu nếu Proxy middleware chuyển kết nối sang đường hầm quá sớm. GHSA-cxf3-9h37-7rr8 mô tả đúng tình huống này với WebSocket. Bài viết dành cho đội phát triển API thời gian thực, gateway nội bộ và quản trị VPS đang dùng github.com/labstack/echo/v4 hoặc /v5.

Điều mới trong cảnh báo ngày 22–23/10

Nhóm Echo công bố cảnh báo ngày 22/10/2026; GitHub Advisory Database đăng và rà soát ngày 23/10. Theo GHSA-cxf3-9h37-7rr8, Proxy middleware chọn đường hầm thô ngay khi phía khách yêu cầu nâng cấp WebSocket, trước khi xác nhận upstream có chấp nhận nâng cấp hay không.

Nếu upstream trả về HTTP thông thường, không gửi mã chuyển giao thức hợp lệ nhưng vẫn giữ kết nối, các yêu cầu HTTP tiếp theo trên cùng kết nối có thể đi thẳng tới upstream. Chúng không quay lại router Echo nên có thể bỏ qua middleware xác thực hoặc phân quyền gắn theo tuyến. Điểm CVSS 4.0 được GitHub công bố là 9,1/10, mức nghiêm trọng. Cảnh báo chưa có mã CVE tại thời điểm nguồn được đọc.

Ba điều kiện phải cùng xuất hiện

1. Ứng dụng có một tuyến proxy Echo mà khách bên ngoài hoặc người dùng không tin cậy truy cập được.
2. Upstream từ chối yêu cầu nâng cấp WebSocket nhưng không đóng kết nối.
3. Upstream có tài nguyên đích không tự kiểm tra xác thực, vì đang dựa vào middleware theo tuyến của Echo.

Lỗi không biến Echo thành proxy tới máy bất kỳ và không vượt qua cơ chế xác thực do chính upstream thực hiện. Đây là khác biệt quan trọng khi phân loại mức ưu tiên: gateway đặt trước một dịch vụ nội bộ tin hoàn toàn vào Echo có rủi ro cao hơn proxy tới upstream đã xác thực độc lập.

Phiên bản bị ảnh hưởng

Bản sửa đưa yêu cầu nâng cấp qua reverse proxy HTTP của Go và chỉ tạo đường hầm sau khi upstream trả về phản hồi nâng cấp hợp lệ. Ghi chú Echo v5.4.1 cũng nêu một số thay đổi hành vi: WebSocket đi theo transport, response modifier, đường dẫn và truy vấn được cấu hình như HTTP. Vì vậy, nâng bản cần kiểm thử chứ không chỉ biên dịch lại.

Checklist kiểm tra và triển khai

• Tìm phiên bản thật trong go.mod, go.sum, SBOM và bản nhị phân hoặc ảnh container đang chạy.
• Tìm nơi dùng Proxy middleware, tuyến ws hoặc wss, và cách gắn middleware xác thực theo nhóm hoặc theo tuyến.
• Xác định upstream nào có thể trả phản hồi không phải 101 nhưng giữ kết nối; thử cả lỗi 4xx, chuyển hướng và trang mặc định.
• Nâng v4 lên tối thiểu 4.16.1 hoặc v5 lên tối thiểu 5.4.1; dùng bản mới hơn nếu đã có và phù hợp chính sách.
• Chạy kiểm thử WebSocket thành công, bị từ chối, ngắt giữa chừng và yêu cầu HTTP kế tiếp trên cùng kết nối.
• Kiểm tra header chuyển tiếp sau nâng bản. Đừng giả định Forwarded từ phía khách vẫn được giữ, vì bản phát hành có thêm thay đổi phòng vệ.
• Triển khai theo đợt và giám sát tỷ lệ 101, 4xx/5xx, kết nối treo, lỗi xác thực và thay đổi tải ở upstream.

Nếu chưa thể nâng ngay, hãng khuyến nghị chặn yêu cầu nâng cấp WebSocket trước khi tới tuyến proxy bị ảnh hưởng hoặc buộc mọi tài nguyên upstream tự xác thực. Chỉ cấu hình upstream trả lỗi không phải 101 chưa đủ, vì chính phản hồi bị từ chối nhưng còn mở kết nối là một phần điều kiện lỗi.

Ảnh hưởng với khách thuê VPS/máy chủ

Sự cố này không liên quan trực tiếp đến cấu hình máy yếu. Một VPS lớn hơn không làm middleware an toàn hơn. Điều cần thiết là môi trường thử nghiệm giống cấu hình proxy thật, khả năng thay binary/container có kiểm soát và theo dõi kết nối dài. Với tải WebSocket lớn, đội vận hành cũng nên đo số kết nối, bộ nhớ và giới hạn file descriptor sau khi đổi cơ chế proxy.

Nguồn tham khảo

• GitHub Advisory: GHSA-cxf3-9h37-7rr8, công bố 22/10 và cập nhật 23/10/2026
• Echo v4.16.1
• Echo v5.4.1

Đội Go cần thử bản nâng cấp có thể gửi phiên bản Echo, sơ đồ tuyến proxy, số kết nối WebSocket và cấu hình upstream qua hotro@thuemaychu.vn. Dữ liệu này giúp trao đổi tài nguyên Cloud VPS cho môi trường thử và theo dõi kết nối; quyết định vá vẫn phải dựa trên mã và cấu hình ứng dụng thực tế.