ประสบการณ์การแฮ็กแอปหาคู่ และวิธีที่ผิดพลาดในการปฏิบัติต่อ นักวิจัยด้านความปลอดภัย

 (alexschapiro.com)
2 คะแนน โดย GN⁺ 2025-05-13 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • แอปหาคู่ Cerca ใช้การล็อกอินด้วยหมายเลขโทรศัพท์ร่วมกับ API ที่เปิดเผย ทำให้เกิดสภาพเสี่ยงอันตรายที่ โค้ดยืนยันตัวตนถูกรวมอยู่ในคำตอบของ OTP และอาจลุกลามไปถึงการเข้าถึงข้อมูลส่วนบุคคลได้
  • api.cercadating.com เมื่อแนบ header เวอร์ชันแอปแล้ว จะสามารถเห็น endpoint ผ่าน openapi.json ของ /docs และบางคำขอยังสามารถแก้ไข business logic เช่นการจับคู่คนสองคนแบบบังคับได้
  • user/{user_id} คืนค่า PII เช่นชื่อ ตำแหน่ง วันเกิด โรงเรียน หมายเลขโทรศัพท์ อีเมล และสถานะโปรไฟล์ เพียงมี user ID ที่ถูกต้อง ซึ่งเมื่อรวมกับช่องโหว่ OTP ก็อาจนำไปสู่การยึดบัญชีได้
  • หลังเข้าถึงบัญชีแล้ว ยังสามารถเข้าถึง ข้อมูลหนังสือเดินทางหรือบัตรประจำตัว, URL เซลฟี และข้อความส่วนตัวได้สำหรับผู้ใช้ที่เคยส่งข้อมูลดังกล่าว โดยสคริปต์ตรวจสอบพบผู้ใช้ 6,117 คน, ผู้ใช้ 207 คนที่กรอกข้อมูลบัตร, และผู้ใช้ 19 คนที่แสดงว่าเป็นนักศึกษา Yale
  • ช่องโหว่ถูกรายงานต่อ Cerca เมื่อวันที่ 23 กุมภาพันธ์ 2025 และมีการคุยทางโทรศัพท์ในวันที่ 24 กุมภาพันธ์ แต่จนถึงเวลาที่เปิดเผยเมื่อวันที่ 21 เมษายน ก็ไม่มีคำตอบติดตามหรือการแจ้งเตือนผู้ใช้ มีเพียงการยืนยันอย่างอิสระว่าได้มีการแพตช์แล้ว

การตอบสนองที่ขาดหายหลังการแจ้งช่องโหว่

  • แอปหาคู่ Cerca มี ช่องโหว่ด้านความปลอดภัยของแอปหาคู่ ที่อาจเปิดให้เห็นข้อความส่วนตัว ข้อมูลหนังสือเดินทาง รสนิยมทางเพศ และข้อมูลส่วนบุคคลอื่น ๆ
  • หลังค้นพบช่องโหว่ จึงได้รายงานไปยังทีม Cerca ทางอีเมลเมื่อวันที่ 23 กุมภาพันธ์ 2025 และในวันถัดมาได้คุยวิดีโอเพื่อหารือเรื่องช่องโหว่ แนวทางบรรเทา และมาตรการติดตามผล
  • ทีม Cerca ยอมรับถึงความร้ายแรงของปัญหา ขอบคุณสำหรับการเปิดเผยอย่างรับผิดชอบ และให้คำมั่นว่าจะแก้ไขช่องโหว่พร้อมแจ้งผู้ใช้ที่ได้รับผลกระทบ
  • จากนั้นได้ขออัปเดตเกี่ยวกับการแก้ไขและแผนแจ้งผู้ใช้ในวันที่ 5 มีนาคม และ 13 มีนาคม แต่จนถึงวันที่เปิดเผย 21 เมษายน 2025 ก็ไม่มีการตอบกลับ
  • ก่อนเปิดเผย มีการ ยืนยันอย่างอิสระ แล้วว่าช่องโหว่ได้รับการแพตช์ จึงตัดสินใจเผยแพร่ข้อมูล

