thông tin chi tiết về cuộc tấn công mới vào các trang web sử dụng mô hình front-end-back-end, chẳng hạn như các trang web chạy qua mạng phân phối nội dung, bộ cân bằng tải hoặc proxy. Cuộc tấn công cho phép, bằng cách gửi một số yêu cầu nhất định, chèn vào nội dung của các yêu cầu khác được xử lý trong cùng một luồng giữa giao diện người dùng và phụ trợ. Phương pháp đề xuất đã được sử dụng thành công để tổ chức một cuộc tấn công nhằm chặn các tham số xác thực của người dùng dịch vụ PayPal, phương pháp này đã trả cho các nhà nghiên cứu khoảng 40 nghìn đô la như một phần của chương trình thông báo về sự hiện diện của các lỗ hổng chưa được vá. Cuộc tấn công cũng có thể áp dụng cho các trang web sử dụng mạng phân phối nội dung Akamai.
Điểm mấu chốt của vấn đề là frontend và backend thường cung cấp các mức hỗ trợ khác nhau cho giao thức HTTP, nhưng đồng thời lại gói gọn các yêu cầu từ những người dùng khác nhau vào một kênh chung. Để kết nối các yêu cầu nhận giao diện người dùng và các yêu cầu xử lý phụ trợ, một kết nối TCP tồn tại lâu dài được thiết lập, qua đó các yêu cầu của người dùng được truyền đi, truyền dọc theo chuỗi lần lượt, được phân tách bằng giao thức HTTP. Để phân tách các yêu cầu, tiêu đề "Độ dài nội dung" (xác định tổng kích thước của dữ liệu trong yêu cầu) và ""(cho phép bạn truyền dữ liệu theo từng phần, chỉ định các khối có kích thước khác nhau ở định dạng "{size}\r\n{block}\r\n{size}\r\n{block}\r\n0").
Vấn đề nảy sinh nếu frontend chỉ hỗ trợ “Content-Length” mà bỏ qua “Transfer-Encoding: chunked” (ví dụ Akamai CDN đã làm điều này) hoặc ngược lại. Nếu Transfer-Encoding: chunked được hỗ trợ ở cả hai bên, thì các tính năng triển khai của trình phân tích cú pháp tiêu đề HTTP có thể được sử dụng để tấn công (ví dụ: khi giao diện người dùng bỏ qua các dòng như “Transfer-Encoding: xchunked”, “Transfer-Encoding: chunked ”, “Mã hóa chuyển giao” :[tab]chunked", "X: X[\n]Mã hóa chuyển giao: chunked", "Transfer-Encoding[\n]: chunked" hoặc "Transfer-Encoding : chunked", và chương trình phụ trợ xử lý chúng thành công).
Trong trường hợp này, kẻ tấn công có thể gửi yêu cầu chứa cả tiêu đề "Độ dài nội dung" và "Mã hóa chuyển: chunked", nhưng kích thước trong "Độ dài nội dung" không tương ứng với kích thước của chuỗi chunk, điều này nhỏ hơn giá trị thực tế. Nếu giao diện người dùng xử lý và chuyển tiếp yêu cầu theo "Độ dài nội dung" và phần phụ trợ đợi khối hoàn thành dựa trên "Mã hóa chuyển: chunked", thì phần cuối của dữ liệu dựa trên "Transfer-Encoding: chunked" sẽ được xác định trước đó và phần đuôi còn lại của yêu cầu kẻ tấn công sẽ ở đầu yêu cầu tiếp theo, tức là. kẻ tấn công sẽ có thể đính kèm dữ liệu tùy ý vào phần đầu yêu cầu của người khác được truyền tiếp theo.
Để xác định sự cố trong tổ hợp giao diện người dùng-phụ trợ đã sử dụng, bạn có thể gửi yêu cầu như thế này qua giao diện người dùng:
BÀI ĐĂNG /về HTTP/1.1
Máy chủ: example.com
Mã hóa chuyển giao: chunked
Content-Length: 4
1
Z
Q
Sự cố xảy ra nếu phần phụ trợ không xử lý yêu cầu ngay lập tức và chờ khối giới hạn 0 cuối cùng của dữ liệu được phân đoạn xuất hiện. Để kiểm tra đầy đủ hơn một tiện ích đặc biệt cũng kiểm tra các phương pháp có thể có để ẩn tiêu đề “Transfer-Encoding: chunked” khỏi giao diện người dùng.
Việc thực hiện một cuộc tấn công thực sự phụ thuộc vào khả năng của trang web bị tấn công, ví dụ: khi tấn công ứng dụng web Trello, bạn có thể thay thế phần đầu của yêu cầu (dữ liệu thay thế như “PUT /1/members/1234... x=x&csrf =1234&username=testzzz&bio=cake”) và gửi tin nhắn bao gồm yêu cầu ban đầu của người dùng bên thứ ba và Cookie xác thực được chỉ định trong đó. Đối với một cuộc tấn công vào saas-app.com, hóa ra có thể thay thế mã JavaScript trong phản hồi bằng cách thay thế nó bằng một trong các tham số yêu cầu. Đối với cuộc tấn công vào redhat.com, một trình xử lý nội bộ đã được sử dụng để chuyển hướng đến trang web của kẻ tấn công (một yêu cầu có dạng “POST /search?dest=../assets/idx?redir=//[email được bảo vệ]/HTTP/1.1").
Việc sử dụng phương pháp dành cho mạng phân phối nội dung giúp có thể thay thế trang web được yêu cầu một cách đơn giản bằng cách thay thế tiêu đề “Máy chủ:”. Cuộc tấn công cũng có thể được sử dụng để đầu độc nội dung của hệ thống bộ nhớ đệm nội dung và trích xuất dữ liệu bí mật được lưu trong bộ nhớ đệm. Đỉnh cao của phương pháp này là việc tổ chức một cuộc tấn công vào PayPal, khiến nó có thể chặn mật khẩu do người dùng gửi trong quá trình xác thực (yêu cầu iframe đã được sửa đổi để thực thi JavaScript trong ngữ cảnh của trang paypal.com/us/gifts, dành cho CSP (Chính sách bảo mật nội dung) nào không được áp dụng).
Điều thú vị là năm 2005 đã có một kỹ thuật giả mạo yêu cầu về cơ bản tương tự cho phép bạn giả mạo dữ liệu trong proxy lưu vào bộ nhớ đệm (Tomcat, Squish, mod_proxy) hoặc vượt qua việc chặn tường lửa bằng cách chỉ định một số yêu cầu “GET” hoặc “POST” trong một phiên HTTP.
Nguồn: opennet.ru