ลิงก์ความปลอดภัยแบบไม่เปิดเผยต่อสาธารณะ เข้าถึงแบบสาธารณะไม่ได้จริงหรือ?
(vin01.github.io)- บริการ วิเคราะห์ URL/มัลแวร์ เช่น urlscan.io, Hybrid Analysis และ Cloudflare Radar URL Scanner จะเก็บลิงก์ไว้เพื่อแบ่งปันข้อมูล threat intelligence แต่ด้วยความผิดพลาดของผู้ใช้หรือการตั้งค่าสแกนเนอร์ที่ไม่ถูกต้อง ลิงก์ที่มีความอ่อนไหว อาจคงอยู่เป็นข้อมูลสาธารณะได้
- บริการที่ ตัว URL เองถูกใช้เสมือนสิทธิ์การเข้าถึง เช่น Dropbox, iCloud, AWS S3, Zoom, OneDrive, Airtable, ลิงก์รีเซ็ตรหัสผ่าน และลิงก์ล็อกอิน OAuth อาจได้รับผลกระทบเป็นพิเศษ
- ไม่ใช่ทุกลิงก์จะถูกเปิดเผยในทันที แต่มีการพบข้อมูลจริง เช่น เอกสารภาษี ใบเรียกเก็บเงิน รูปภาพ การสื่อสารงาน ความลับที่แชร์ผ่าน onetimesecret และข้อมูลอย่างสมาร์ตโฮมหรือวิดีโอบันทึกการประชุม
- urlscan Pro แสดงทั้ง Public และ การสแกนแบบ Unlisted ให้ลูกค้าแบบเสียเงินเห็น และอาจมีเส้นทางที่ส่งแบบ unlisted โดยไม่ตั้งใจได้ เช่น การตั้งค่า TheHive's Cortex-Analyzers
- ในช่วง 24 ชั่วโมงล่าสุด จำนวนการสแกนบน urlscan.io คือ Public 398,563 รายการ, Unlisted 328,147 รายการ และ Private 955,432 รายการ และจากการทดลองด้วย canary token ก็ยืนยันการเข้าถึงได้ภายใน 1 ชั่วโมงหลังส่งลิงก์ จึงจำเป็นต้อง จัดการการมองเห็นของการสแกน
ลิงก์ที่มีความอ่อนไหวซึ่งค้างอยู่ในบริการวิเคราะห์ URL
- urlscan.io, Hybrid Analysis และ Cloudflare Radar URL Scanner เก็บลิงก์จำนวนมากไว้เพื่อการวิเคราะห์ URL และมัลแวร์
- ปัญหาคือ ในคลังเก็บเหล่านี้อาจมี ลิงก์ส่วนตัวและลิงก์อ่อนไหว ปะปนอยู่ด้วย
- ผู้ใช้ส่งลิงก์อ่อนไหวเข้าสแกนโดยไม่รู้ว่ามันจะกลายเป็นข้อมูลสาธารณะ
- สแกนเนอร์หรือส่วนขยายที่ตั้งค่าไม่ถูกต้อง ส่งลิงก์ส่วนตัวที่สแกนจากอีเมลเข้าไปเป็นข้อมูลสาธารณะ
ลิงก์และข้อมูลที่อาจถูกเปิดเผย
- ลิงก์ที่ถูกพบมีทั้ง URL สำหรับแชร์ และ URL ที่เกี่ยวข้องกับการยืนยันตัวตนจากหลายบริการ
- การแชร์ไฟล์จากคลาวด์สตอเรจอย่าง Dropbox, iCloud, Sync, Egnyte, Ionos Hidrive และ AWS S3
- NAS ที่เชื่อมต่อคลาวด์ เช่น Western Digital Mycloud
- เครื่องมือสื่อสารในองค์กรอย่าง Slido, Zoom, OneDrive และ Airtable
- ลิงก์รีเซ็ตรหัสผ่านและลิงก์ล็อกอิน OAuth
- บริการเหล่านี้มักอนุญาตการเข้าถึงผ่าน ลิงก์ส่วนตัวเพียงลิงก์เดียว ที่มีตัวระบุแบบสุ่มรวมอยู่เพื่อความปลอดภัย
- บางลิงก์มีการป้องกันเพิ่มเติมด้วยรหัสผ่านหรือ passphrase ดังนั้นการเข้าถึงลิงก์เพียงอย่างเดียวอาจไม่ได้ทำให้ข้อมูลรั่วไหลทันที
- เนื้อหาที่มีความอ่อนไหวซึ่งถูกพบจริง ได้แก่
- ไฟล์ส่วนตัว เช่น เอกสารภาษี ใบเรียกเก็บเงิน รูปภาพ และการสื่อสารงาน
- ความลับที่แชร์ผ่าน onetimesecret
- วิดีโอบันทึกจากอุปกรณ์สมาร์ตโฮม
- วิดีโอบันทึกการประชุมที่เก็บไว้บนคลาวด์
ช่องโหว่ของเส้นทางการส่งและความรับผิดชอบ
- การส่งจำนวนมากที่พบบน urlscan.io มีแท็ก falconsandbox และจากจุดนี้ขอบเขตการวิเคราะห์จึงขยายไปถึง Hybrid Analysis
- Cloudflare Radar ก็มีแนวโน้มจะถูกใช้งานกว้างขึ้น และมีลิงก์ส่วนตัวบางส่วนถูกรวมไว้เป็นข้อมูลสาธารณะแล้ว
- ข้อกำหนดการใช้งานของ Hybrid Analysis ระบุว่าสามารถวิเคราะห์ เปิดเผย และแบ่งปันเนื้อหาที่ผู้ใช้ส่งมาได้ และไม่รับผิดชอบต่อข้อมูลที่ถูกรวมเข้ามาโดยบังเอิญในสิ่งที่ส่งหรือรายงานที่สร้างอัตโนมัติ
- ข้อกำหนดการใช้งานของ urlscan.io ก็ระบุเช่นกันว่าไม่รับผิดชอบต่อเนื้อหาหรือการกระทำของผู้ใช้ และผู้ใช้ต้องรับผิดชอบต่อเนื้อหาและกิจกรรมที่เผยแพร่ภายใต้บัญชีของตน
- ดูเหมือนจะไม่มี กลไกที่ชัดเจน สำหรับตรวจทานเนื้อหาเดิมเพื่อทำเครื่องหมายหรือลบลิงก์อ่อนไหว และอาจไม่ง่ายที่จะทำให้เป็นอัตโนมัติ
- การวิเคราะห์ของ Positive Security ใช้ canary token กับ urlscan.io เพื่อตรวจจับแหล่งที่มาแบบอัตโนมัติ และกล่าวถึงความเป็นไปได้ที่เครื่องมือความปลอดภัยซึ่งสแกนลิงก์อันตรายในอีเมลจะเป็นสาเหตุ
- พฤติกรรมแบบเดียวกันนี้ได้รับการยืนยันด้วย canary link เช่นกัน
การสแกนแบบ Unlisted และการเข้าถึงผ่าน urlscan Pro
- urlscan Pro ให้ผู้ใช้แบบเสียเงินและองค์กรเข้าถึงการสแกนในขอบเขตที่กว้างขึ้น ไม่ใช่แค่ Public แต่รวมถึง Unlisted scans ด้วย
- บน urlscan.io, Unlisted หมายถึงไม่ปรากฏบนหน้าสาธารณะหรือผลการค้นหา แต่ยังมองเห็นได้สำหรับลูกค้าของแพลตฟอร์ม urlscan Pro
- มีการระบุว่าลูกค้า urlscan Pro ถูกจำกัดให้เป็นนักวิจัยด้านความปลอดภัยที่ผ่านการตรวจสอบแล้วหรือบริษัทที่มีชื่อเสียง
- Cortex-Analyzers ของ TheHive เป็นตัวอย่างของเส้นทางการเปิดเผยโดยไม่ตั้งใจ
- ตัววิเคราะห์ urlscan.io ใช้การตั้งค่า
public:onอย่างชัดเจน - ด้วยการตั้งค่านี้ แม้การมองเห็นของบัญชี urlscan จะเป็น Private ลิงก์ก็ยังอาจปรากฏเป็น unlisted ได้
- โค้ดที่เกี่ยวข้องอยู่ใน urlscan.py ของ Cortex-Analyzers
- ตัววิเคราะห์ urlscan.io ใช้การตั้งค่า
- ในกรณีนี้ แม้ข้อมูลจะไม่ได้ถูกเปิดเผยสู่สาธารณะทั้งหมด แต่ผู้ใช้ urlscan Pro ก็ยังมองเห็นได้ จึงยังมีโอกาสที่ข้อมูลที่อ่อนไหวยิ่งกว่าจะรั่วไหล
จำนวนการสแกนและผลจาก canary token
- จำนวนการสแกนบน urlscan.io ในช่วง 24 ชั่วโมงล่าสุดมีดังนี้
Public: 398,563 รายการUnlisted: 328,147 รายการPrivate: 955,432 รายการ
- ผลการเข้าถึงที่ยืนยันด้วย canary token มีดังนี้
- ลิงก์ที่ส่งเข้า urlscan.io แบบ
unlistedถูก เข้าถึง 12 ครั้ง ภายใน 1 ชั่วโมงหลังส่ง - ลิงก์ที่ส่งเข้า Hybrid Analysis ผ่าน
APIไม่ใช่เบราว์เซอร์ ถูก เข้าถึง 10 ครั้ง ภายใน 1 ชั่วโมงหลังส่ง - IP บางรายการเข้าถึงลิงก์เฉพาะที่ส่งให้ทั้งสองบริการพร้อมกัน และใช้บริการทำ IP anonymization ของต้นทาง
- ลิงก์ที่ส่งเข้า urlscan.io แบบ
- รายการ IP ดังกล่าวถูกเผยแพร่ไว้ใน ไฟล์แยก
การลบลิงก์อ่อนไหวและข้อควรระวังในการใช้งาน
- urlscan.io และ Hybrid Analysis มีขั้นตอนให้รายงานลิงก์เพื่อลบออกได้
- สำหรับ Hybrid Analysis การลบและขอบเขตการแชร์มีความซับซ้อนมากกว่า
- ไฟล์ทั้งหมดที่ส่งไปยัง Public Sandbox สามารถค้นหาได้และถูกให้บริการทั่วโลก
- แม้เลือกช่อง “Do not share my sample with the community” ภาพหน้าจอและรายงานจริงก็ยังคงถูกให้บริการต่อไป
- “do not share” ใช้กับเฉพาะตัวอย่างอินพุตจริงเท่านั้น
- เมื่อใช้งานบริการเหล่านี้ ควรตรวจสอบ การมองเห็นของการสแกน ก่อนเสมอ
- หากเข้าถึงลิงก์หรือไฟล์จากฐานข้อมูล URL ลักษณะนี้ อาจพบความพยายามฟิชชิง ไฟล์มัลแวร์จริง หรือลิงก์อันตรายได้
- หากจำเป็นต้องเข้าถึง ควรตรวจสอบใน สภาพแวดล้อม sandbox
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
ปัญหาพื้นฐานอยู่ที่การมองว่า ลิงก์ที่ไม่มีการควบคุมการเข้าถึง เป็นสิ่งไม่เปิดเผยต่อสาธารณะ เพียงเพราะไม่มีดัชนีตัวระบุสาธารณะ
เมื่อเดือนที่แล้ว เรื่องการหา AWS account ID ผ่าน bucket ก็ได้รับความสนใจพอสมควรบน HN[0] และความเห็นโดยรวมในคอมเมนต์คือ การคาดหวังความปลอดภัยบนสมมติฐานว่าตัวระบุบัญชีเป็นข้อมูลลับนั้นเป็นเรื่องผิด
แนวคิดเดียวกันนี้ใช้ได้กับกรณีนี้ด้วย และนี่ไม่ใช่ปัญหาความปลอดภัยใหม่เท่าไร แต่เป็นเพียงอีกวิธีหนึ่งของ การค้นหาแบบใช้ search operator (dorking)
[0]: https://news.ycombinator.com/item?id=39512896
ในทางทฤษฎี ลิงก์เลขฐานสิบหก 256 ตัว หรือ 1024 บิต เดายากกว่าชื่อผู้ใช้ 32 ตัวอักษรและรหัสผ่าน 32 ตัวอักษรมาก
https://site.com/[256chars] มีชุดความเป็นไปได้ 2^1024 จึง brute force แทบเป็นไปไม่ได้
ในขณะที่ https://site,com/[32chars] กับรหัสผ่าน 32 ตัวอักษรมีชุดความเป็นไปได้ 2^256 ซึ่งก็เกือบเป็นไปไม่ได้เช่นกัน แต่ยังมีโอกาสมากกว่าแบบแรก
เหมือนกับมองเป็น https://site,com/[32chars][32chars]
อย่างไรก็ตาม แม้แบบแรกจะเดายากกว่า แต่ URL รั่วไหลบ่อยกว่ารหัสผ่านมาก
ในที่นี้ “ข้อความ” รวมกว้าง ๆ ตั้งแต่อีเมล, DM ไปจนถึงลิงก์ที่วางในเอกสาร
รู้สึกไม่สบายใจเลยเลือกวิธีอื่นในท้ายที่สุด แต่ก็ทำให้คิดต่ออยู่เรื่อย ๆ ว่า “ความลับ” ที่อยู่ใน URL กับความลับที่อยู่ใน token ที่ส่งไปตอนร้องขอ URL นั้นต่างกันจริง ๆ แค่ไหน
ข้อสรุปของผมคือ token สามารถออกให้แยกตามลูกค้าได้ และสามารถเฝ้าดู access log เพื่อตรวจจับพฤติกรรมน่าสงสัยแล้วเพิกถอนได้
อีกอย่างตามที่คนอื่นพูดไว้ วิธีคิดก็ต่างกันในแง่ว่าเราให้ความสำคัญแค่ไหนกับการเก็บรายชื่อไฟล์ให้เป็นความลับ
ในระดับสิ่งที่ Amazon อาจทำผิดพลาดได้ การเผลอเปิดเผยรายชื่อไฟล์ใน public bucket ดูเหมือนเป็นสิ่งที่ผู้ใช้ 99% ไม่สนใจ จึงมีลำดับความสำคัญต่ำ
แน่นอนว่าบริษัทของเราแพ้ในการแย่งชื่อนั้น
หลังจากนั้นทุกครั้งที่ใช้ AWS ก็กลายเป็นบทเรียนเล็ก ๆ ว่าปกติควรตั้งชื่อ bucket ในรูปแบบ -
ถ้าต้องเป็นส่วนตัวจริง ๆ ก็ควรเข้ารหัสชื่อโปรเจกต์ด้วย แล้วจัดสคริปต์ที่แสดงรายการ bucket เป็นชื่อที่ “คุ้นเคย” ให้แทน
บริการโฮสติ้งมักมีการประนีประนอมแปลก ๆ อยู่เสมอ และตัวระบุแบบสุ่มสมบูรณ์ซึ่งเป็นวิธีที่สมบูรณ์แบบในเชิงเทคนิค มีแนวโน้มจะเพิ่มภาระในการปฏิบัติงานมากกว่าชื่อเชิงบรรยายซึ่งเป็นวิธีที่ไม่สมบูรณ์แบบมาก
Bitwarden Send สร้างลิงก์ที่ส่งต่อให้คนอื่นได้ และมีสตริงสุ่มยาวต่อท้ายหลัง
#ใช้อยู่เป็นประจำ เลยอยากรู้ว่ามีปัญหาด้านความปลอดภัยไหม
อย่างน้อยลิงก์ก็เพิกถอนได้และตั้งให้หมดอายุอัตโนมัติหลังผ่านไปไม่กี่วันได้ แต่รหัสผ่านทั่วไปมักไม่ได้ทำงานแบบนั้น
ถ้าจะสร้างลิงก์แชร์แบบส่วนตัว ให้เก็บ ค่าลับ ไว้ในส่วน hash ของ URL
hash จะไม่ถูกส่งไปในการสอบถาม DNS หรือ HTTP request
เช่น ถ้าเข้า links.com?token= ลิงก์นั้นจะถูกส่งไปพร้อมกับ query parameter และอาจถูกเก็บไว้โดยตัวกลางอย่าง Cloudflare
แต่ถ้าเข้า links.com# ส่วน hash จะไม่ออกไปนอกเบราว์เซอร์
เวลาจัดการข้อมูลในส่วน hash การเข้ารหัสเป็นสตริง URL Safe Base64 จะสะดวก
กล่าวคือเป็นลำดับ JS Object ↔ JSON String ↔ URL Safe Base 64 String
ส่วนที่เหลือถูกต้อง แค่อยากเสริม nuance เรื่อง การเข้ารหัสของ HTTPS นี้ไว้
การใส่ไว้ใน fragment ช่วยได้ แต่ไม่สมบูรณ์แบบ
ไม่ได้พูดในเชิงอุดมคติเท่านั้น เพราะเคยเห็น token ส่วนตัวใน fragment รั่วไหลด้วยวิธีนี้จริง ๆ หลายครั้ง
[https://example.com?token=](<https://example.com?token=<secret>>;) ควรทำ DNS query แค่ “example.com” เท่านั้น
บอตที่ตามลิงก์ในอีเมลรัน JavaScript หรือไม่? มีความเสี่ยงไหมที่ POST ที่ JavaScript ชักนำจะไปเปิดใช้งานการกระทำจริง ๆ?
ลิงก์ที่ไม่ได้เป็นส่วนหนึ่งของลูป redirect แบบรวดเร็ว ย่อมถูกคัดลอกและวางเพื่อแชร์อยู่แล้ว
URL ถูกออกแบบมาเพื่อการนั้น เป็นสิ่งสากล และช่วยให้เข้าถึงทรัพยากรที่ให้บริการผ่านโปรโตคอลใด ๆ ได้ง่าย
การควบคุมการเข้าถึงสำหรับสิ่งที่ไม่ได้มีอายุสั้นควรทำอยู่นอก URL
ถ้าแชร์ลิงก์ผ่านช่องทางที่ไม่ใช่การเข้ารหัสแบบ end-to-end ผู้ที่เข้าถึง URL นั้นเป็นรายแรกไม่ใช่ผู้รับ แต่เป็นบริการของช่องทางนั้น
อาจเป็นเรื่องสมเหตุสมผลเหมือนที่ Bitwarden หา favicon เพื่อประสบการณ์ผู้ใช้ หรืออาจมีเจตนาไม่ดีเหมือน crawler ของ Facebook Messenger ที่อยากรู้มากขึ้นว่ามีการแชร์อะไรในข้อความส่วนตัว
เครื่องมือสแกนแบบนี้จะไม่ทำให้ประสบการณ์ผู้ใช้ดีขึ้น
หากระบุชัดเจนว่าผลการสแกนจะถูกเปิดเผย ผู้ใช้บางส่วนก็จะคิดใหม่ก่อนใช้บริการ และไม่ว่าจะเป็นผู้ใช้ฟรีหรือผู้ใช้ไลเซนส์ Pro ก็ไม่ดีต่อธุรกิจ
ลิงก์ “ส่วนตัว” ที่ใช้งานได้ไม่จำกัดนี่มักชวนให้สงสัยอยู่เสมอ
สุดท้ายก็เป็น ความปลอดภัยที่พึ่งพาความคลุมเครือ
เวลาจะแชร์อย่างเช่น Google Docs อย่างน้อยก็มีตัวเลือกที่ระบุชัดว่า “ทุกคนที่มี URL สามารถเข้าถึงได้”
ในระบบที่ผมสร้างเอง ถ้าต้องการรูปแบบแบบนี้ ปกติจะใช้ signed URL ที่มีอายุแค่ไม่กี่นาที
โดยทั่วไป URL เป็นรายละเอียดการใช้งานภายในและไม่ได้แสดงให้ผู้ใช้เห็นโดยตรง แต่ก็มีโอกาสเห็นได้ในหน้าดีบักของเบราว์เซอร์
ถ้าสิ่งนี้บนอินเทอร์เน็ตไม่ได้รับการป้องกันด้วยอะไรเลยนอกจากสตริงสุ่มใน URL จริง ๆ แล้วมันก็ไม่ใช่ของส่วนตัว
เป็นเรื่องเดียวกับเว็บแคมที่เชื่อมต่ออินเทอร์เน็ตซึ่งค้นหาก็เจอ
เรื่องนี้เรารู้อยู่แล้วไม่ใช่หรือ? ไม่เข้าใจว่าทำไมในส่วน “ใครเป็นผู้รับผิดชอบ” ถึงไม่กล่าวถึงประเด็นนี้เลย
ไม่ใช่ทุกอย่างต้องการความปลอดภัยระดับสูงสุด และในบางกรณีแค่มีด่านกั้นเพื่อป้องกันการแชร์ในวงกว้างก็พอ
เช่น ในแกลเลอรีรูปภาพ ถ้ากด “สร้างลิงก์แชร์” แล้วส่งลิงก์รูปให้ใครสักคน ก็ไม่อยากให้คนนั้นต้องกรอกรหัสผ่าน
เปิดลิงก์แล้วควรเห็นรูปภาพเลย และสำหรับวัตถุประสงค์นั้นก็โอเค
หนึ่งในตัวอย่างตรงนี้เป็นกรณีแบบนั้นพอดี และเหมาะกับกรณีใช้งานนั้น
ในแง่ความกังวลเรื่องความเป็นส่วนตัว ต่อให้มีขั้นตอนล็อกอิน ผู้ใช้ปลายทางก็ยังแชร์สกรีนช็อตต่อได้อยู่ดี ณ จุดนั้น
ถือว่าความปลอดภัยเหมาะกับกรณีใช้งานแล้ว
เป็นสถานการณ์ที่ผู้ใช้มีลิงก์รูปอยู่แล้วและอาจแชร์ต่อได้ แต่เราเชื่อว่าเขาจะไม่ตั้งใจทำเช่นนั้น
ปัญหาใหญ่ตรงนี้ไม่ใช่ตัวลิงก์เองเท่าไร แต่เป็นการที่เครื่องมือวิเคราะห์ความปลอดภัยสแกนทุกลิงก์ที่ผู้ใช้ได้รับทางอีเมล แล้วทำให้ผู้ใช้คนอื่นในชุมชนนั้นเข้าถึงได้ด้วย
นั่นเป็นการแชร์ต่อที่กว้างกว่าที่ผมตั้งใจไว้มากตอนส่งรูปให้ใครสักคน
วิธีเลี่ยงปัญหา การยืนยันตัวตนผ่านอีเมล นี้คือ ใช้โค้ดชั่วคราวแบบใช้ครั้งเดียว โดยไม่ต้องไปถึงขั้นสร้างบัญชีพร้อมรหัสผ่าน
แบบนั้นต่อให้ URL ถูกแชร์โดยไม่ตั้งใจ ก็ไม่เป็นปัญหาใหญ่นัก
นอกเรื่องนิดหน่อย แต่ลิงก์พาไปที่ Cloudflare Radar ซึ่งบริการนี้ apparently ดูเหมือนจะทำเหมืองข้อมูลจาก ข้อมูล 1.1.1.1
ผมเข้าใจว่า 1.1.1.1 ไม่ใช้ข้อมูลผู้ใช้เพื่อวัตถุประสงค์ใด ๆ
อยากให้คนที่ฉลาดกว่าช่วยอธิบายหน่อย สองอย่างต่อไปนี้ต่างกันอย่างไร?
ถ้าสมมติว่าทั้งคู่มีการป้องกัน brute force หรือ rate limiting แบบเดียวกัน หรือไม่มีทั้งคู่ ทำไมข้อ 1 ถึงปลอดภัยกว่าข้อ 2?
แต่ในทางปฏิบัติมีความแตกต่าง
ความลับแบบอิงการครอบครอง กับ ความลับแบบอิงความรู้ นั้นต่างกัน
URL คือสิ่งที่คุณถือครอง ถ้าทิ้งไว้ในที่ที่เข้าถึงได้ก็อาจถูกเอาไปได้
รหัสผ่านคือสิ่งที่คุณรู้ และถ้าจัดการดี ๆ ก็ไม่ถูกเอาไปได้ ยกเว้นการโจมตีด้วยท่อตะกั่ว
อีกแบบหนึ่งคือแบบอิงชีวมิติ เช่น การสแกนม่านตาหรือลายนิ้วมือ
(1) ต้องใช้ข้อมูลจากช่องทางแยกต่างหากเพื่อยืนยันตัวตน และเป็นข้อมูลที่ผู้คนคุ้นเคยกับการเก็บรักษาอย่างปลอดภัย
ส่วน URL ใน (2) ถูกปฏิบัติเหมือน URL
URL มักถูกบันทึกลงล็อก ถูกบันทึกไว้ ถูกแชร์ และถูกส่งต่อไปหลายที่
เช่น ถ้าไฟร์วอลล์ของบริษัทบันทึกชื่อผู้ใช้และรหัสผ่านที่ใช้ล็อกอินเข้า service ใด service หนึ่ง นั่นแย่อย่างชัดเจน แต่การบันทึก URL ที่เข้าถึงอาจดูเหมือนยอมรับได้
อย่างหลังเป็นแค่ตัวอย่าง และด้วยการรับประกันแบบ end-to-end ของ TLS ทั้งสองอย่างไม่ควรถูกเข้าถึงได้อยู่แล้ว
เพิ่มเติมคือถ้า domain.com/12-char-password ถูกเรียกโดยไม่มี HTTPS แม้จะมี redirect คำขอแรกก็จะถูกส่งแบบไม่เข้ารหัส ทำให้เกิด man-in-the-middle attack ได้
ในทางกลับกัน หน้า login มีวิธีมากกว่าที่จะรับประกันว่าการส่งรหัสผ่านจะเกิดขึ้นบน HTTPS เท่านั้น
ปัญหาใหญ่ข้อหนึ่งคือแอปพลิเคชัน logging จำนวนมากบันทึก URL ทั้งหมดไว้ที่ไหนสักแห่ง และนั่นเท่ากับว่าได้บันทึก “รหัสผ่าน” ลงล็อกไปโดยปริยาย
สื่อและรูปภาพทั้งหมดที่อัปโหลดไปยังแอป airtable.com แบบ private เป็น ลิงก์สาธารณะ
ถ้ารู้ URL ก็เข้าถึงได้โดยไม่ต้องยืนยันตัวตน
แท็ก image ปกติไม่สามารถตั้งค่า Authorization header ที่มี token ใน request ได้เหมือนที่ทำกับ fetch() ใน API request
ตัวเลือกที่เป็นไปได้มีแค่เพิ่ม token ลงใน URL หรือใช้ cookie authentication
cookie authentication จะทำงานก็ต่อเมื่อ CDN อยู่บนโดเมนเดียวกัน และแม้แต่ subdomain ก็อาจเป็นปัญหาได้ในหลายกรณี
เห็นด้วยว่าอาจเป็นปัญหาได้
ลิงก์ประชุม Zoom มักแนบรหัสผ่านไว้เป็น พารามิเตอร์คิวรี
ลิงก์แบบนี้ถือเป็นลิงก์ “ความปลอดภัยแบบไม่เปิดเผย” หรือไม่? แล้วลิงก์ที่ไม่มีรหัสผ่านถือเป็นลิงก์ “ความปลอดภัยแบบไม่เปิดเผย” หรือไม่?
เพราะเมื่อ URL ไปปรากฏที่อื่น การประชุมนั้นก็น่าจะจบและหายไปแล้ว
แต่ในความเป็นจริง ไม่มีใครใส่ใจ และทุกคนต้องการแบบ “คลิกเพื่อเข้าร่วม” โดยไม่ต้องกรอกโน่นกรอกนี่
วิธีเดิมที่ “ใช้แค่ ID การประชุม” นั้นเดาได้ง่ายเกินไป