"Bẻ cong" logic phân tích URL: Tấn công Web Cache Deception qua kỹ thuật Delimiter Discrepancy
Ý kiến
0
Chưa có ý kiến nào. Hãy là người đầu tiên chia sẻ!
Chưa có ý kiến nào. Hãy là người đầu tiên chia sẻ!
Lỗ hổng Delimiter Decoding Discrepancies xảy ra khi có sự bất đồng bộ giữa máy chủ Cache (như Nginx, Varnish) và máy chủ gốc (Origin Server như PHP, Python, Java) trong cahsc phân tích và giải mã các ký tự phân cách (delimiters) trong URL.
Máy chủ Cache (Cache Server): Thường tuân thủ nghiêm ngặt các quy tắc cache dựa trên đường dẫn tĩnh (được mã hóa). Nó có thể không thực hiện giải mã (Decode) URL trước khi áp dụng các quy tắc cache.
Máy chủ gốc (Origin Server): Thực hiện giải mã URL (URL Decoding) trước khi xử lý logic nghiệp vụ. Nếu một ký tự phân cách (như #, ;, ?) bị giải mã, máy chủ gốc có thể hiểu sai đường dẫn thực tế, dẫn đến việc cắt ngắn (truncate) đường dẫn hoặc trả về dữ liệu động (nhạy cảm) thay vì tệp tĩnh.
Giả sử ứng dụng web có quy tắc cache cho các tệp tĩnh như .css hoặc .js. Kẻ tấn công sẽ lợi dụng sự khác biệt trong việc giải mã để lừa cache lưu lại dữ liệu nhạy cảm dưới tệp tĩnh.
Payload mẫu: /profile.php%23wcd.css
Tại máy chủ Cache: Không giải mã %23. Nó thấy đuôi .css nên áp dụng luật “Cache tất cả tệp .css”. Nó lưu trữ phản hồi từ tệp này vào bộ nhớ đệm.
Tại máy chủ gốc (Origin Server): Giải mã%23 thành #. Theo chuẩn URL, # là một delimiter, máy chủ gốc cắt ngắn đường dẫn thành/profile.php. Nó thực thi logic của trang profile và trả về dữ liẹu cá nhân ngời dùng.
Bắt request: Sử dụng Burp Suite để chặn gói tin truy cập vào một trang có dữ liệu nhạy cảm (VD: /myaccount).
Chèn Payload: Chuyển request sang tap Repeater, thay đổi URL thành payload chứa delimiter đã được mã hóa (VD: /myaccount%3fwcd.css).
Phân tích phản hồi:
Gửi request và quan sát Header X-Cache. Nếu là MISS, hãy gửi lại lần thứ hai.
Nếu Header chuyển thành HIT, hệ thống đã bị lừa lưu trữ phản hồi nhạy cảm vào Cache.
Khai thác (Bypass Auth): Xóa tất cả các thông tin định danh (Cookie/Authorization) trong request và gửi lại. Nếu máy chủ trả về dữ liệu nhạy cảm (Đã được lưu cache), lỗ hổng đã được khai thác thành công.
Sự tồn tại của lỗ hổng này đến từ ba yếu tố chính:
Giải mã khác biệt (Decoding Discrepancies): Máy chủ gốc giải mã ký tự đặc biệt (VD: %23 thành #) rồi cắt chuỗi, trong khi Cache giữ nguyên và áp dụng quy tắc lưu tệp tĩnh.
Thứ tự xử lý (Processing Order): Cache áp dụng luật trên URL thô (chưa giải mã), sau đó mới chuyển tiếp yêu cầu, tạo ra khoảng trống cho kẻ tấn công thao túng logic.
Chuẩn hóa (Normalization): Mỗi hệ thống có cách chuẩn hóa ký tự lùi mục (VD: ..%2f) khác nhau, khiến Cache và Origin Server nhìn nhận “Cùng một địa chỉ” theo hai cách hoàn toàn đối lập.
Việc vá lỗ hổng này đòi hỏi sự đồng bộ giữa các lớp bảo mật:
Đồng bộ hóa Parsing: Đảm bảo cả Cache Server và Origin Server sử dụng chung một thư viện chuẩn hóa (Normalization) và giải mã URL. Không được để tồn tại sự khác biệt giữa hai lớp này.
Cache theo đường dẫn, không theo đuôi tệp: Thay vì tin tưởng và đuôi tệp (.css, .js), hãy cấu hình cache dựa trên các đường dẫn cố định (VD: /static/, /assets/).
Chính sách "No-Cache" mặc định: Mọi API trả về dữ liệu người dùng (dữ liệu động) phải luôn đi kèm với Header: Cache-Control: private, no-store, no-cache, must-revalidate
Nguyên tắc "Không khoan nhượng" tại Origin: Nếu URL chứa các ký tự phân cách bất thường hoặc mã hóa không hợp lệ, Origin Server phải trả ngay mã lỗi 400 Bad Request. Tuyệt đối không tự ý "chữa lỗi" hoặc cắt gọt URL hộ người dùng.