HTTP Request Smuggling 

HTTP request smuggling (Tấn công bất đồng bộ HTTP) là một kỹ thuật được sử dụng để can thiệp vào quá trình trang web xử lý các chuỗi yêu cầu HTTP nhận được từ một hay nhiều người dùng.

Các lỗ hổng liên quan đến HTTP request smuggling thường xuất hiện khi front-end và các máy chủ back-end có bất đồng trong việc xử lý các yêu cầu HTTP. Từ đó cho phép kẻ tấn công gửi hoặc đánh cắp một yêu cầu không xác định và ghép nó vào yêu cầu của người dùng tiếp theo.

Việc không đồng bộ các yêu cầu có thể bị khai thác để đánh cắp thông tin đăng nhập, đưa về các phản hồi sai cho người dùng, thậm chí là lấy cắp dữ liệu từ yêu cầu của nạn nhân, sau đó chuyển thông tin đến máy chủ do kẻ tấn công kiểm soát.

Kỹ thuật này được trình bày lần đầu tiên vào năm 2005 bởi một nhóm các nhà nghiên cứu từ Watchfire gồm: Klein, Chaim Linhart, Ronen Heled và Steve Orrin. Tuy nhiên, trong 5 năm qua những kẻ tấn công bổ sung thêm một số cải tiến mới, khiến phạm vi tấn công lớn hơn. Các biến thể có thể ghép các yêu cầu lại với nhau và chiếm được quyền truy cập tối đa vào API nội bộ gây nhiễm độc web cache và xâm nhập vào trang đăng nhập của các ứng dụng phổ biến.  

Các biến thể mới này được Klein, Phó Giám đốc Nghiên cứu Bảo mật tại SafeBreach tiết lộ: kết hợp sử dụng nhiều proxy-server khác nhau, bao gồm Abyss của Aprelium, Microsoft IIS, Apache và Tomcat trong chế độ web-server và Nginx, Squid, HAProxy, Caddy và Traefik trong chế độ HTTP proxy.

Dưới đây là bốn biến thể mới được phát hiện và một biến thể cũ mà Klein đã khai thác thành công trong các nghiên cứu của mình:

Variant 1: “Header SP/CR junk: …”

Variant 2 – “Wait for It”

Variant 3 – HTTP/1.2 to bypass mod_security-like defense

Variant 4 – a plain solution

Variant 5 – “CR header” 

Khi xử lý các yêu cầu HTTP chứa hai tiêu đề Content - Length, thì Abyss đã được phát hiện chỉ chấp nhận tiêu đề thứ hai là hợp lệ, trong khi Squid sử dụng tiêu đề đầu tiên, do đó dẫn đến việc hai máy chủ xử lý các yêu cầu khác nhau và làm xuất hiện “request smuggling”.
Trong trường hợp Abyss nhận được một yêu cầu HTTP với nội dung có độ dài nhỏ hơn giá trị Content - Length được chỉ định, nó sẽ đợi 30 giây để thực hiện yêu cầu nhưng không bỏ qua nội dung còn lại của yêu cầu. Klein thấy rằng điều này cũng dẫn đến sự khác biệt giữa Squid và Abyss, bởi các phần xử lý sau của một yêu cầu HTTP sẽ được gửi đi như một yêu cầu thứ hai.

Biến thể thứ ba của phương pháp này sử dụng HTTP/1.2 để phá vỡ hệ thống phòng thủ của tường lửa web (WAF-Web application firewall). Trong Bộ quy tắc cốt lõi (Computer reservation - CRS) của OWASP ModSecurity, tường lửa này được định rõ là dùng để ngăn chặn việc các cuộc tấn công HTTP request smuggling thực hiện các hành vi mang tính độc hại.

Cuối cùng, Klein phát hiện ra rằng sử dụng trường tiêu đề “Content - Type: text/plain” cũng đủ để vượt qua khâu kiểm tra paranoia mức độ 1 và 2 được chỉ định trong CRS và làm xuất hiện một lỗ hổng HTTP Request Smuggling.

Những biện pháp bảo vệ khả thi 

Sau khi phát hiện này được công bố cho Aprelium, Squid và OWASP CRS, các vấn đề đã được khắc phục trong Abyss X1 phiên bản 2.14, Squid phiên bản 4.12, 5.0.3 và CRS phiên bản 3.3.0.

Klein kêu gọi tiêu chuẩn hóa các yêu cầu HTTP gửi đi từ các máy chủ proxy và nhấn mạnh sự cần thiết của một giải pháp tường lửa mạnh mẽ dành cho website, mã nguồn mở có khả năng xử lý các cuộc tấn công HTTP Request Smuggling.

“ModSecurity (kết hợp với CRS) quả thực là một dự án mã nguồn mở, nhưng nếu xét về độ mạnh và tính tổng quát, thì ModSecurity còn tồn tại một số nhược điểm. Nó không thể bảo vệ hệ thống hoàn toàn trước các cuộc tấn công HTTP Request Smuggling và nó chỉ khả dụng cho Apache, IIS và nginx,” Klein cho biết.

Để giải quyết vấn đề này, Klein đã cho công bố một thư viện dựa trên C++ trên GitHub. Thư viện này giúp đảm bảo tất cả các yêu cầu HTTP gửi đến là hoàn toàn hợp lệ và được xác định rõ ràng bằng cách yêu cầu nó phải tuân thủ nghiêm ngặt các quy tắc về định dạng tiêu đề HTTP và định dạng dòng yêu cầu.