การเข้าถึงบัญชีที่เริ่มจากการล็อกอิน OTP

  • แอปใช้เพียง การล็อกอินแบบ OTP ที่ส่งรหัสไปยังหมายเลขโทรศัพท์
  • เพื่อดูคำขอเครือข่ายจากแอป จึงใช้ Charles Proxy บนแอป iPhone เพื่อดักจับคำขอของแอป
  • ในคำตอบที่ใช้ trigger OTP นั้น มี one-time password รวมอยู่โดยตรง
  • ด้วยโครงสร้างนี้ หากรู้เพียงหมายเลขโทรศัพท์ของผู้ใช้ ก็สามารถเข้าถึงบัญชีนั้นได้
  • เนื่องจากยังต้องมีช่องทางอื่นเพื่อรู้หมายเลขโทรศัพท์ของเจ้าของบัญชี จึงนำไปสู่การสำรวจ API endpoint

Endpoint ที่ถูกเปิดเผยผ่านเอกสาร OpenAPI

  • ใช้ directory fuzzer เพื่อไล่ enumerates path ของ api.cercadating.com
  • หากไม่มี header ที่เกี่ยวข้องกับแอป จะไม่สามารถเข้าถึงส่วนใดของเว็บไซต์ได้เลย
  • เมื่อตั้งให้ Gobuster ส่งคำขอพร้อม header ดังกล่าว ก็พบ endpoint /docs และมี openapi.json ให้ใช้งานที่นั่น
  • ใช้ฟังก์ชัน match-and-replace ของ Burp Suite เพื่อตั้งให้แนบ header เวอร์ชันแอปและ bearer token ที่ดึงจาก Charles Proxy ติดไปทุกครั้ง
  • บาง endpoint ที่ไม่ได้รับการป้องกันส่งผลต่อ business logic และยังสามารถส่งคำขอเพื่อบังคับจับคู่คนสองคนได้

การเปิดเผยโปรไฟล์ผู้ใช้และข้อมูลส่วนบุคคล

  • endpoint user/{user_id} จะคืนข้อมูลส่วนบุคคลหลากหลายอย่างเมื่อได้รับ user ID ที่ถูกต้อง
  • คำตอบมีข้อมูลดังต่อไปนี้
    • ชื่อ เพศ เพศที่สนใจ เมือง ละติจูด·ลองจิจูด
    • อีเมลสถาบันการศึกษาและสถานะการยืนยัน อุตสาหกรรม อาชีพ วันเกิด ส่วนสูง
    • school ID และชื่อสถาบัน สถานะความสมบูรณ์ของโปรไฟล์
    • สถานะการยืนยันสัญชาติด้วยเอกสาร สถานะการยืนยันมือถือ·อีเมล
    • สถานะพรีเมียม สถานะบัญชีว่าใช้งานอยู่·พักใช้งานชั่วคราว·อยู่ใน onboarding
    • หมายเลขโทรศัพท์ อีเมล user ID จำนวนครั้งค้นหาที่เหลือ
    • รูปโปรไฟล์ ความชอบในการจับคู่ prompt ของผู้ใช้ ข้อมูลติดต่อร่วมกัน เวลาสร้าง·แก้ไข และอายุ เป็นต้น
  • ด้วยสคริปต์ Python สามารถค้นหา user ID ที่มีอยู่จริงและไล่ดึงข้อมูลผู้ใช้จำนวนมากได้
  • หมายเลขโทรศัพท์ที่ได้กลับมานั้น เมื่อนำไปรวมกับช่องโหว่ OTP ก็สามารถใช้เพื่อ เข้าถึงบัญชีทั้งหมด ได้
  • แม้ไม่ต้องล็อกอินด้วย OTP ก็ยังอยู่ในสภาพที่ข้อมูลส่วนบุคคลของผู้ใช้ถูกเปิดเผย

