Phần này minh họa các ví dụ về các cuộc tấn công tận dụng các tính năng cụ thể của giao thức HTTP, bằng cách khai thác các điểm yếu của ứng dụng web hoặc đặc thù theo cách các tác nhân khác nhau diễn giải thông điệp HTTP. Phần này sẽ phân tích hai cuộc tấn công khác nhau nhắm vào các tiêu đề HTTP cụ thể:
- HTTP splitting
- HTTP smuggling
Cuộc tấn công đầu tiên khai thác sự thiếu lọc giá trị đầu vào cho phép kẻ xâm nhập chèn các ký tự CR và LF vào tiêu đề của phản hồi ứng dụng và ‘tách’ câu trả lời đó thành hai thông báo HTTP khác nhau. Mục tiêu của cuộc tấn công có thể khác nhau, từ nhiễm độc bộ nhớ cache cross site scripting.
Các bài viết liên quan:
Trong cuộc tấn công thứ hai, kẻ tấn công khai thác thực tế rằng một số thông điệp HTTP được tạo đặc biệt có thể được phân tích cú pháp và diễn giải theo những cách khác nhau tùy thuộc vào tác nhân nhận chúng. Việc nhập lậu HTTP yêu cầu một số kiến thức về các tác nhân khác nhau đang xử lý các thông báo HTTP (máy chủ web, proxy, tường lửa) và do đó sẽ chỉ được đưa vào phần kiểm tra hộp xám.
Định nghĩa HTTP Splitting Smuggling
HTTP Splitting Smuggling (còn được gọi là HTTP Request Smuggling) là một lỗ hổng bảo mật trong các ứng dụng web, mà nguyên nhân chính là sự không đồng nhất trong cách các máy chủ web và bộ định tuyến xử lý các yêu cầu HTTP đa luồng (HTTP pipelining).
Khi tấn công HTTP Splitting Smuggling, kẻ tấn công tận dụng sự không đồng nhất này để chèn các ký tự đặc biệt, chẳng hạn như các ký tự xuống dòng (line break), vào yêu cầu HTTP. Kết quả là, yêu cầu được chia nhỏ thành nhiều phần nhỏ hơn khi đi qua các lớp bảo mật, nhưng được ghép lại lại thành yêu cầu hoàn chỉnh tại máy chủ đích. Điều này có thể dẫn đến việc kẻ tấn công thực hiện các hành vi không mong muốn hoặc đánh lừa hệ thống.
Kẻ tấn công có thể tận dụng lỗ hổng này để thực hiện các cuộc tấn công như lừa đảo, đánh cắp thông tin người dùng, thay đổi nội dung yêu cầu, hoặc thậm chí tấn công Cross-Site Scripting (XSS) và Server-Side Request Forgery (SSRF).
Để phòng chống HTTP Splitting Smuggling, cần kiểm tra và xử lý đúng cách các yêu cầu HTTP, đảm bảo đồng nhất trong cách xử lý yêu cầu tại máy chủ web và bộ định tuyến, và áp dụng các biện pháp bảo mật phù hợp.
Xem thêm Tìm hiểu tấn công HTTP Response Splitting
Rủi ro và hậu quả của HTTP Splitting Smuggling
Rủi ro và hậu quả của HTTP Splitting Smuggling có thể bao gồm:
- Tấn công lừa đảo: Kẻ tấn công có thể sử dụng HTTP Splitting Smuggling để lừa đảo người dùng và đánh cắp thông tin nhạy cảm như tên đăng nhập, mật khẩu, thông tin tài khoản ngân hàng, và thông tin cá nhân khác.
- Tấn công Cross-Site Scripting (XSS): HTTP Splitting Smuggling có thể được sử dụng như một phương pháp để thực hiện tấn công XSS trên các ứng dụng web. Kẻ tấn công có thể chèn mã độc hại vào yêu cầu HTTP và gửi nó đến máy chủ, từ đó lợi dụng sự tin tưởng của máy chủ để thực thi mã độc hại trên trình duyệt của người dùng.
- Đánh cắp thông tin người dùng: Kẻ tấn công có thể sử dụng HTTP Splitting Smuggling để truy cập và đánh cắp thông tin nhạy cảm của người dùng như phiếu điều hướng, cookie, token xác thực, và thông tin cá nhân khác.
- Thực hiện các hoạt động không mong muốn: Kẻ tấn công có thể sử dụng HTTP Splitting Smuggling để thực hiện các hoạt động không mong muốn trên máy chủ web, bao gồm thay đổi nội dung yêu cầu, tạo yêu cầu giả mạo, hoặc gửi các yêu cầu không hợp lệ nhằm gây ra tình trạng lỗi hoặc quá tải máy chủ.
- Ảnh hưởng đến uy tín và niềm tin của người dùng: Nếu một ứng dụng web bị tấn công và thông tin cá nhân của người dùng bị đánh cắp hoặc bị lợi dụng, sẽ gây ảnh hưởng tiêu cực đến uy tín và niềm tin của người dùng đối với ứng dụng và tổ chức điều hành nó.
Đối với các ứng dụng web, rủi ro và hậu quả của HTTP Splitting Smuggling có thể là nghiêm trọng. Do đó, việc phòng chống và khắc phục lỗ hổng này là cực kỳ quan trọng để đảm bảo an toàn và bảo mật cho người dùng và dữ liệu của họ.
Xem thêm Code Splitting trong React
Cách phòng chống HTTP Splitting Smuggling
Để phòng chống HTTP Splitting Smuggling, bạn có thể thực hiện các biện pháp bảo mật sau:
- Cập nhật và sử dụng phiên bản mới nhất của các phần mềm và frameworks: Đảm bảo rằng bạn sử dụng phiên bản mới nhất của các phần mềm và frameworks trong ứng dụng web của mình. Các bản vá bảo mật thường được cung cấp để khắc phục các lỗ hổng có liên quan đến HTTP Splitting Smuggling.
- Kiểm tra và xử lý đầu vào đúng cách: Kiểm tra và xử lý đầu vào từ người dùng hoặc các nguồn bên ngoài một cách cẩn thận và đúng cách. Hạn chế hoặc loại bỏ các ký tự đặc biệt và dấu phân cách trong yêu cầu HTTP.
- Sử dụng bộ lọc đầu ra (output filtering): Áp dụng bộ lọc đầu ra để loại bỏ hoặc mã hóa các ký tự đặc biệt trong phản hồi HTTP trước khi nó được gửi đến người dùng. Điều này giúp ngăn chặn các cuộc tấn công XSS và các hình thức tấn công khác sử dụng HTTP Splitting Smuggling.
- Kiểm tra và cấu hình chính sách bảo mật HTTP: Kiểm tra và cấu hình chính sách bảo mật HTTP (HTTP Security Headers) cho ứng dụng web của bạn. Điều này bao gồm sử dụng các header như Strict-Transport-Security (HSTS), X-Content-Type-Options, X-XSS-Protection, và Content-Security-Policy để giới hạn các lỗ hổng bảo mật có thể bị khai thác.
- Áp dụng các biện pháp bảo vệ phía máy chủ: Thiết lập và cấu hình máy chủ web và bộ định tuyến một cách đúng cách để loại bỏ hoặc xử lý đúng cách các yêu cầu HTTP có chứa các ký tự đặc biệt và dấu phân cách.
- Cập nhật và bảo trì hệ thống: Đảm bảo rằng hệ thống và phần mềm của bạn được cập nhật thường xuyên và được bảo trì đúng cách. Điều này đảm bảo rằng các lỗ hổng bảo mật liên quan đến HTTP Splitting Smuggling được khắc phục và hạn chế nguy cơ tấn công.
- Đào tạo và nâng cao nhận thức bảo mật: Đào tạo nhân viên về các vấn đề bảo mật, bao gồm HTTP Splitting Smuggling và các hình thức tấn công khác. Nâng cao nhận thức về bảo mật sẽ giúp nhân viên nhận ra các mối nguy tiềm ẩn và có thể ngăn chặn các cuộc tấn công một cách hiệu quả.
Tuy nhiên, việc phòng chống HTTP Splitting Smuggling không chỉ dừng lại ở các biện pháp kỹ thuật, mà còn yêu cầu sự quan tâm và chủ động trong việc duy trì và cải thiện bảo mật ứng dụng web.
Xem thêm HTTP là gì?
Làm thế nào để kiểm tra
Mục tiêu kiểm tra
Đánh giá xem ứng dụng có dễ bị chia tách hay không, xác định những cuộc tấn công có thể xảy ra.
Đánh giá xem chuỗi thông tin liên lạc có dễ bị buôn lậu hay không, xác định xem có thể thực hiện được những cuộc tấn công nào không.
Blackbox testing
HTTP splitting
Một số ứng dụng web sử dụng một phần đầu vào của người dùng để tạo giá trị của một số tiêu đề trong phản hồi của họ. Ví dụ đơn giản nhất được cung cấp bởi chuyển hướng trong đó URL mục tiêu phụ thuộc vào một số giá trị do người dùng gửi. Ví dụ, giả sử người dùng được yêu cầu chọn xem họ thích giao diện web tiêu chuẩn hay nâng cao. Lựa chọn sẽ được chuyển dưới dạng một tham số sẽ được sử dụng trong tiêu đề phản hồi để kích hoạt chuyển hướng đến trang tương ứng.
Cụ thể hơn, nếu tham số ‘interface’ có giá trị ‘advanced’, ứng dụng sẽ trả lời như sau:
HTTP/1.1 302 Moved Temporarily Date: Sun, 03 Dec 2005 16:22:19 GMT Location: http://victim.com/main.jsp?interface=advanced <snip>
Khi nhận được thông báo này, trình duyệt sẽ đưa người dùng đến trang được chỉ định trong tiêu đề Vị trí. Tuy nhiên, nếu ứng dụng không lọc đầu vào của người dùng, có thể chèn vào tham số ‘giao diện’ chuỗi% 0d% 0a, đại diện cho chuỗi CRLF được sử dụng để phân tách các dòng khác nhau. Tại thời điểm này, người kiểm tra sẽ có thể kích hoạt một phản hồi sẽ được hiểu là hai phản hồi khác nhau bởi bất kỳ ai tình cờ phân tích cú pháp nó, ví dụ như một bộ đệm web nằm giữa chúng tôi và ứng dụng. Điều này có thể bị kẻ tấn công lợi dụng để đầu độc bộ nhớ cache web này để nó cung cấp nội dung sai trong tất cả các yêu cầu tiếp theo.
Giả sử trong ví dụ trước, người kiểm tra chuyển dữ liệu sau làm tham số giao diện:
advanced%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2035%0d%0a%0d%0a<html>Sorry,%20System%20Down</html>
Do đó, câu trả lời từ ứng dụng dễ bị tấn công sẽ như sau:
HTTP/1.1 302 Moved Temporarily Date: Sun, 03 Dec 2005 16:22:19 GMT Location: http://victim.com/main.jsp?interface=advanced Content-Length: 0 HTTP/1.1 200 OK Content-Type: text/html Content-Length: 35 <html>Sorry,%20System%20Down</html> <other data>
Bộ nhớ cache web sẽ thấy hai phản hồi khác nhau, vì vậy nếu kẻ tấn công gửi, ngay sau yêu cầu đầu tiên, yêu cầu thứ hai yêu cầu /index.html, bộ nhớ cache web sẽ khớp yêu cầu này với phản hồi thứ hai và lưu vào bộ nhớ cache nội dung của nó, để tất cả các yêu cầu tiếp theo được chuyển hướng đến nạn nhân.com/index.html đi qua bộ đệm web đó sẽ nhận được thông báo “hệ thống ngừng hoạt động”. Bằng cách này, kẻ tấn công sẽ có thể khử bề mặt trang web một cách hiệu quả đối với tất cả người dùng sử dụng bộ đệm ẩn web đó (toàn bộ Internet, nếu bộ đệm ẩn web là proxy ngược cho ứng dụng web).
Ngoài ra, kẻ tấn công có thể chuyển cho những người dùng đó một đoạn mã JavaScript gắn một cuộc tấn công tập lệnh trên nhiều trang web, ví dụ: để đánh cắp cookie. Lưu ý rằng mặc dù lỗ hổng bảo mật nằm trong ứng dụng, nhưng mục tiêu ở đây là người dùng của nó. Do đó, để tìm kiếm lỗ hổng này, người kiểm tra cần xác định tất cả đầu vào do người dùng kiểm soát có ảnh hưởng đến một hoặc nhiều tiêu đề trong phản hồi và kiểm tra xem họ có thể đưa chuỗi CR + LF vào đó thành công hay không.
Xem thêm Http package trong Go lang
Các tiêu đề có nhiều khả năng là ứng cử viên cho cuộc tấn công này là:
LocationSet-Cookie
Cần lưu ý rằng việc khai thác thành công lỗ hổng này trong một kịch bản thế giới thực có thể khá phức tạp, vì một số yếu tố phải được tính đến:
- Người kiểm tra bút phải đặt đúng tiêu đề trong phản hồi giả để nó được lưu vào bộ nhớ đệm thành công (ví dụ: tiêu đề Được sửa đổi lần cuối với ngày được đặt trong tương lai). Họ cũng có thể phải hủy các phiên bản đã lưu trong bộ nhớ cache trước đó của máy nhắn tin mục tiêu, bằng cách đưa ra yêu cầu sơ bộ với Pragma: no-cache trong tiêu đề yêu cầu
- Ứng dụng, trong khi không lọc chuỗi CR + LF, có thể lọc các ký tự cần thiết cho một cuộc tấn công thành công (ví dụ: <và>). Trong trường hợp này, người thử nghiệm có thể thử sử dụng các mã hóa khác (ví dụ: UTF-7)
- Một số mục tiêu (ví dụ: ASP) sẽ mã hóa URL phần đường dẫn của tiêu đề Vị trí (ví dụ: www.victim.com/redirect.asp), làm cho chuỗi CRLF trở nên vô dụng. Tuy nhiên, chúng không mã hóa được phần truy vấn (ví dụ:? Interface = advanced), có nghĩa là dấu chấm hỏi ở đầu là đủ để bỏ qua bộ lọc này
Để có thảo luận chi tiết hơn về cuộc tấn công này và thông tin khác về các kịch bản và ứng dụng có thể xảy ra, hãy kiểm tra các tài liệu tham khảo ở cuối phần này.
Gray Box testing
HTTP splitting
Việc khai thác thành công HTTP Splitting được giúp đỡ rất nhiều khi biết một số thông tin chi tiết về ứng dụng web và mục tiêu tấn công. Ví dụ: các mục tiêu khác nhau có thể sử dụng các phương pháp khác nhau để quyết định khi nào thông báo HTTP đầu tiên kết thúc và khi nào thông báo thứ hai bắt đầu. Một số sẽ sử dụng các ranh giới tin nhắn, như trong ví dụ trước. Các mục tiêu khác sẽ giả định rằng các thông điệp khác nhau sẽ được thực hiện bởi các gói tin khác nhau. Những người khác sẽ phân bổ cho mỗi tin nhắn một số đoạn có độ dài xác định trước: trong trường hợp này, tin nhắn thứ hai sẽ phải bắt đầu chính xác ở phần đầu của một đoạn và điều này sẽ yêu cầu người kiểm tra sử dụng đệm giữa hai tin nhắn. Điều này có thể gây ra một số rắc rối khi tham số dễ bị tấn công được gửi trong URL, vì một URL rất dài có thể bị cắt bớt hoặc bị lọc. Một tình huống hộp xám có thể giúp kẻ tấn công tìm ra cách giải quyết: ví dụ: một số máy chủ ứng dụng sẽ cho phép gửi yêu cầu bằng POST thay vì GET.
HTTP Smuggling
Như đã đề cập trong phần giới thiệu, HTTP Smuggling tận dụng các cách khác nhau mà một thông điệp HTTP được chế tạo đặc biệt có thể được phân tích cú pháp và diễn giải bởi các tác nhân khác nhau (trình duyệt, bộ đệm web, tường lửa ứng dụng). Kiểu tấn công tương đối mới này lần đầu tiên được phát hiện bởi Chaim Linhart, Amit Klein, Ronen Heled và Steve Orrin vào năm 2005. Có một số ứng dụng có thể xảy ra và chúng tôi sẽ phân tích một trong những cách ngoạn mục nhất: vượt tường lửa ứng dụng. Tham khảo whitepaper ban đầu (được liên kết ở cuối trang này) để biết thêm thông tin chi tiết và các tình huống khác.
Bỏ qua tường lửa ứng dụng
Có một số sản phẩm cho phép quản trị hệ thống phát hiện và chặn một yêu cầu web thù địch tùy thuộc vào một số mẫu độc hại đã biết được nhúng trong yêu cầu. Ví dụ: hãy xem xét cuộc tấn công truyền qua thư mục Unicode cũ, khét tiếng chống lại máy chủ IIS, trong đó kẻ tấn công có thể phá mã gốc www bằng cách đưa ra một yêu cầu như:
http: //target/scripts/..%c1%1c../winnt/system32/cmd.exe? / c + <command_to_execute>
Tất nhiên, khá dễ dàng để phát hiện và lọc cuộc tấn công này bởi sự hiện diện của các chuỗi như “..” và “cmd.exe” trong URL. Tuy nhiên, IIS 5.0 khá kén chọn các yêu cầu POST có nội dung lên đến 48K byte và cắt bớt tất cả nội dung vượt quá giới hạn này khi tiêu đề Content-Type khác với application / x-www-form-urlencoded. Người kiểm tra bút có thể tận dụng điều này bằng cách tạo ra một yêu cầu rất lớn, có cấu trúc như sau:
POST /target.asp HTTP/1.1 <-- Request #1 Host: target Connection: Keep-Alive Content-Length: 49225 <CRLF> <49152 bytes of garbage>
POST /target.asp HTTP/1.0 <-- Request #2 Connection: Keep-Alive Content-Length: 33 <CRLF>
POST /target.asp HTTP/1.0 <-- Request #3 xxxx: POST /scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0 <-- Request #4 Connection: Keep-Alive <CRLF>
Điều xảy ra ở đây là Yêu cầu số 1 được tạo bởi 49223 byte, bao gồm cả các dòng của Yêu cầu số 2. Do đó, tường lửa (hoặc bất kỳ tác nhân nào khác bên cạnh IIS 5.0) sẽ thấy Yêu cầu số 1, sẽ không thấy Yêu cầu số 2 (dữ liệu của nó sẽ chỉ là một phần của số 1), sẽ thấy Yêu cầu số 3 và bỏ lỡ Yêu cầu số 4 (vì POST sẽ chỉ là một phần của tiêu đề giả xxxx).
Bây giờ, điều gì sẽ xảy ra với IIS 5.0? Nó sẽ ngừng phân tích cú pháp Yêu cầu số 1 ngay sau 49152 byte rác (vì nó sẽ đạt đến giới hạn 48K = 49152 byte) và do đó sẽ phân tích cú pháp Yêu cầu số 2 như một yêu cầu mới, riêng biệt. Yêu cầu số 2 tuyên bố rằng nội dung của nó là 33 byte, bao gồm mọi thứ cho đến “xxxx:”, khiến IIS bỏ lỡ Yêu cầu số 3 (được hiểu là một phần của Yêu cầu số 2) nhưng lại phát hiện Yêu cầu số 4, vì BÀI ĐĂNG của nó bắt đầu ngay sau byte thứ 33 hoặc Yêu cầu số 2. Nó hơi phức tạp một chút, nhưng điểm mấu chốt là URL tấn công sẽ không bị tường lửa phát hiện (nó sẽ được hiểu là phần thân của một yêu cầu trước đó) nhưng sẽ được phân tích cú pháp chính xác (và thực thi) bởi IIS.
Trong trường hợp nói trên, kỹ thuật này khai thác một lỗi của máy chủ web, có những tình huống khác mà chúng ta có thể tận dụng các cách khác nhau mà các thiết bị hỗ trợ HTTP khác nhau phân tích cú pháp các thông báo không tuân thủ 1005 RFC. Ví dụ: giao thức HTTP chỉ cho phép một tiêu đề Độ dài Nội dung, nhưng không chỉ định cách xử lý một thông báo có hai phiên bản của tiêu đề này. Một số triển khai sẽ sử dụng cái đầu tiên trong khi những cái khác sẽ thích cái thứ hai, ở đường cho các cuộc tấn công HTTP Smuggling. Một ví dụ khác là việc sử dụng tiêu đề Độ dài Nội dung trong thông báo GET.
Lưu ý rằng HTTP Smuggling * không * khai thác bất kỳ lỗ hổng nào trong ứng dụng web mục tiêu. Do đó, có thể hơi phức tạp, trong một cuộc thử nghiệm bằng bút, để thuyết phục khách hàng rằng dù thế nào cũng nên tìm kiếm một biện pháp đối phó.
