ซับโดเมนที่ใช้ร่วมกัน สองทางเข้า ใครเห็นบันทึกใด

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

ข้อแรก ชื่อโฮสต์เป็นเพียงชื่อของผู้เช่า

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

ฟังก์ชันช่วยเหลือที่ใช้ร่วมกันซึ่งคืนทั้งบริบทและสิทธิ์จากการค้นชื่อโฮสต์ครั้งเดียวคือจุดเริ่มต้นของบั๊ก

ข้อสอง สมาชิกภาพมาจากเซสชัน

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

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

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

ข้อสาม เครือข่ายไม่ได้พิสูจน์อะไรเกี่ยวกับบุคคล

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

DNS เป็นข้อเท็จจริงด้านการขนส่งข้อที่สาม คำตอบส่วนตัวต้องใช้เส้นทางส่วนตัว และส่วนหน้าที่สาธารณะต้องใช้เส้นทางต้นทางที่รองรับ ไม่มีข้อใดพกพาสิทธิ์

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

ข้อสี่ รันเมทริกซ์บนทางเข้าทั้งสอง

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

curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-b.example.com/records/42
curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-a.example.com/records/42

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

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