เพียร์ซ็อกเก็ตหรือเฮดเดอร์ที่ส่งต่อ: จะเชื่อถือที่อยู่ใด?

คำขอที่มาถึงแอปพลิเคชันของคุณมีหลักฐานเกี่ยวกับที่อยู่สองชนิด คือเพียร์ที่เปิดการเชื่อมต่อเครือข่าย และฟิลด์ HTTP ที่อ้างว่าที่อยู่ของไคลเอนต์ก่อนหน้า ทั้งสองตอบคำถามต่างกัน เพียร์ซ็อกเก็ตนั้นถูกสังเกต ส่วนเฮดเดอร์นั้นเป็นการอ้างของใครก็ตามที่เขียนมัน และไม่ควรมีอันใดแทนที่อีกอันอย่างเงียบ ๆ ในล็อกหรือกฎการเข้าถึง การเปรียบเทียบด้านล่างแยกทั้งสองออกจากกัน แล้วแสดงรูปแบบเดียวที่ทำให้เฮดเดอร์ใช้งานได้

อธิบายเส้นทางก่อนจะเปรียบเทียบอะไร:

Client -> approved reverse proxy -> application origin

ในรูปแบบนั้น เพียร์ซ็อกเก็ตของต้นทางมักเป็นพร็อกซี และเฮดเดอร์ส่งต่ออาจพาข้ออ้างของพร็อกซีเกี่ยวกับไคลเอนต์ คุณค่าของมันมาจากความสัมพันธ์ที่ควบคุมได้กับพร็อกซีนั้น ไม่ใช่จากชื่อของเฮดเดอร์

หลักฐานเกี่ยวกับที่อยู่สองชนิด

เพียร์ซ็อกเก็ตเป็นข้อเท็จจริงเกี่ยวกับการเชื่อมต่อ TCP หนึ่งครั้ง คือมีบางอย่างจับมือเสร็จสิ้นจากที่อยู่นั้น มันไม่จำเป็นต้องเป็นคน อุปกรณ์ หรือบัญชีที่คุณใส่ใจ เพราะ VPN หรือทางออก Tor อาจเป็นแหล่งที่บริการสังเกตได้โดยชอบธรรม กระนั้นก็ยังเป็นที่อยู่เดียวที่โฮสต์เองตรวจสอบแล้ว และนั่นคือคุณค่าทั้งหมดของมัน

ฟิลด์ส่งต่อเป็นเมทาดาทาเกี่ยวกับห่วงโซ่ X-Forwarded-For, X-Real-IP และฟิลด์มาตรฐาน Forwarded เขียนได้โดยไคลเอนต์ใดก็ตามที่ไปถึงปลายทางซึ่งสะท้อนมันกลับมา ความน่าเชื่อถือจึงขึ้นอยู่กับว่าใครได้รับอนุญาตให้ตั้งค่าโดยสิ้นเชิง

เก็บทั้งสองไว้ในบริบทของคำขอภายใต้ชื่อที่แยกจากกัน แอปพลิเคชันที่เขียนทับเพียร์ด้วยเฮดเดอร์จะสูญเสียความสามารถในการสร้างข้อผิดพลาดด้านความเชื่อถือขึ้นใหม่ในภายหลัง และนั่นคือจังหวะที่คุณต้องการมันพอดี

เฮดเดอร์ไม่เคยเปลี่ยนเส้นทางการเชื่อมต่อ

การเขียนที่อยู่ลงในฟิลด์ส่งต่อไม่เปลี่ยนแหล่งของการเชื่อมต่อ TCP ที่มาถึงเซิร์ฟเวอร์ และไม่เปลี่ยนเส้นทางใด ๆ ตลอดเส้นทาง การกำหนดเส้นทาง VPN ทั่วไปหรือ NAT ต้นทาง ส่งข้อมูลโดยไม่มีเฮดเดอร์ HTTP เลย เช่นเดียวกัน เกตเวย์ส่งผ่านไม่เขียนการแลกเปลี่ยน HTTPS ที่ป้องกันอย่างถูกต้องใหม่โดยไม่เปลี่ยนรูปแบบปลายทาง TLS

ข้อผิดพลาดตรงข้ามก็พบได้บ่อยพอ ๆ กัน คือ HTTPS ไม่ได้ทำให้เฮดเดอร์ส่งต่อที่ไคลเอนต์ให้มาเป็นความจริง มันปกป้องการขนส่งข้ออ้างเท็จได้ดีเท่ากับข้ออ้างจริง

ถ้าเพื่อนร่วมงานเสนอให้เปลี่ยนเฮดเดอร์เพื่อแก้ปัญหาการกำหนดเส้นทาง แสดงว่าการวินิจฉัยผิดไปแล้ว จงแก้เส้นทาง หรือแก้การตั้งค่าพร็อกซีที่เขียนเฮดเดอร์

ระบุชื่อพร็อกซีที่ได้รับอนุญาตให้อ้างได้

