URL ส่วนบุคคลที่ไม่สามารถคาดเดาได้นั้นเทียบเท่ากับการตรวจสอบด้วยรหัสผ่านหรือไม่

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

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

อีกวิธีหนึ่งคือฉันเพียงแค่สามารถใช้URL ส่วนตัว นั่นคือฉันสามารถโฮสต์ทรัพยากรในเส้นทางที่คาดเดาไม่ได้บางตัวอย่างเช่นhttps://example.com/23idcojj20ijf...ซึ่ง จำกัด การเข้าถึงผู้ที่รู้จักสตริงที่แน่นอน

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

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

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

ด้วยเหตุผลนี้ URL ส่วนตัวจึงใช้สำหรับการดำเนินการครั้งเดียวเช่นรีเซ็ตรหัสผ่านและโดยทั่วไปจะใช้งานได้ในเวลา จำกัด เท่านั้น

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

บันทึก:

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

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

URL ส่วนตัว / ยากที่จะเดาไม่เท่ากับการตรวจสอบด้วยรหัสผ่าน ตามธรรมชาติแล้ว URL ส่วนบุคคลไม่ได้เป็นส่วนตัวเลย - เป็นแหล่งข้อมูลที่สาธารณชนสามารถเข้าถึงได้ ฉันคิดว่า URL "ส่วนตัว" เป็นชื่อเรียกที่ไม่ถูกต้องแทนที่จะเป็น URL "คลุมเครือ"

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

สถานที่บางแห่งที่ฉันเคยเห็น URL "ส่วนตัว" ที่ใช้โดยทั่วไปคือ:

1. รีเซ็ตรหัสผ่านอีเมล
2. อีเมลการสร้างใบรับรอง
3. อีเมลยืนยันบัญชี / อีเมล
4. การส่งเนื้อหาที่ซื้อ (ebooks ฯลฯ )
5. สิ่งอื่น ๆ เช่นการเช็คอินเที่ยวบินพิมพ์บอร์ดดิ้งพาสใช้ URL ส่วนตัวนอกเหนือจากการตรวจสอบสิทธิ์แบบเดิม

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

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

โดยทั่วไปแล้ว URL ที่สร้างขึ้นแบบสุ่มจะมีคุณสมบัติอยู่สองสามประการ:

1. ควรหมดอายุหลังจากระยะเวลาที่เหมาะสม
2. ควรเป็น URL แบบใช้ครั้งเดียว: IE ควรหมดอายุหลังจากมีการเข้าถึงครั้งแรก
3. ควรเลื่อนการตรวจสอบสิทธิ์ของผู้ใช้ไปยังเอนทิตีอื่น ๆ ที่เชื่อถือได้เพื่อรับรองความถูกต้องของผู้ใช้อย่างปลอดภัย (โดยการส่งลิงค์ผ่านอีเมลหรือ SMS ฯลฯ )
4. มันเป็นไปไม่ได้ที่คอมพิวเตอร์สมัยใหม่จะบังคับให้เดรัจฉาน URL ในกรอบเวลาก่อนวันหมดอายุ - ไม่ว่าจะโดยการ จำกัด อัตรา API ที่เปิดเผยทรัพยากรหรือโดยการสร้าง url endpoint ที่มีเอนโทรปีเพียงพอที่ไม่สามารถเดาได้
5. ไม่ควรรั่วไหลข้อมูลเกี่ยวกับผู้ใช้ IE: หากหน้านี้เป็นการตั้งรหัสผ่านใหม่: หน้านั้นไม่ควรแสดงข้อมูลบัญชีผู้ร้องขอ หากอลิซร้องขอลิงค์รีเซ็ตรหัสผ่านและบ๊อบเดา URL อย่างใดบ๊อบไม่ควรรู้ว่าเขากำลังรีเซ็ตรหัสผ่านใด
6. หากมีการรั่วไหลของข้อมูลเกี่ยวกับผู้ใช้ควรใช้การตรวจสอบแบบดั้งเดิมเช่นหน้าอาจพิจารณาผู้ใช้รับรองความถูกต้องหากพวกเขามีชุดคุกกี้หรือหาก session_id ของพวกเขายังคงถูกต้อง

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

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

