การเปิดเผย ID ฐานข้อมูล - ความเสี่ยงด้านความปลอดภัย?

ฉันได้ยินมาว่าการเปิดเผย ID ฐานข้อมูล (ใน URL เป็นต้น) เป็นความเสี่ยงด้านความปลอดภัย แต่ฉันมีปัญหาในการทำความเข้าใจว่าเหตุใด

มีความคิดเห็นหรือลิงก์ว่าเหตุใดจึงเสี่ยงหรือเหตุใดจึงไม่เป็นเช่นนั้น

แก้ไข: แน่นอนว่าการเข้าถึงนั้นถูกกำหนดขอบเขตไว้เช่นหากคุณไม่เห็นทรัพยากรfoo?id=123คุณจะได้รับหน้าข้อผิดพลาด มิฉะนั้น URL ควรเป็นความลับ

แก้ไข: หาก URL เป็นความลับอาจมีโทเค็นที่สร้างขึ้นซึ่งมีอายุการใช้งาน จำกัด เช่นใช้ได้ 1 ชั่วโมงและใช้ได้เพียงครั้งเดียว

แก้ไข (หลายเดือนต่อมา): แนวปฏิบัติที่ฉันต้องการในปัจจุบันคือการใช้ UUIDS สำหรับ ID และเปิดเผย ถ้าฉันใช้หมายเลขตามลำดับ (โดยปกติสำหรับประสิทธิภาพในบางฐานข้อมูล) เป็น ID ฉันชอบสร้างโทเค็น UUID สำหรับแต่ละรายการเป็นคีย์สำรองและเปิดเผยสิ่งนั้น

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

ต่อไปนี้เป็นกฎที่ดีที่จะปฏิบัติตาม:

1. ใช้การรักษาความปลอดภัยตามบทบาทเพื่อควบคุมการเข้าถึงการดำเนินการ วิธีการดำเนินการนี้ขึ้นอยู่กับแพลตฟอร์มและเฟรมเวิร์กที่คุณเลือก แต่หลายคนสนับสนุนรูปแบบการรักษาความปลอดภัยที่เปิดเผยซึ่งจะเปลี่ยนเส้นทางเบราว์เซอร์ไปยังขั้นตอนการรับรองความถูกต้องโดยอัตโนมัติเมื่อการดำเนินการต้องใช้อำนาจบางอย่าง
2. ใช้การรักษาความปลอดภัยแบบเป็นโปรแกรมเพื่อควบคุมการเข้าถึงวัตถุ สิ่งนี้ยากกว่าที่จะทำในระดับกรอบ บ่อยครั้งเป็นสิ่งที่คุณต้องเขียนลงในโค้ดของคุณดังนั้นจึงมีข้อผิดพลาดมากกว่า การตรวจสอบนี้นอกเหนือไปจากการตรวจสอบตามบทบาทโดยการตรวจสอบให้แน่ใจว่าไม่เพียง แต่ผู้ใช้มีสิทธิ์ในการดำเนินการเท่านั้น แต่ยังมีสิทธิ์ที่จำเป็นสำหรับออบเจ็กต์เฉพาะที่กำลังแก้ไข ในระบบตามบทบาทคุณสามารถตรวจสอบได้ง่ายว่ามีเพียงผู้จัดการเท่านั้นที่สามารถให้เงินเพิ่มได้ แต่นอกเหนือจากนั้นคุณต้องตรวจสอบให้แน่ใจว่าพนักงานนั้นอยู่ในแผนกของผู้จัดการโดยเฉพาะ
3. สำหรับบันทึกฐานข้อมูลส่วนใหญ่เงื่อนไข 1 และ 2 เพียงพอแล้ว แต่การเพิ่มรหัสที่คาดเดาไม่ได้อาจถือได้ว่าเป็นการประกันเพิ่มเติมเล็กน้อยหรือ "การรักษาความปลอดภัยในเชิงลึก" หากคุณซื้อในแนวคิดนั้น สถานที่หนึ่งที่ตัวระบุที่ไม่สามารถคาดเดาได้เป็นสิ่งจำเป็นอย่างไรก็ตามอยู่ในรหัสเซสชันหรือโทเค็นการตรวจสอบความถูกต้องอื่น ๆ โดยที่ ID นั้นจะพิสูจน์ตัวตนคำขอ สิ่งเหล่านี้ควรสร้างขึ้นโดย RNG ที่เข้ารหัส

แม้ว่าจะไม่ใช่ความเสี่ยงด้านความปลอดภัยของข้อมูลแต่ก็ถือเป็นความเสี่ยงด้านความปลอดภัยของระบบธุรกิจอัจฉริยะเนื่องจากเปิดเผยทั้งขนาดข้อมูลและความเร็ว ฉันเคยเห็นธุรกิจต่างๆได้รับอันตรายจากสิ่งนี้และได้เขียนเกี่ยวกับรูปแบบการต่อต้านนี้ในเชิงลึก เว้นแต่คุณจะสร้างการทดสอบและไม่ใช่ธุรกิจฉันขอแนะนำอย่างยิ่งให้เก็บรหัสส่วนตัวของคุณไว้ให้พ้นสายตาของสาธารณชน https://medium.com/lightrail/prevent-business-intelligence-leaks-by-using-uuids-instead-of-database-ids-on-urls-and-in-apis-17f15669fd2e

ขึ้นอยู่กับว่า ID นั้นหมายถึงอะไร

พิจารณาไซต์ที่เหตุผลในการแข่งขันไม่ต้องการเปิดเผยต่อสาธารณะว่าพวกเขามีสมาชิกกี่คน แต่การใช้รหัสตามลำดับจะเปิดเผยเว็บไซต์ใน URL: http://some.domain.name/user?id=3933

ในทางกลับกันหากพวกเขาใช้ชื่อล็อกอินของผู้ใช้แทน: http://some.domain.name/user?id=someพวกเขาไม่ได้เปิดเผยอะไรที่ผู้ใช้ไม่รู้

แนวความคิดทั่วไปเป็นไปตามบรรทัดต่อไปนี้: "เปิดเผยข้อมูลเพียงเล็กน้อยเกี่ยวกับการทำงานภายในของแอปของคุณให้ทุกคนทราบ"

การเปิดเผย ID ฐานข้อมูลถือเป็นการเปิดเผยข้อมูลบางส่วน

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

เราใช้ GUID สำหรับรหัสฐานข้อมูล การรั่วไหลเป็นอันตรายน้อยกว่ามาก

หากคุณกำลังใช้ ID จำนวนเต็มในฐานข้อมูลของคุณคุณอาจทำให้ผู้ใช้เห็นข้อมูลที่ไม่ควรทำได้โดยการเปลี่ยนตัวแปร qs

เช่นผู้ใช้สามารถเปลี่ยนพารามิเตอร์ id ใน qs นี้ได้อย่างง่ายดายและดู / แก้ไขข้อมูลที่ไม่ควรhttp: // someurl? id = 1

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

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

ดังนั้นเราจึงใช้รหัสท้องถิ่นของเซสชันสังเคราะห์เพราะมันซ่อนไว้มากที่สุดเท่าที่เราจะทำได้

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