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

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

---

ความสำคัญที่สตาร์ทอัพต้องให้ความสำคัญกับความปลอดภัยอย่างจริงจัง

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

ขั้นตอนการค้นพบช่องโหว่และการแจ้งเตือน

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

ช่องโหว่ OTP และขั้นตอนแฮ็กแบบง่ายๆ

• ระหว่างกระบวนการล็อกอินของแอป รหัสผ่านใช้ครั้งเดียว (OTP) ถูกเปิดเผยตรงๆ ใน network response
• ผู้โจมตี เพียงรู้หมายเลขโทรศัพท์ก็สามารถเข้าถึงบัญชีได้ง่ายและรวดเร็ว

การเข้าถึง API endpoint และการรั่วไหลของข้อมูล

• ยืนยันได้ว่าสามารถเข้าถึงทุกเส้นทางของ API ได้เพียง ใส่ app version header
• มีการเปิดเผย เอกสาร OpenAPI ทั้งหมด ผ่าน endpoint /docs
• สามารถใช้เครื่องมืออย่าง Burp Suite เพื่อ ฉีด app header และโทเค็นอัตโนมัติ แล้วควบคุม API ได้
• บาง endpoint เปลี่ยนแค่ business logic แต่ endpoint สำคัญหลายจุดส่งคืนข้อมูลส่วนบุคคลอย่างร้ายแรง
• ผ่าน user/{user_id} เป็นต้น สามารถเข้าถึงข้อมูลส่วนบุคคล หมายเลขโทรศัพท์ และแม้กระทั่งยึดบัญชีได้

สถานะการเปิดเผยข้อมูลส่วนบุคคลและข้อมูลเอกสารยืนยันตัวตนจำนวนมาก

• ผ่าน endpoint ข้อมูลส่วนบุคคล มีการเปิดเผย PII จำนวนมาก เช่น เพศ เมือง วันเกิด อีเมลมหาวิทยาลัย และข้อมูลเอกสารยืนยันตัวตน
• โดยเฉพาะฟิลด์เกี่ยวกับเอกสารยืนยันตัวตน เช่น national_id_verified ทำให้เข้าถึงไฟล์อ่อนไหวได้ เช่น ภาพหนังสือเดินทางและบัตรประชาชน
• จากสคริปต์โจมตีพบว่าสามารถ ระบุตัวผู้ใช้ได้ 6,117 คน และในจำนวนนี้ 207 คนได้กรอกข้อมูลเอกสารยืนยันตัวตนแล้ว
• มีบางบัญชีที่แสดงว่าเป็นสังกัดมหาวิทยาลัยเยล
• เมื่ออ้างอิงจาก Instagram ทางการของ Cerca นี่เทียบได้กับ ผู้ใช้ 10,000 คนในสัปดาห์แรก

ความเสี่ยงของความเสียหายจริงและความร้ายแรงของปัญหา

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

บทสรุปและความจำเป็นของวัฒนธรรมความปลอดภัยที่มีความรับผิดชอบ

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

[GN⁺]

