🔐Web cache poisoning
request = yêu cầu; response = phản hồi
Last updated
request = yêu cầu; response = phản hồi
Last updated
Web cache poisoning là một kỹ thuật tấn công mà kẻ tấn công cố gắng thay đổi hoặc làm ô nhiễm dữ liệu được lưu trữ trong bộ nhớ cache của một máy chủ proxy hoặc máy chủ trung gian trên mạng. Bằng cách tận dụng các lỗ hổng trong việc xử lý cache hoặc các lỗ hổng bảo mật khác, kẻ tấn công có thể chèn hoặc thay đổi các nội dung độc hại, đánh lừa người dùng hoặc khai thác các lỗ hổng khác trên ứng dụng web.
Nếu một máy chủ phải gửi một phản hồi mới cho mỗi yêu cầu HTTP riêng biệt, điều này có thể làm quá tải máy chủ, gây ra vấn đề độ trễ và trải nghiệm người dùng kém chất lượng, đặc biệt là trong những khoảng thời gian đông đúc. Caching chủ yếu là một phương pháp để giảm thiểu các vấn đề đó.
Bộ nhớ cache đặt giữa máy chủ và người dùng, nơi nó lưu trữ (cache) các phản hồi cho các yêu cầu cụ thể, thường là trong một khoảng thời gian cố định. Nếu một người dùng khác sau đó gửi một yêu cầu tương tự, bộ nhớ cache đơn giản chỉ cần phục vụ một bản sao của phản hồi đã được lưu trong bộ nhớ cache trực tiếp cho người dùng, mà không cần tương tác từ phía máy chủ. Điều này giảm tải đáng kể lên máy chủ bằng cách giảm số lượng yêu cầu trùng lặp mà máy chủ phải xử lý.
Cache key: Khi bộ nhớ cache nhận được một yêu cầu HTTP, trước tiên nó phải xác định xem có phản hồi đã được lưu trong bộ nhớ cache mà nó có thể phục vụ trực tiếp, hay nó có phải chuyển tiếp yêu cầu để xử lý bởi máy chủ phía sau. Bộ nhớ cache xác định các yêu cầu tương đương bằng cách so sánh một tập hợp con được xác định trước của các thành phần yêu cầu, được gọi chung là "cache key". Thông thường, điều này sẽ bao gồm dòng yêu cầu và tiêu đề Host. Những thành phần của yêu cầu không được bao gồm trong cache key được gọi là "unkeyed".
Nếu cache key của yêu cầu đến khớp với cache key của một yêu cầu trước đó, thì bộ nhớ cache coi chúng là tương đương. Kết quả là, nó sẽ phục vụ một bản sao của phản hồi đã được lưu trong bộ nhớ cache được tạo ra cho yêu cầu ban đầu. Điều này áp dụng cho tất cả các yêu cầu tiếp theo có cùng cache key khớp, cho đến khi phản hồi trong bộ nhớ cache hết hạn.
Đáng chú ý, các thành phần khác của yêu cầu hoàn toàn bị bỏ qua bởi bộ nhớ cache. Chúng ta sẽ tìm hiểu tác động của hành vi này chi tiết hơn sau.
Tác động của một cuộc tấn công web cache poisoning phụ thuộc rất nhiều vào hai yếu tố quan trọng:
Nội dung mà kẻ tấn công thành công lưu vào cache Vì cache bị nhiễm độc chủ yếu là một phương tiện phân phối chứ không phải một cuộc tấn công độc lập, tác động của web cache poisoning liên quan chặt chẽ đến mức độ nguy hiểm của nội dung được tiêm vào. Giống như hầu hết các loại cuộc tấn công khác, web cache poisoning cũng có thể được sử dụng kết hợp với các cuộc tấn công khác để tăng thêm tác động tiềm năng.
Lượng lưu lượng truy cập trên trang bị ảnh hưởng Phản hồi bị nhiễm độc chỉ được phục vụ cho người dùng truy cập trang bị ảnh hưởng trong khi cache bị nhiễm độc. Kết quả là, tác động có thể không tồn tại hoặc lớn đến mức tùy thuộc vào trang có phổ biến hay không. Ví dụ, nếu kẻ tấn công thành công nhiễm độc một phản hồi trong cache trên trang chủ của một trang web lớn, cuộc tấn công có thể ảnh hưởng đến hàng ngàn người dùng mà không có sự tương tác tiếp theo từ kẻ tấn công.
Lưu ý rằng thời hạn của một mục trong cache không nhất thiết ảnh hưởng đến tác động của web cache poisoning. Một cuộc tấn công thường có thể được viết script để nhiễm độc lại cache một cách vô thời hạn.
Có thể nói rằng lỗ hổng web cache poisoning dễ khai thác nhất là khi đầu vào không được unkeyed và được reflect trong phản hồi có thể được lưu vào cache mà không được filter.
Ví dụ: Xem xét request và response sau
Ở đây, giá trị của tiêu đề X-Forwarded-Host được sử dụng để tạo động một URL hình ảnh Open Graph, sau đó được phản ánh trong phản hồi. Quan trọng đối với web cache poisoning, tiêu đề X-Forwarded-Host thường không được check giá trị nên khi này chúng ta có thể tạo một con server chứa mã độc XSS để khai thác.
"X-Forwarded-Host" là một tiêu đề HTTP được sử dụng để chỉ định host gốc khi một yêu cầu HTTP được chuyển tiếp qua các máy chủ trung gian, chẳng hạn như một proxy hoặc load balancer. Khi yêu cầu đi qua các máy chủ trung gian này, tiêu đề "X-Forwarded-Host" được thêm vào yêu cầu để xác định host gốc ban đầu mà yêu cầu được gửi đến.
Qua một vòng xem xét thì thấy rằng response như này:
Vậy khi chúng ta thêm một header: X-Forwarded-Host thì sẽ như thế nào:
X-Forwarded-Host: hacker.com : X-Forward-Host là một trường tiêu đề HTTP được sử dụng trong các yêu cầu HTTP để xác định tên miền hoặc địa chỉ IP của máy chủ gốc mà yêu cầu ban đầu đã được gửi đến trước khi đi qua các proxy hoặc load balancer.
Khi đó source link trong JS, nó được forward tới domain chúng ta forward tới thông qua thêm header X-Forwarded-Host. Bây giờ để solve bài này cần tạo một server chứa mã độc XSS, sau đó bỏ và giá trị của X-Forwarded-Host header.
Chúng ta chú ý một giá trị của cookie trả về trong response, vậy lúc này chúng ta sẽ nhúng một mã độc XSS vào, "-alert(1)-"
Nhìn vào tiêu đề lab này chúng ta cần thêm 2 header nào đó để có thể alert cookie ra. Đầu tiên chúng ta sẽ thử X-Forwarded-Scheme xem nó có chuyển từ https -> http hay không?
X-Forwarded-Scheme là một tiêu đề HTTP được sử dụng để xác định giao thức (scheme) của trang web gốc khi đi qua các proxy hoặc máy chủ trung gian.
Khi một yêu cầu HTTP đi qua một proxy hoặc máy chủ trung gian, thông tin về giao thức ban đầu (HTTP hoặc HTTPS) thường bị mất đi. Điều này có thể làm cho các ứng dụng web có khả năng hoạt động không chính xác nếu chúng cần biết giao thức đúng của trang web gốc.
Thêm một điều nữa, sau một lúc check thì chúng ta có một đường path như sau và trả về JS chuyển qua Repeater.
Ở đây chúng ta sử dụng header trên để bắt nó chuyển qua http nhưng không thấy gì thay đổi, như tiêu đều thì yêu cầu 2 header.
Vậy ở đây, chúng ta sẽ thêm lại X-Forwarded-Host xem như nào, hãy chú ý phần Location của res trả về:
Thấy rằng request sẽ được lưu vào cache sau đó request tiếp theo tới đã bị chuyển hướng tới theo url của header X-Forwarded-Host mà chúng ta chèn vào, chúng ta build một server chứa mã độc mà khai thác giống lab 2.
Đối với lab này chúng ta sẽ không biết được header nào có thể nhúng được vào source code web khi nó load trang, bơi vậy chúng ta sẽ dùng tool Param Miner sẽ hỗ trợ chúng ta đoán header đó.
Như trên hình sau một lúc nhấn Guess headers thì nó trả về cho chúng ta một vài Secret input: headers
Có một x-host header mà chúng ta tìm ra được và bây giờ sẽ thêm nó vào xem chuyện gì xảy ra với response.