การเข้าถึงต่อเนื่องไปถึงบัตรประจำตัวและข้อความส่วนตัว

  • ฟิลด์ national_id_verified แสดงให้เห็นว่าระบบมีการเก็บข้อมูลหนังสือเดินทางหรือบัตรประจำตัว
  • คำตอบที่เกี่ยวกับเอกสารยืนยันตัวตนมีข้อมูลดังต่อไปนี้
    • verification_type: PASSPORT
    • document_number
    • front_side_url
    • back_side_url
    • selfie_url
    • สถานะ, ID, user ID
  • ข้อมูลเหล่านี้ถูกส่งให้เฉพาะผู้ใช้ที่ล็อกอินแล้วเท่านั้น แต่เพราะช่องโหว่ OTP จึงอยู่ในสภาพที่ สามารถล็อกอินเป็นผู้ใช้คนใดก็ได้
  • ผู้เขียนระบุว่าโครงสร้างนี้ทำให้สามารถดูข้อมูลเอกสารยืนยันตัวตนของใครก็ได้หากมีการส่งไว้ แต่ในทางปฏิบัติไม่ได้ทำเช่นนั้น
  • ยังสามารถดู ข้อความส่วนตัว กับคู่เดตที่เป็นไปได้ และหากมีการส่งไว้ก็เข้าถึงข้อมูลหนังสือเดินทางได้ด้วย

ขนาดของการเปิดเผยที่ตรวจสอบได้

  • ใช้สคริปต์อย่างรวดเร็วเพื่อนับจำนวนผู้ใช้ที่สามารถดึงข้อมูลได้ จำนวนผู้ใช้ที่ลงทะเบียนว่าเป็นนักศึกษา Yale และจำนวนผู้ใช้ที่กรอกข้อมูลบัตรประจำตัว
  • สคริปต์ทำงานโดยไล่ตรวจ user ID ที่มีอยู่จริง และจะหยุดเมื่อไม่พบ ID ที่ใช้ได้ติดต่อกัน 1,000 ค่า
  • วิธีนี้ไม่ได้ตัดความเป็นไปได้ว่ายังมีผู้ใช้อีกมากกว่านี้
  • Cerca ระบุว่ามีผู้ใช้ 10,000 คนในสัปดาห์แรก
  • ตัวเลขที่ยืนยันได้มีดังนี้
    • ผู้ใช้ 6,117 คน
    • ผู้ใช้ที่กรอกข้อมูลบัตร 207 คน
    • ผู้ใช้ที่ระบุว่าเป็นนักศึกษา Yale 19 คน