ความคิดเห็นจาก Hacker News

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

  • ฉันไม่เห็นด้วยอย่างมาก การบอกว่า "ไม่รู้" ไม่ใช่ข้อยกเว้น ความจริงที่ว่าพวกเขาเดินหน้าทั้งที่ไม่รู้ยิ่งเป็นปัญหาใหญ่กว่าอีก มันเหมือนคนขับที่ยังอ่อนประสบการณ์ไม่มีใบขับขี่แล้วก่ออุบัติเหตุทำให้คนบาดเจ็บ
  • ฉันก็กดลิงก์ต้นทางเพราะอยากหาข้อมูลเกี่ยวกับ Cerca แล้วพบว่าเป็นบทความเดือนเมษายน 2025 ที่ชมแอปซึ่งเพิ่งสร้างได้ราวสองเดือน มันให้ความรู้สึกเหมือนขยะที่ LLM มโนขึ้นมา ตามที่ OP บอกว่าได้ติดต่อทีม Cerca ตั้งแต่เดือนกุมภาพันธ์ งั้นก็อาจเป็นช่องโหว่ที่พบตั้งแต่เปิดตัว หรือมีอะไรบางอย่างแปลก ๆ อยู่ดี ถึงอย่างนั้นก็ยังมีบริบทว่าเป็น "ช่องโหว่อายุสองเดือน" + "บริการที่นักศึกษาสร้างและมีอายุสองเดือน"
  • ถ้าแอปออกภายใต้ชื่อ "Cerca Applications, LLC" ฉันไม่แน่ใจว่าคนทั่วไปจะรู้ได้อย่างไรว่าเราควรผ่อนปรนเพราะมันเป็นแอปที่นักศึกษาสร้าง
  • ฉันคิดว่านักศึกษากลุ่มนี้ควรไปเรียนอย่างอื่น
  • นี่ฟังดูเหมือนเป็นการแก้ตัวให้พวกเขา ไม่ควรเป็นตรรกะว่าแค่เพราะเป็นแอปที่นักศึกษาทำก็ต้องปล่อยผ่าน The Facebook เองก็เริ่มจากนักศึกษาเหมือนกัน ประวัติการละเมิดความเป็นส่วนตัวและการเพิกเฉยต่อความปลอดภัยของข้อมูลของ Meta ก็ยาวนานอยู่แล้ว เพราะงั้นพฤติกรรมแบบนี้จึงไม่ควรถูกแก้ตัว และฉันคิดว่าจะแก้ได้ก็ต่อเมื่อมีการกำกับดูแลและปรับจริงจัง โดยไม่สนว่าอายุหรือประสบการณ์ของผู้ก่อตั้งเป็นอย่างไร
  • ถ้าจะจัดการข้อมูลอ่อนไหวอย่างหนังสือเดินทางและรสนิยมทางเพศ อย่างน้อยที่สุดก็ควรตอบสนองเมื่อมีคนเตือนว่าข้อมูลกำลังรั่วไหล นี่เป็นหายนะเต็มรูปแบบ และการขาดความปลอดภัยในระดับนี้ยอมรับไม่ได้อย่างสิ้นเชิง
  • ถ้าไม่รู้อะไรเลยเรื่องความปลอดภัยของแอป ก็ไม่ควรสร้างแอปเลย ฉันอาจจะพูดด้วยอารมณ์ แต่พอเห็นเพื่อนใช้แอปหาคู่แล้วคิดว่าข้อมูลของพวกเขาอาจถูกเปิดเผย มันแย่มาก คนที่สร้างควรรู้สึกละอายใจ และก็ควรละอายใจด้วยที่ไม่ตอบนักวิจัยด้านความปลอดภัย ถ้าเป็นฉันแล้วโดนเมินแบบนั้น ฉันคงเขียนบทเปิดโปงที่ตรงไปตรงมามากกว่านี้ หยุดสร้างแอปเถอะ ได้โปรด

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

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

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

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

• ตัวบทความเองทำให้รู้สึกค่อนข้างสับสน มันอธิบายเหมือนว่า API ที่รับ OTP (รหัสผ่านใช้ครั้งเดียว) ง่ายมากจนตัว OTP ถูกเปิดเผยตรง ๆ ใน response ของเซิร์ฟเวอร์ ทำให้ใครก็ตามที่รู้หมายเลขโทรศัพท์สามารถเข้าถึงบัญชีได้ ดูเหมือน API จะเป็นแค่ otp/หมายเลขโทรศัพท์ และใส่ OTP กลับมาใน response ดังนั้นถ้าเดาหมายเลขโทรศัพท์ถูกก็จะได้โค้ดทันที แล้วก็มีการบอกว่าใช้สคริปต์ไล่เลข user ID และหยุดเมื่อเจอ ID ว่างติดกัน 1,000 ครั้ง ทำให้ยืนยันได้ว่ามีผู้ใช้ทั้งหมด 6,117 คน มีข้อมูลบัตรประจำตัว 207 รายการ และมีนักศึกษา Yale 19 คน แต่การเข้าถึงข้อมูลส่วนบุคคลของคนอื่นโดยไม่ได้รับความยินยอมในระดับนี้คล้ายกับกรณีที่ weev แฮ็ก AT&T แล้วติดคุกในอดีต แม้ขนาดจะเล็กกว่า แต่งานวิจัยแบบนี้ก็มีความเสี่ยงทางกฎหมาย และน่ากังวลว่าผู้เขียนอาจไม่ตระหนักว่าสภาพแวดล้อมทางกฎหมายไม่ได้คุ้มครองนักวิจัยด้านความปลอดภัย

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

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

  • มีข้อเสนอว่าควรติดต่อไป โดยระบุว่าคุณเป็นนักพัฒนาที่มีความรับผิดชอบ แล้วเปิดเผยเฉพาะประเด็นปัญหาเท่านั้นก็น่าจะดี

