Lỗ hổng AWS API Gateway: Thêm dấu gạch chéo cuối cùng có thể vô hiệu hóa xác thực

Một nhà nghiên cứu bảo mật tên là Piyush Gupta đã phát hiện ra một lỗ hổng nghiêm trọng trong dịch vụ AWS HTTP API, biến thể mới hơn và rẻ hơn của API Gateway. Lỗ hổng này cho phép kẻ tấn công vượt qua hoàn toàn lớp xác thực Lambda authorizer chỉ bằng cách thêm một dấu gạch chéo (/) vào cuối đường dẫn yêu cầu.

Cụ thể, trong khi yêu cầu tới GET /v1/accounts trả về lỗi 401 Unauthorized (chưa được cấp phép), thì yêu cầu tới GET /v1/accounts/ lại trả về mã 200 OK cùng với toàn bộ dữ liệu tài khoản. Nguy hiểm hơn, kỹ thuật này cũng hoạt động với các yêu cầu POST, cho phép Gupta khởi tạo chuyển tiền mà không cần mã JWT hợp lệ tại một công ty fintech.

Nguyên nhân sâu xa: Sự không khớp trong chuẩn hóa đường dẫn

Vấn đề gốc rễ nằm ở sự mâu thuẫn giữa hai lớp xử lý của HTTP API: lớp khớp đường dẫn (route matching) và lớp ủy quyền (authorizer). Hai lớp này hoạt động độc lập và có quan điểm khác nhau về việc thế nào là một "khớp" (match).

Gupta giải thích rằng HTTP API sử dụng cơ chế "greedy path matching" (khớp đường dẫn kiểu tham lam) theo mặc định. Đường dẫn /v1/accounts/ được khớp với /v1/accounts như một tiền tố. Authorizer chạy và trả về kết quả Allow (cho phép). Tuy nhiên, khi đến bước tích hợp (integration), quá trình ánh xạ lại trở nên mơ hồ. Đường dẫn bị viết lại, ngữ cảnh xác thực bị loại bỏ, và đột nhiên người dùng đã ở bên trong hệ thống mà không cần JWT hợp lệ.

Cơ chế hoạt động cụ thể như sau: Authorizer thiết lập trường context.authorizer.userId cho các yêu cầu đã xác thực. Backend Lambda đọc trường này để giới hạn phạm vi truy cập dữ liệu. Khi đường dẫn có dấu gạch chéo đánh vào tầng tích hợp, userId trở thành undefined. Backend không xác thực trường này một cách độc lập mà tin tưởng rằng authorizer đã thiết lập nó. Khi userId không xác định, tích hợp mặc định về tài khoản hệ thống và trả về toàn bộ dữ liệu.

Giải pháp và khuyến nghị

Ngay sau khi phát hiện vấn đề, công ty fintech đã khắc phục bằng cách chuyển từ HTTP API sang REST API (có cơ chế khớp đường dẫn chặt chẽ hơn) và thêm xác thực userId trong mọi hàm Lambda thay vì chỉ dựa vào authorizer.

Gupta cũng chia sẻ các bước để các đội ngũ khác tự kiểm tra:

Nếu bạn muốn tái hiện lỗi này, hãy tạo một HTTP API với lambda authorizer, gửi yêu cầu đến route có và không có dấu gạch chéo ở cuối, sau đó kiểm tra event.requestContext.authorizer trong lambda tích hợp. Nó sẽ xuất hiện khi không có dấu gạch chéo và bị thiếu khi có dấu gạch chéo. Đó là điểm bị rơi.

Một bình luận viên trên Reddit đã chỉ ra rằng HTTP API, dù là phiên bản mới hơn, nhưng quá trình phát triển đã bị "đóng băng" từ 4-5 năm trước do vấn đề về kiến trúc nội bộ. Điều này khiến các đội ngũ cân nhắc sử dụng HTTP API để tiết kiệm chi phí cần phải suy nghĩ kỹ về việc liệu sản phẩm này có nhận được các bản vá cho lớp lỗi khớp đường dẫn hay không.

Một vấn đề không mới

Đây không phải là một lớp lỗ hổng biệt lập. Vào tháng 3 năm 2026, CVE-2026-33186 đã công bố một mô hình gần như giống hệt trong gRPC-Go, khi máy chủ chấp nhận các yêu cầu mà pseudo-header :path bỏ qua dấu gạch chéo bắt buộc. Các interceptor ủy quyền đánh giá đường dẫn thô không chuẩn hóa và không khớp được với các quy tắc từ chối.

Vấn đề về dấu gạch chéo trong AWS API Gateway thực tế không mới. Một chủ đề trên AWS re:Post từ năm 2024 đã ghi nhận hành vi này. Tuy nhiên, điểm mới ở đây là việc chứng minh rằng sự không khớp giữa khớp đường dẫn và ủy quyền có thể bị khai thác để vượt qua xác thực hoàn toàn, chứ không chỉ gây nhầm lẫn trong định tuyến.

Đối với các đội ngũ đang sử dụng AWS HTTP API với Lambda authorizers, các hành động cần thực hiện ngay lập tức bao gồm: kiểm tra xem các biến thể đường dẫn có dấu gạch chéo của các route được bảo vệ có trả về phản hồi khác nhau hay không; đảm bảo các hàm Lambda backend xác thực độc lập các trường ngữ cảnh ủy quyền; và cân nhắc sử dụng cơ chế khớp đường dẫn chặt chẽ hơn của REST API cho các điểm cuối nhạy cảm về bảo mật.