सारांश
- X-Forwarded-For header से "Real Client IP" लेते समय सबसे दाईं ओर वाला IP इस्तेमाल करें
- XFF header में सबसे बाईं ओर का IP आमतौर पर "क्लाइंट के सबसे करीब" और "लगभग असली" माना जाता है, लेकिन इसे spoof किया जा सकता है. इसे किसी भी security-संबंधित काम में इस्तेमाल न करें
- सबसे दाईं ओर का XFF IP चुनते समय, उस header की आखिरी instance का उपयोग करना चाहिए
- reverse proxy द्वारा सेट किए गए "True Client IP" मान (X-Real-IP, True-Client-IP आदि) उपयोगी हो सकते हैं, लेकिन
- reverse proxy उस मान को कैसे सेट करता है, इस पर निर्भर करता है
- यह भी संभव है कि reverse proxy खुद ही spoof हुआ हो
- reverse proxy की configuration कैसी है, इस पर भी निर्भर करता है
- reverse proxy द्वारा खास तौर पर सेट न किए गए header भरोसेमंद नहीं हैं
- उदाहरण के लिए, अगर यह Nginx के पीछे नहीं है या हमेशा header सेट करने के लिए configured नहीं है, तो X-Real-IP header नहीं पढ़ना चाहिए. वरना spoof किया गया मान पढ़ा जा सकता है
- कई Rate Limiter implementations spoof किए जा सकने वाले IP का उपयोग करती हैं, इसलिए वे rate limiting से बच निकलने और memory exhaustion attacks के प्रति संवेदनशील हैं
- अगर आपके code या infrastructure में "real client ip" से जुड़ी किसी चीज़ का उपयोग हो रहा है, तो आगे दिए गए technical विवरण देखें
विवरण (लंबा होने के कारण केवल शीर्षक अनुवादित हैं)
- परिचय : आजकल "real client ip" पता लगाना बहुत कठिन है
- जाल
- headers पर भरोसा नहीं किया जा सकता
- कई headers
- private IP
- IP splitting
- unencrypted data पर कभी भरोसा नहीं किया जा सकता
- X-Client-IP, True-Client-IP जैसी चीज़ें spoof की जा सकती हैं
- X-Forwarded-For को समझना
- जाल से बचना
- असली IP निकालने का algorithm
- सभी IP मान इकट्ठा करो
- security की ज़रूरत के अनुसार तय करो कि कौन सा इस्तेमाल करना है
- सबसे बायाँ, सबसे दायाँ
- वास्तविक उदाहरण
- 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
3 टिप्पणियां
मुझे लगता है कि इस हिस्से में हल्का-सा गलत अनुवाद है। मूल पाठ यह है।
उदाहरण के लिए, यदि आप Nginx के पीछे नहीं हैं, या ऐसा नहीं है कि इसे हमेशा (हेडर को) सेट किया जाता हो, तो आपको X-Real-IP हेडर नहीं पढ़ना चाहिए। क्योंकि तब आप spoofed वैल्यू पढ़ रहे होंगे.
आह, मैं इसे ठीक कर दूँगा। धन्यवाद!
आम तौर पर
TRUSTED_PROXYenvironment variable का इस्तेमाल करके सबसे दाईं ओर से "विश्वसनीय" proxy को एक-एक करके हटाया जाता है, और फिर सबसे पहले मिलने वाले IP का उपयोग किया जाता है.आमतौर पर internal IP (192.168.0.0/16) आदि को भी विश्वसनीय proxy माना जाता है.