กฎสองข้อทำให้ฟิลด์ส่งต่อใช้งานได้ และทั้งสองเป็นคอนฟิกูเรชันไม่ใช่โค้ด ขอบจะทำให้ทุกอย่างที่มาจากภายนอกเป็นปกติหรือทิ้งไป ตามพฤติกรรมที่เอกสารระบุไว้สำหรับฟิลด์เหล่านั้น จากนั้นต้นทางจะรับที่อยู่ทดแทนจากเส้นทางพร็อกซีที่คุณระบุชื่อและจากที่อื่นไม่ได้ กฎข้อที่สองใช้ได้เพียงตราบเท่าที่ไคลเอนต์ไม่สามารถเข้าถึงต้นทางด้วยวิธีอื่น เพราะต้นทางที่ตอบทั้งคำขอตรงและคำขอผ่านพร็อกซีไม่รู้ว่าตนให้บริการอันไหน

โมดูล IP จริงของ NGINX แสดงการแยกกันอย่างชัดเจน set_real_ip_from ระบุชื่อผู้ส่งที่ข้ออ้างของพวกเขาถูกนับ และ real_ip_header บอกว่าฟิลด์ใดพามันไป อันแรกทำหน้าที่เชื่อถือ อันที่สองเพียงบอกว่าควรมองที่ไหน

set_real_ip_from 10.20.0.0/24;
real_ip_header X-Forwarded-For;
# real_ip_recursive off - take the rightmost value in the field
# real_ip_recursive on  - walk the list back past every trusted address

คำสั่งเลือกเฮดเดอร์เพียงอย่างเดียวยังไม่ได้กำหนดอะไรเกี่ยวกับใครเป็นผู้ส่งค่า

ความปลอดภัยของการขนส่งต้องทำงานตลอดเส้นทางระหว่างองค์ประกอบที่คุณเชื่อถือ ขอบที่ทำให้เป็นปกติอย่างถูกต้องจะสูญเสียคุณค่านั้นในวินาทีที่ hop ที่ไม่มีการป้องกันทางปลายทางเปิดให้คนอื่นแก้ไขข้ออ้างระหว่างเดินทาง

จัดการห่วงโซ่หลาย hop อย่างตั้งใจ

พร็อกซีหลายตัวต้องมีรูปแบบห่วงโซ่ที่ชัดเจน อย่าเอาค่าที่แยกด้วยจุลภาคซ้ายสุดหรือขวาสุดเพียงเพราะบทความบล็อกบทความหนึ่งทำเช่นนั้น จงค้นหาว่าพร็อกซีใดของคุณเพิ่มค่า ตัวใดแทนที่ และตัวใดเก็บฟิลด์ขาเข้าไว้ ตัวอย่างเช่น NGINX สามารถไล่รายการย้อนกลับเทียบกับชุดที่เชื่อถือได้และหยุดที่ที่อยู่แรกที่ตนไม่ได้เป็นเจ้าของ และนั่นคือกฎของผลิตภัณฑ์นั้น ไม่ใช่กฎหมายที่ทุกเฟรมเวิร์กทำตาม อ่านเอกสารของพร็อกซีคุณเองด้วยคำถามสองข้อเดิม คือมันเลือกค่าใด และเชื่อผู้ส่งคนใด

เขียนห่วงโซ่ลงไป คือลำดับ hop, hop ใดกำหนดฟิลด์ และ hop ใดลบสำเนาขาเข้า จากนั้นเก็บโน้ตนั้นไว้ข้างคอนฟิกูเรชันพร็อกซี ไม่ใช่แค่ในตั๋ว แล้วทดสอบโดยส่งคำขอที่มีเฮดเดอร์ปลอมผ่านกระบวนการตรวจสอบที่ได้รับอนุมัติ และยืนยันว่าต้นทางไม่สนใจมัน

เมื่อคุณเพิ่ม hop ให้ทบทวนเอกสารนั้น ตัวกระจายโหลดใหม่ที่แทรกไว้หน้าพร็อกซีที่เชื่อถือได้อาจเปลี่ยนที่อยู่ที่ชนะโดยไม่มีใครแก้ไขแอปพลิเคชัน

เก็บการสังเกตทั้งสองไว้ในล็อก

ในที่ที่อนุญาตให้วินิจฉัย ให้บันทึกเพียร์ของการเชื่อมต่อและที่อยู่ไคลเอนต์ที่ทำให้เป็นปกติเป็นสองฟิลด์แยกกัน และเพิ่มเมทาดาทาการส่งต่อที่วัตถุประสงค์ต้องการจริง ๆ เท่านั้น จากนั้นพิสูจน์การติดตั้งด้วยคำขอสองรายการ คือรายการที่ผ่านพร็อกซีซึ่งควรบันทึกทั้งสองค่าอย่างสมเหตุสมผล และความพยายามตรงไปยังต้นทางซึ่งต้องถูกปฏิเสธ

จำไว้ว่าคู่นี้หมายถึงอะไร เฮดเดอร์เพิ่มบริบทที่องค์ประกอบซึ่งคุณเลือกเชื่อถือจัดหาให้ ส่วนเพียร์ยังคงเป็นที่อยู่เดียวที่โฮสต์ของคุณเห็นจริง ไม่มีอันใดเป็นข้อพิสูจน์ตัวตนของบุคคล และการออกแบบที่ถืออันใดเป็นข้อพิสูจน์จะผิดเกี่ยวกับใครบางคน