โปรโตคอลขั้นสูงเพิ่มเติม (เช่น OAUTH, Kerberos, ... ) ช่วยให้คุณสามารถพิสูจน์ว่าคุณรู้ความลับโดยไม่ต้องส่งความลับ สิ่งนี้สำคัญเนื่องจากมีวิธีการมากมายที่จะได้รับความลับที่ "ไม่สามารถคาดเดาได้" นอกเหนือจากการคาดเดา

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

มีคำตอบที่ดีอยู่แล้วในกระทู้นี้ แต่เพื่อตอบคำถามโดยตรง:

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

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

URL ลับของคุณไม่ได้ผูกไว้กับผู้ใช้เฉพาะ ดังที่คนอื่น ๆ ชี้ให้เห็นมันอาจลงเอยในไฟล์บันทึกของพร็อกซีหรือคำขอค้นหาที่ได้รับการจัดทำดัชนีโดย google หรือวิธีอื่น ๆ ที่อาจรั่วไหลออกมา

ในทางกลับกันรหัสผ่านจะเชื่อมโยงกับบัญชีผู้ใช้ที่ไม่ซ้ำกัน คุณมีความสามารถในการตั้งค่าใหม่หรืออนุญาตให้ใช้ในรูปแบบที่ตั้งบ้านของผู้ใช้หรือที่อยู่ IP ที่รู้จักหรือการควบคุมอื่น ๆ

ชื่อผู้ใช้ / รหัสผ่านช่วยให้คุณควบคุมการเข้าถึงได้ละเอียดยิ่งขึ้น

การควบคุมการเข้าถึงช่วยให้สามารถเข้าถึงตัวตน (หัวเรื่อง) ของทรัพยากร (วัตถุ) ในตัวอย่าง URL ของคุณตัวตนคือ "ทุกคนที่เคยได้รับ URL ผ่านวิธีการใด ๆ "

ไปกับชื่อผู้ใช้ / รหัสผ่านถ้าคุณสามารถ URL รั่วไหลออกมาในรูปแบบที่ไม่คาดคิดเมื่อเวลาผ่านไปทุกประเภท

URL ลับนั้นมีความปลอดภัยเท่ากับรหัสผ่านลับ อย่างไรก็ตามรหัสผ่านสามารถเก็บเป็นความลับได้ง่ายกว่า URL เพราะทุกคนและโปรแกรมรู้ว่ารหัสผ่านต้องเป็นความลับ

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

ในทำนองเดียวกันพร็อกซี HTTP จะไม่บันทึกรหัสผ่านในขณะที่ URL มักถูกบันทึกไว้

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

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

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

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

ยังมีอีกแง่มุมหนึ่งที่ฉันยังไม่เห็นกล่าวถึง - ตัวย่อ URL

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

เพื่อแสดง - สมมติว่า URL สุ่มของคุณยาว 128 บิต (เช่น guid) นอกจากนี้สมมติว่าตัวสร้างตัวเลขสุ่มของคุณนั้นแข็งแกร่งมากและคุณสร้างบิตเหล่านั้นอย่างสม่ำเสมอ การเดาหมายเลข 128 บิตนั้นยากมากและอาจใช้เวลานาน - URL ของคุณจะได้รับการป้องกันคีย์ 128 บิตอย่างมีประสิทธิภาพ

จากนั้นสมมติว่ามีคนแชร์ URL นี้บน shortener google URL วันนี้บริการที่ส่ง ID ยาว 10 ตัวอักษรประกอบด้วยตัวอักษรและตัวเลข (26 + 10) ^ 10 ~ = 3.6 * 10 ^ 15 <2 ^ 52 - ดังนั้นเราจึงได้ลดความแข็งแกร่งของคีย์ลงจาก 128 บิตเป็น 52 บิต

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

บทความต้นฉบับ: http://arxiv.org/pdf/1604.02734v1.pdf
โพสต์บล็อกสรุปบทความ (โดยผู้เขียน): https://freedom-to-tinker.com/blog/vitaly/gone-in- ตัวละครหกสั้น URL ที่ถือว่าเป็นอันตรายสำหรับระบบคลาวด์ / บริการ