• ฉันคิดว่าการเก็บข้อมูลอ่อนไหวอย่างหนังสือเดินทางหรือที่อยู่ในแอปควรเป็นเรื่องที่ต้องคิดแล้วคิดอีกจริง ๆ ไม่ควรถูกมองข้ามว่า "ก็เป็นแอปที่นักศึกษาสร้างนี่" แล้วปล่อยผ่านไป

  • รัฐบาลสหราชอาณาจักรกำลังพยายามบังคับให้เว็บไซต์ลามกต้องใช้บัตรประจำตัวเพื่อเข้าถึง ฉันรอดูอยู่ว่าผลลัพธ์จะออกมาแบบไหน
  • ถ้ารับข้อมูลบัตรประจำตัวอย่างหนังสือเดินทางเข้ามาแล้ว หลังจากกรอกเสร็จก็ไม่ควรมีความจำเป็นต้องเปิดเผยออกภายนอกอีกเลย ถ้าต้องมี API เพื่อแสดงข้อมูลบัตรใน UI ก็คืนมาแค่เลขท้ายไม่กี่หลักก็พอ ถ้าเป็นแอปหาคู่ แค่ส่งสถานะการยืนยันตัวตนกลับมาเป็น boolean หรือ enum (ยังไม่ยืนยัน/หนังสือเดินทาง/ใบขับขี่) ก็น่าจะพอแล้ว ระบบที่ต้องเลือกตามเอกสารแต่ละใบแบบแอปสายการบินอาจเป็นข้อยกเว้น แต่ถึงอย่างนั้น อย่างแอปของ United ก็ยังแสดงแค่เลขท้ายไม่กี่หลัก ฉันอยากให้ API ภายในถูกจำกัดแบบนั้นเหมือนกัน
  • มีการแชร์ลิงก์ให้อ้างอิง GDPR (กฎหมายคุ้มครองข้อมูลส่วนบุคคลของสหภาพยุโรป)
  • ฉันคิดว่าเราน่าจะต้องมีบริการยืนยันตัวตนที่ปลอดภัยและเป็นส่วนตัวซึ่งดำเนินการโดยรัฐบาล หรือไม่ก็ให้บริษัทอย่าง Apple หรือ Google ที่ทำตัวแทบจะเหมือนรัฐบาลรับหน้าที่นี้ไป
  • ปกติแล้วก็มักใช้บริการยืนยันตัวตนของบุคคลที่สามกันอยู่แล้ว แต่ฉันก็สงสัยว่าบริการพวกนั้นส่งภาพบัตรประจำตัวจริง ๆ เข้าแอปด้วยหรือเปล่า

• การคืน OTP กลับมาใน API response ตรง ๆ เป็นอะไรที่เหลือเชื่อมาก ฉันนึกไม่ออกว่าทำไปทำไม

  • เขาน่าจะทำเพื่อให้ UI เอาไปเทียบกับค่าที่ผู้ใช้กรอกได้ทันที ถ้าไม่คิดเรื่องความปลอดภัย มันอาจฟังดูเข้าท่า แอปหาคู่ต้องใช้ข้อมูลส่วนตัวในวงกว้างมาก ความผิดพลาดแบบนี้จึงน่ากลัวสุด ๆ
  • วิธีนี้ช่วยลดค่าใช้จ่ายฐานข้อมูลได้ในทันที
  • พอสร้าง OTP แล้วก็ส่ง response จาก DB หรือ cache กลับไปตรง ๆ ถ้าทำ POC หรือ MVP แบบลวก ๆ ก็อาจพลาดใช้โมเดลแนวนี้ได้ง่าย
  • ดูเหมือน OTP จะถูกเปิดเผยตรง ๆ อยู่ใน "response ต่อคำขอส่งรหัสผ่านใช้ครั้งเดียว" เรื่องนี้อาจเกิดจาก framework serialize ทั้ง DB object แล้วส่งกลับทาง HTTP ทั้งก้อน
  • มันดูดีเผิน ๆ เพราะประหยัด HTTP request ไปหนึ่งครั้งและทำให้ UX เร็วขึ้น Pinterest เองก็เคยมี API เก่าที่เปิดเผยข้อมูลทุกอย่างรวมถึง 2FA secret ฉันเคยรายงานเรื่องนั้นและได้รางวัลตอบแทน แต่ความผิดพลาดแบบนี้ก็เกิดกับบิ๊กเทคได้เหมือนกัน
  • ฉันก็ไม่เข้าใจเหมือนกัน คิดได้แค่ว่าเป็นความผิดพลาดที่เกิดจากการพยายามทำให้การสร้างฟอร์มง่ายขึ้น

• มีการแชร์ลิงก์ไปยังอีกบทความที่เกี่ยวข้องจาก Yale Daily News

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

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

• เพิ่งมารู้จักเครื่องมือชื่อ Charle's Proxy บน iOS ตอนนี้เอง เมื่อก่อนฉันเคยทำ pentesting ด้วยการค้นหาสตริงในไบนารีแอปโดยตรง สำหรับการวิเคราะห์แอปที่มีเฉพาะบน iOS มันน่าจะช่วยได้มากจริง ๆ

  • เป็นเครื่องมือที่ใช้ได้ดี แนะนำเลย (แต่ถ้ามี SSL pinning ก็ใช้ไม่ได้นะ)