คำมั่นเรื่องความเป็นส่วนตัวกับความเสี่ยงที่เกิดขึ้นจริง

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

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-05-13
ความคิดเห็นจาก Hacker News

  • แอปนี้ดูเหมือนเป็น โปรเจกต์ระดับเริ่มต้น ที่นักศึกษามหาวิทยาลัยทำขึ้น แน่นอนว่าพวกเขาควรพยายามอย่างเต็มที่เพื่อปฏิบัติตามแนวทางด้านความปลอดภัยและการสื่อสารให้ถูกต้อง แต่เมื่อคิดว่าแม้แต่ “บริษัทผู้ใหญ่” ที่ได้รับเงินลงทุนจาก VC รายใหญ่ก็ยังรับมือกับปัญหาคล้าย ๆ กันได้เละเทะ ผมก็ไม่อยากโจมตีพวกเขารุนแรงเกินไป
    https://georgetownvoice.com/2025/04/06/georgetown-students-c...

    • ไม่เห็นด้วยอย่างยิ่ง การบอกว่า “พวกเขาไม่รู้ว่ากำลังทำอะไรอยู่ ก็อย่าตัดสินแรงเกินไป” ฟังดูแปลก ถ้าไม่รู้ว่ากำลังทำอะไรอยู่แต่ยัง เดินหน้าไปจนถึงการเปิดตัว นั่นไม่น่าจะเป็นเหตุบรรเทา แต่ใกล้เคียงกับเหตุเพิ่มน้ำหนักความผิดมากกว่า
      คล้ายกับกรณีคนขับรถชนคนตาย แล้วมารู้ทีหลังว่าไม่มีใบขับขี่ด้วยซ้ำ
    • ตอนค้นหาข้อมูลเกี่ยวกับ “Cerca” ก็เจอลิงก์เดียวกันนี้ เป็นบทความเดือนเมษายน 2025 ที่ชื่นชมแอปที่เพิ่งทำมาได้สองเดือน เลยดูเหมือน บทความขยะจากอาการหลอนของ LLM
      ในโพสต์ต้นฉบับบอกว่าเขาติดต่อทีม Cerca ตั้งแต่เดือนกุมภาพันธ์ ดังนั้นคงเป็นช่องโหว่ที่พบในวันเปิดตัว หรือไม่ก็มีโครงสร้างอะไรบางอย่างที่แปลกอยู่ ไม่ว่าจะอย่างไร นี่ก็เป็นทั้ง “ช่องโหว่อายุสองเดือน” และ “แอป/บริการที่นักศึกษาทำซึ่งมีอายุสองเดือน”
    • ถ้าแอปเปิดตัวในนาม Cerca Applications, LLC แล้วเราจะรู้ได้อย่างไรว่าเป็นแค่สคริปต์คิดดี้ไม่กี่คนที่ควรมองข้ามให้
    • คนเหล่านี้น่าจะไปเรียนสาขาอื่นจะดีกว่า
    • ที่พูดมาก็มีเหตุผล แต่กรณีนี้ก็ยังเกินไปอยู่ดี การไม่ส่ง OTP ที่ควรเป็นความลับกลับมาใน response body น่าจะใกล้เคียงกับสามัญสำนึก ไม่ว่าจะเป็นนักพัฒนามีประสบการณ์หรือเด็กมัธยม
      แถมนี่ไม่ใช่ของที่ทำเล่น ๆ แต่เป็นผลิตภัณฑ์เชิงพาณิชย์ มี in-app purchase ขึ้นไว้ว่า Cerca App $9.99, Cerca App 3 month $9.99, 10 Swipes $2.99, 3 Swipes $0.99, 5 swipes $1.99, 3 Searches $1.99, 10 Searches $3.99, 5 Searches $2.99

  • ในฐานะวิศวกรของบริษัทเล็ก บางครั้งผมก็กังวลเรื่อง ความรับผิดส่วนบุคคล ของตัวเอง มีบริษัทจำนวนมากที่อยู่ในอุตสาหกรรมที่ไม่ถูกกำกับดูแล ไม่อยู่ภายใต้ PCI หรือ HIPAA และในองค์กรเล็ก ๆ ความปลอดภัยมักถูกผลักให้เป็นแค่เรื่องที่ฝ่ายวิศวกรรมสนใจ ไม่ใช่หน้าที่ระดับองค์กร
    ทีมผลิตภัณฑ์โฟกัสที่ฟีเจอร์, PM โฟกัสที่กำหนดการ, QA โฟกัสที่การหาบั๊ก และแทบไม่มีใครส่งเสียงอย่างมีเหตุผลเรื่องความปลอดภัย วิศวกรไม่ได้ถูกคาดหวังให้ทำอะไรมากกว่าปิดงานที่อยู่บนบอร์ด ถ้าทำให้ปลอดภัยได้โดยไม่กระทบกำหนดการก็ดี แต่ถ้าไม่ได้ ก็จะถูก PM หรือคนอื่น ๆ กดดัน
    แล้วก็จะได้ยินคำพูดอย่าง “ต้องใช้เวลานานแค่ไหน?”, “ความเสี่ยงที่เรื่องแบบนั้นจะเกิดขึ้นจริงมีมากแค่ไหน?”, “ไว้ค่อยจัดการเรื่องความปลอดภัยทีหลัง ตอนนี้ปล่อย MVP ให้ลูกค้าใช้ก่อนเถอะ” ในฐานะพนักงาน ผมก็ทำงานตามที่นายจ้างสั่ง แต่ถ้าบริษัทถูกฟ้องเพราะถูกแฮ็กหรือข้อมูลรั่ว ผมก็อดคิดไม่ได้ว่าผมจะต้องรับผิดส่วนตัวหรือเปล่า เพียงเพราะเป็นคนเดียวที่ “ควรรู้” เรื่องนี้

    • พูดอย่างเคร่งครัดแล้ว ก็ไม่ใช่ วิศวกรตามความหมายทางวิศวกรรมจริง ๆ คุณคงไม่ได้ลงนามในแบบออกแบบที่รับรองความปลอดภัย และแม้พิสูจน์ได้ว่าไม่ปลอดภัย คุณก็ไม่ได้เป็นคนรับผิดชอบเรื่องนั้น
    • ถ้าเป็น LLC หรือนิติบุคคล ก็น่าจะได้รับการคุ้มครองด้วย ม่านนิติบุคคล ตราบใดที่ไม่ได้มีหลักฐานเป็นลายลักษณ์อักษรว่าทำอาชญากรรม
      อย่างไรก็ตาม การที่องค์กรทุกขนาดขาดมาตรฐานความปลอดภัยโดยรวมเป็นเรื่องน่าสมเพช ดูเหมือนการปล่อยฟีเจอร์ใหม่จะมาก่อนการทำให้แน่ใจว่ามีแนวทางความปลอดภัยที่ดีเสมอ
    • โดยส่วนตัวแล้ว ผมอยากรู้กฎหมายให้พอปกป้องตัวเองได้ คัดค้านสิ่งผิดกฎหมายเป็นลายลักษณ์อักษร และถ้ามีคำสั่งให้เพิกเฉย ก็ขออนุมัติเป็นลายลักษณ์อักษรเก็บไว้ด้วย
      แต่ก็เข้าใจว่าในสตาร์ทอัพที่มีนักพัฒนาแค่หนึ่งหรือสองคน แม้แต่เรื่องนี้ก็ทำได้ยาก ถ้าผมรู้สึกว่าบริษัทไม่ได้มุ่งทำสิ่งที่ถูกกฎหมาย ผมคงลาออก
    • ถ้าเป็นวิศวกรในองค์กรเล็ก ผมมองว่าคุณมีหน้าที่ให้ความรู้กับทีมที่เหลือเกี่ยวกับ ความเสี่ยงด้านความปลอดภัย เหล่านี้ และผลักดันให้กันเวลาทางวิศวกรรมมาใช้ลดความเสี่ยง
      มันไม่ง่าย แต่เป็นเรื่องสำคัญที่ถ้าไม่จัดการอย่างจริงจัง อาจทำให้ธุรกิจทั้งธุรกิจจมลงได้
    • ถึงผมจะไม่ชอบแนวป้องกันตัวแบบ “แค่ทำตามคำสั่ง” แต่ในกรณีแบบนี้ต้องมี บันทึกเป็นลายลักษณ์อักษร ไว้แน่นอน
      ต้องมีประวัติอีเมลที่คุณยกความกังวลเรื่องการขาดความปลอดภัย และบันทึกที่หัวหน้าตอบกลับมาว่าไม่ต้องใส่ใจ ผมไม่รู้ว่าอยู่ในเขตอำนาจศาลไหน แต่ไม่เคยได้ยินกรณีที่พนักงานทั่วไปต้องรับผิดทางกฎหมายเป็นการส่วนตัวจากเหตุข้อมูลรั่ว โดยปกติแล้วเหตุข้อมูลรั่วมักไม่มีใครเผชิญผลลัพธ์จริงจัง บริษัทแค่จ่ายค่าปรับเชิงพิธีการแล้วก็ผ่านไป

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

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

  • บทความค่อนข้างสับสน ส่วนที่บอกว่าในระบบล็อกอินแบบ OTP การตอบกลับของคำขอรหัสผ่านแบบใช้ครั้งเดียวมี OTP ส่งกลับมาแบบตรง ๆ ยังอธิบายไม่พอ แต่น่าจะหมายความว่าเป็น API อย่าง api.cercadating.com/otp/ ถ้าเดาหมายเลขโทรศัพท์ได้ ก็จะรับโค้ด OTP ของเบอร์นั้นได้ แม้ไม่ได้เป็นเจ้าของหมายเลขนั้น
    อีกอย่าง เขาบอกว่าใช้สคริปต์ที่หยุดเมื่อไม่เจอผู้ใช้ที่ถูกต้องใน ID ต่อเนื่อง 1,000 รายการ แล้วพบผู้ใช้ 6,117 คน, 207 คนที่ใส่ข้อมูลบัตรประจำตัว, และ 19 คนที่อ้างว่าเป็นนักศึกษา Yale แต่ไม่แน่ใจว่าผู้เขียนรู้หรือไม่ว่านี่อันตรายแค่ไหน โดยพื้นฐานแล้วคล้ายกับวิธีที่ weev เจาะ AT&T และเขาก็ต้องเข้าคุก[0]
    แม้จะเป็นบริษัทที่ใหญ่กว่าและการรั่วไหลที่ใหญ่กว่า แต่ผมคงไม่ออกมาคุยโวต่อสาธารณะว่าตัวเองใช้ช่องโหว่ด้านความปลอดภัยเข้าถึงข้อมูลของคนหลายพันคนโดยไม่ได้รับอนุญาต ไม่ได้จะตัดสินเรื่องศีลธรรม และคิดว่านักวิจัยความปลอดภัยควรมีพื้นที่ในการแจ้งเตือน แต่กฎหมายค่อนข้างเสียเปรียบต่อนักวิจัยความปลอดภัยมาก
    [0] https://en.wikipedia.org/wiki/Goatse_Security#AT&T/iPad_emai...

    • มีการพูดถึงการเดาหมายเลขโทรศัพท์ และบอกว่า API call ที่ส่ง OTP นั้น คืนค่า OTP กลับมา แบบตรงตัว
    • ถ้าอ่านคำฟ้องเดิมในคดี Auernheimer จะเห็นว่าอัยการมี หลักฐานเจตนา ในวงกว้าง ซึ่งกรณีนี้น่าจะไม่มี
      จำเลยในคดีนั้นยังถูกกล่าวหาว่าเผยแพร่ข้อมูลระบุตัวบุคคลพื้นฐานด้วย แต่กรณีนี้ดูเหมือนไม่ได้เกิดเรื่องแบบนั้น

  • เคยเจอเรื่องคล้ายกันกับแอปหาคู่อีกแอป แต่ฝั่งนั้นไม่ตอบกลับเลย สุดท้ายเพื่อดึงความสนใจของผู้ก่อตั้ง ผมเลยเปลี่ยนข้อความแนะนำตัวของเขาเป็นประโยคว่า “ติดต่อกลับมาหน่อย” แล้วเขาก็กู้คืนจากแบ็กอัป
    หลายปีต่อมาเห็นโฆษณาบน Instagram เลยลองตรวจดูว่าปัญหายังอยู่ไหม ปรากฏว่ายังอยู่ โครงสร้างคือแค่รู้ API endpoint ที่หาได้ง่ายผ่านแอป-พร็อกซี-เซิร์ฟเวอร์ ใครก็มีสิทธิ์แอดมินเต็มรูปแบบและเข้าถึงข้อความทั้งหมด การแมตช์ และอื่น ๆ ได้
    ชักคิดว่าควรกลับไปลองอีกสักครั้งไหม

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

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

    • ข้อมูลหนังสือเดินทางหรือบัตรประจำตัวอื่น ๆ ไม่มีเหตุผลใดเลยที่ต้องเปิดเผยต่อสาธารณะหลังจากกรอกเข้าไปแล้ว แม้จำเป็นต้องดึงข้อมูลผ่าน API เพื่อแสดงใน UI ก็ไม่จำเป็นต้องรวมเลขหนังสือเดินทาง/เลขบัตรประจำตัวเต็ม ๆ และอย่างน้อยควรปิดบังให้ส่งมาแค่ตัวเลขท้าย ๆ เท่านั้น
      ถ้าเป็นเว็บหาคู่ API แค่คืนค่าสถานะบัตรประจำตัวเป็นบูลีน verified/not-verified หรือค่า enum อย่าง ‘not-verified’, ‘passport’, ‘drivers-license’ ก็เพียงพอแล้ว ไม่มีความจำเป็นจริง ๆ ที่จะแสดงรายละเอียดให้ไคลเอนต์/UI เห็น
      กรณีอย่างแอปสายการบินที่ต้องเลือกเอกสารระบุตัวตนเพื่อวัตถุประสงค์ด้านตรวจคนเข้าเมือง อาจเป็นข้อยกเว้นที่แสดงข้อมูลได้มากขึ้น แต่ก็ควรเป็นแบบแอป United ที่แสดงแค่เลขท้ายไม่กี่หลักของหนังสือเดินทาง หวังว่าแม้แต่ API ภายในก็จะส่งมาแค่นั้น
    • รัฐบาลสหราชอาณาจักรกำลังพยายามอย่างหนักที่จะบังคับให้เว็บไซต์โป๊ต้องมี การยืนยันตัวตน เพื่อเข้าถึง รอดูวันที่มันย้อนกลับมาระเบิดใส่หน้าพวกเขาเอง
    • ควรมี บริการยืนยันตัวตน ที่ปลอดภัยและเป็นส่วนตัวซึ่งดำเนินการโดยรัฐบาล
      หรือไม่ก็ให้หน่วยงานที่ “คล้ายรัฐบาล” อย่าง Apple หรือ Google รับหน้าที่ก็ได้
    • ดู GDPR ได้เลย
      https://en.wikipedia.org/wiki/General_Data_Protection_Regula...
    • ไม่ได้ใช้บริการยืนยันตัวตนของบุคคลที่สามหรือ? ปกติแอปต่าง ๆ ก็จัดการกันแบบนั้นนี่นา คงไม่ใช่ว่าบริการบุคคลที่สามแบบนั้นส่ง ต้นฉบับบัตรประจำตัว อย่างรูปภาพจริงกลับมาให้แอปตรง ๆ หรอกนะ?

  • การที่การตอบกลับของ API สำหรับคำขอ คืนค่า OTP กลับมานั้นไม่สมเหตุสมผลเลย ทำไมถึงทำแบบนั้นนะ?

    • อาจทำเพื่อให้ UI ตรวจสอบได้ว่าค่าที่ผู้ใช้กรอกถูกต้องหรือไม่
      ถ้าไม่คิดเรื่องความปลอดภัย นี่ก็เป็นวิธีแก้ที่ดูสมเหตุสมผลและชัดเจนมาก แอปหาคู่เป็นหนึ่งในประเภทแอปที่อันตรายที่สุดในการสร้าง เพราะโดยธรรมชาติมีข้อมูลระบุตัวบุคคลจำนวนมาก และนี่ก็แย่มาก
    • อาจเป็นไปได้ว่าสร้างและบันทึก OTP แล้วคืนค่าการตอบกลับจากฐานข้อมูลหรือแคชอะไรสักอย่างมาแบบตรง ๆ
      ใน proof of concept หรือ MVP ที่ทำเร็ว ๆ มักใช้โมเดลที่บันทึกเป็นการตอบกลับ API ตรง ๆ เพื่อประหยัดเวลา จึงพลาดได้ง่าย
    • เป็นเคล็ดลับง่าย ๆ วิธีหนึ่งในการตัดค่าใช้จ่ายฐานข้อมูล
    • ลด HTTP request ได้หนึ่งครั้ง แถมประสบการณ์ผู้ใช้ก็เร็วขึ้น มีอะไรให้ไม่ชอบล่ะ?
      ตอน API ใหม่ของ Pinterest ออกมา มันกำลังโปรยข้อมูลผู้ใช้ทั้งหมดให้ทุกแอปที่ใช้ OAuth integration อยู่ และยังรวมถึง ค่าลับสำหรับการยืนยันตัวตนสองขั้นตอน ด้วย ผมรายงานไปและได้รางวัลบั๊กบาวน์ตี แต่เรื่องแบบนี้ยังเกิดขึ้นได้แม้กับ API ของบริษัทใหญ่ที่ควรรู้ดีกว่านี้
    • ดูเหมือนว่า OTP ถูกส่งมาใน “การตอบกลับที่ทริกเกอร์รหัสผ่านแบบใช้ครั้งเดียว”
      อาจเป็นความผิดของเฟรมเวิร์ก เป็นไปได้ว่าโครงสร้างคือเอาอ็อบเจกต์ที่จะใส่ลงฐานข้อมูลไป serialize โดยตรงจาก ORM หรือระบบจัดเก็บอื่น แล้วส่งกลับเป็น HTTP response

  • https://yaledailynews.com/blog/2025/04/24/yale-student-expos...
    เป็นบทความอีกชิ้นเกี่ยวกับเรื่องนี้

    • “นักพัฒนาควรใช้แนวปฏิบัติที่ดี แต่ก็อาจยังไม่เพียงพอ การรักษาข้อมูลให้ปลอดภัยเป็น ปัญหาที่ยังไม่มีคำตอบ” อ๋อ อย่างนั้นเอง ก็คงช่วยไม่ได้สินะ

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

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

  • ถ้า “ไม่ได้รับการตอบกลับใด ๆ” ก็ถึงเวลาที่ควรแจ้งว่า หากยังคงเงียบต่อไป จะเปิดเผยช่องโหว่หลังผ่านไป 90 วัน

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