ตกลงหรือไม่ที่จะมีชั้นตรวจสอบความถูกต้องก่อนเลเยอร์ควบคุมการเข้าถึง

ฉันกำลังสร้างแอปพลิเคชันเว็บที่มีโครงสร้าง API และในแอปพลิเคชันนี้เรามีเลเยอร์ต่างๆที่ทำงานของตนเอง

ชั้นแรกคือการตรวจสอบชั้นที่ผู้ใช้ป้อนข้อมูลตรวจสอบและถ้ามันผ่านการตรวจสอบเราย้ายที่ชั้นที่สอง (ซึ่งก็คือการควบคุมการเข้าถึงชั้น) มิฉะนั้นกลับเกิดข้อผิดพลาด

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

ชั้นที่สามคือชั้นควบคุมที่เรามีตรรกะของแอปพลิเคชัน

คำถามของฉันคือว่าตกลงที่จะมีชั้นตรวจสอบก่อนการควบคุมการเข้าถึง? เกิดอะไรขึ้นถ้าผู้ใช้พยายามที่จะทำงานที่ผู้ใช้ไม่ได้รับอนุญาตและเราจะส่งกลับข้อผิดพลาดการตรวจสอบ? ผู้ใช้จะส่งคำขอไปยังปลายทางและพูดคุยกับเลเยอร์การตรวจสอบและเมื่อผ่านการตรวจสอบแล้วเขาจะเห็นข้อความYou can't access this!

ฉันรู้สึกแปลก ๆ ดังนั้นมันดีเหมือนนี้หรืออะไรเป็นทางเลือกอื่นของฉันในโครงสร้างพื้นฐานนี้

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

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

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

มีการตรวจสอบหลายประเภท:

1. การตรวจสุขภาพขั้นพื้นฐานราคาถูกซึ่งยืนยันว่าการร้องขอนั้นไม่ผิดรูปแบบ

   โดยทั่วไปจะเป็นฝั่งไคลเอ็นต์ที่ทำซ้ำอย่างน้อยบางส่วนเพื่อหลีกเลี่ยงการไปกลับ

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

2. การตรวจสอบความถูกต้องที่แพงกว่าซึ่งยังไม่ได้ขึ้นอยู่กับข้อมูลแอปพลิเคชันที่ได้รับการป้องกันใด ๆ

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

   หากการตรวจสอบความถูกต้องของขั้นตอนแรกซ้ำซ้อนอาจทำให้การทำซ้ำส่วนของลูกค้าฝั่งนี้ด้วยเช่นกัน

3. การตรวจสอบเพิ่มเติมขึ้นอยู่กับการป้องกันข้อมูลแอปพลิเคชัน

   ทำก่อนการควบคุมการเข้าถึงอย่างชัดเจนเสี่ยงการรั่วไหลของข้อมูล ดังนั้นก่อนจะควบคุมการเข้าถึง

ต้องมีบางการตรวจสอบก่อนที่จะควบคุมการเข้าถึง สมมติว่า API ของ SO นั้นมีปลายทาง "แก้ไขคำตอบ" จากนั้นผู้ใช้สามารถแก้ไขคำตอบเฉพาะนั้นได้หรือไม่นั้นขึ้นอยู่กับคำตอบ (ด้านล่างชื่อเสียงที่แน่นอนผู้ใช้สามารถแก้ไขคำตอบของเขาเองได้) ดังนั้นพารามิเตอร์ "answer ID" ที่มีรูปแบบที่ถูกต้องจะต้องได้รับการตรวจสอบก่อนที่เลเยอร์ควบคุมการเข้าถึงจะเข้าสู่การเล่น อาจเป็นไปได้ว่าคำตอบนั้นมีอยู่

OTOH ดังที่ Caleth และ Greg กล่าวถึงการวางการตรวจสอบที่ครอบคลุมมากขึ้นก่อนการควบคุมการเข้าถึงเป็นความเสี่ยงด้านความปลอดภัยที่อาจเกิดขึ้น

ดังนั้นกฎที่ยากคือ

1. คุณต้องไม่เปิดเผยข้อมูลใด ๆ ผ่านการตรวจสอบว่าผู้ใช้ไม่ควรจะสามารถค้นพบได้
2. คุณต้องตรวจสอบข้อมูลก่อนที่การควบคุมการเข้าถึงจะสามารถใช้งานได้ในระดับที่การควบคุมการเข้าถึงต้องการ

การปฏิบัติตามกฎทั้งสองนี้อาจหมายความว่าคุณต้องมีการตรวจสอบความถูกต้องก่อนและบางอย่างหลังจากการควบคุมการเข้าถึง

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

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

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

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

ไม่มันไม่เป็นไร

หากคุณมีข้อผิดพลาดในชั้นการตรวจสอบของคุณมันอาจจะข้ามชั้นความปลอดภัย

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

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