"진짜" 클라이언트 IP의 위험성
(adam-p.ca)요약
- X-Forwarded-For 헤더에서 "Real Client IP" 를 가져올때 가장 오른쪽 IP를 사용할 것
- XFF 헤더에서 가장 왼쪽 IP는 보통 "클라이언트에 가장 가까운" "거의 진짜"인것으로 간주되지만 속이는게 가능(spoofable). 보안과 관련된 어떤 것에도 사용하지 말 것
- 가장 오른쪽 XFF IP를 선택할때, 해당 헤더의 마지막 인스턴스를 사용해야 함
- 리버스 프록시가 설정한 "True Client IP" 값들(X-REal-IP, True-Client-IP 등)도 좋긴 하지만
- 리버스 프록시가 그값을 어떻게 지정하는가에 따라 다르고
- 리버스 프록시 자체가 이미 속았는지도 모르고(Spoofed)
- 리버스 프록시의 설정이 어떻게 되었는지에 따라 다름
- 리버스 프록시가 특별히 설정하지 않은 헤더는 신뢰할 수 없음
- 예를 들어 , Nginx 뒤에 있지 않거나 항상 (헤더를) 설정하도록 되어 있지 않다면 X-Real-IP헤더를 읽어선 안됨. 스푸핑 된 값을 읽을 수도 있기 때문
- 많은 Rate Limiter 구현이 스푸핑 가능한 IP를 사용하고 있으며, 레이트 리미팅 피하기 및 메모리 고갈 공격에 취약함
- 코드나 인프라에서 "real client ip" 관련한 것을 사용하고 있다면 뒤에 이어지는 기술적 내용을 참고할 것
상세 (길어서 제목만 옮깁니다)
- 소개 : 요즘 "real client ip"를 알아내는 것은 끔찍함
- 함정들
- 헤더는 신뢰할 수 없음
- 여러개의 헤더
- Private IP
- IP Splitting
- 암호화되지 않은 데이터는 항상 신뢰할 수 없음
- X-Client-IP, True-Client-IP 같은 것은 스푸핑 가능
- X-Forwareded-For 에 대해 알기
- 함정 피하기
- 진짜 IP를 구하기 위한 알고리듬
- 모든 IP값들을 가져와
- 보안에 따라 어떤걸 사용할지 선택
- 가장 왼쪽, 가장 오른쪽
- 진짜 IP를 구하기 위한 알고리듬
- 실전 예제들
- Cloudflare, Nginx, Apache
- Akamai
- Fastly
- Azure
- go-chi/chi
- didip/tollbooth
- ulule/limiter
- sethvargo/go-limiter
- Let's Encrypt
- Express
- Traefik
- phpList
- IIS
- Tor
- 고급 : 이론적 함정과 공격 방법들
- RFC 7239: Forwarded HTTP Extension, June 2014
예를 들어 Nginx 뒤에 있거나, 특별히 항상 지정하지 않는다면 X-Real-IP헤더를 읽어선 안됨. 스푸핑 된 값을 읽을수도 있기 때문
이 부분은 살짝 오역인 것 같습니다. 원문은 이렇습니다.
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.
예를 들어서, Nginx 뒤에 있지 않거나 항상 (헤더를) 설정하도록 되어 있지 않다면 X-Real-IP 헤더를 읽어서는 안 된다. 스푸핑 된 값을 읽게 되기 때문.
일반적인 방법으로는 TRUSTED_PROXY 환경변수를 이용하여 가장 오른쪽부터 "믿을 수 있는" 프록시를 하나씩 제외하다가 처음 나오는 IP를 사용하긴 합니다.
보통 내부 아이피(192.168.0.0/16) 등을 믿을 수 있는 프록시로 취급하기도 하구요