ลิงก์รายการไอพีที่อนุญาตชั่วคราว: สิ่งที่การอนุญาตยอมรับจริง ๆ

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

ตัดสินว่าการอนุญาตตอบคำถามใด

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

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

จำกัดคำขอที่เซิร์ฟเวอร์

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

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

แสดงการอนุญาตก่อนติดตั้ง

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

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

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

ที่อยู่ถูกใช้ร่วมกันแม้ในขณะที่การอนุญาตยังมีชีวิต

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

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

ทดสอบสี่กรณี และตระกูลที่อยู่ทั้งสอง

การอนุญาตดีได้เท่ากับสี่กรณีที่มันผ่าน: คำขอใหม่ที่ได้รับอนุญาต ผู้ขอที่ไม่ได้รับอนุมัติ การเล่นซ้ำลิงก์เดิม และคำขอเดิมหลังหมดอายุ

จากนั้นทดสอบแต่ละตระกูลแยกกัน เพราะที่อยู่ต้นทางที่บริการสังเกตอาจต่างกันระหว่างสองตระกูล

dig +short A service.example.com
dig +short AAAA service.example.com
curl -4 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com
curl -6 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com

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