21 điểm bởi xguru 2022-03-07 | 3 bình luận | Chia sẻ qua WhatsApp

Tóm tắt

  • Khi lấy "Real Client IP" từ header X-Forwarded-For, hãy dùng địa chỉ IP ở ngoài cùng bên phải
  • IP ở ngoài cùng bên trái trong header XFF thường được xem là địa chỉ "gần client nhất", tức "gần như thật", nhưng có thể bị giả mạo (spoofable). Không dùng nó cho bất kỳ mục đích nào liên quan đến bảo mật
  • Khi chọn IP XFF ngoài cùng bên phải, phải dùng instance cuối cùng của header đó
  • Các giá trị "True Client IP" do reverse proxy thiết lập (X-Real-IP, True-Client-IP, v.v.) cũng hữu ích, nhưng
    • còn tùy reverse proxy thiết lập giá trị đó như thế nào
    • cũng không biết liệu bản thân reverse proxy đã bị đánh lừa (spoofed) hay chưa
    • và còn phụ thuộc vào cách reverse proxy được cấu hình
  • Không thể tin cậy các header mà reverse proxy không được cấu hình đặc biệt để thiết lập
    • Ví dụ, nếu không ở sau Nginx hoặc không được cấu hình để luôn thiết lập header thì không nên đọc header X-Real-IP. Vì có thể bạn đang đọc một giá trị đã bị giả mạo
  • Nhiều cách triển khai rate limiter đang dùng IP có thể bị giả mạo, nên dễ bị né tránh rate limiting và tấn công làm cạn kiệt bộ nhớ
  • Nếu bạn đang dùng thứ gì đó liên quan đến "real client ip" trong code hoặc hạ tầng, hãy tham khảo phần nội dung kỹ thuật bên dưới

Chi tiết (vì quá dài nên chỉ chuyển tiêu đề)

  • Giới thiệu: ngày nay việc xác định "real client ip" là một việc kinh khủng
  • Các bẫy
    • Không thể tin cậy header
    • Nhiều header
    • IP riêng tư
    • Tách IP
    • Dữ liệu không được mã hóa thì luôn không đáng tin
    • Các header như X-Client-IP, True-Client-IP có thể bị giả mạo
    • Hiểu về X-Forwarded-For
  • Cách tránh bẫy
    • Thuật toán để lấy IP thật
      • Lấy tất cả các giá trị IP
      • Chọn dùng giá trị nào tùy theo yêu cầu bảo mật
      • Bên trái nhất, bên phải nhất
  • Các ví dụ thực tế
    • Cloudflare, Nginx, Apache
    • Akamai
    • Fastly
    • Azure
    • go-chi/chi
    • didip/tollbooth
    • ulule/limiter
    • sethvargo/go-limiter
    • Let's Encrypt
    • Express
    • Traefik
    • phpList
    • IIS
    • Tor
  • Nâng cao: các bẫy mang tính lý thuyết và phương pháp tấn công
  • RFC 7239: Forwarded HTTP Extension, June 2014

3 bình luận

 
tribela 2022-03-08

Ví dụ, nếu ở sau Nginx hoặc nếu không được thiết lập để luôn chỉ định một cách đặc biệt thì không nên đọc header X-Real-IP. Vì có thể sẽ đọc phải giá trị bị giả mạo.

Đoạn này có vẻ là dịch hơi sai. Nguyên văn là như sau.

For example, you must not check the X-Real-IP header if you’re not behind Nginx or something else that always sets it, because you’ll be reading a spoofed value.

Ví dụ, nếu không ở sau Nginx hoặc không được cấu hình để luôn đặt (header) này, thì không được đọc header X-Real-IP. Vì sẽ đọc phải giá trị bị giả mạo.

 
xguru 2022-03-08

À, tôi sẽ sửa lại. Cảm ơn!

 
tribela 2022-03-08

Theo cách thông thường, người ta dùng biến môi trường TRUSTED_PROXY để lần lượt loại bỏ từng proxy "đáng tin cậy" từ bên phải sang, rồi sử dụng IP xuất hiện đầu tiên.
Thông thường, IP nội bộ (192.168.0.0/16) v.v. cũng được xem là proxy đáng tin cậy.