ใช้ 4G ในการยืนยันเบอร์ผู้ใช้งาน ปลอดภัยจริงหรือ ?
จะเห็นได้ว่ามีผู้ให้บริการแอปบางราย บังคับให้เราใช้เบอร์โทรศัพท์เคลื่อนที่เพื่อยืนยันตัวตน ก่อนจะไปดูกันว่าปลอดภัยหรือไม่ ไปดูกันก่อนว่ามันทำงานอย่างไร
ซึ่งกระบวนการที่จะเพิ่มข้อมูลเข้าในจะต้องเป็น http protocol ซึ่งไม่มีการเข้ารหัส และการไม่ถูกเข้ารหัสนี้สามารถทำให้คนที่อยู่ระหว่างทางสามารถที่จะปลอมแปลง request และ response ได้
- ต่อไปนี้จะเรียก ผู้ให้บริการโทรศัพท์เคลื่อนที่ว่า “operator”
ตัวอย่าง http request ออกจากมือถือคือ
GET /what-is-my-phone-number HTTP/1.1
Host: api.someservice.co.th
User-Agent: myCustomHTTPClient/0.0.1
Accept: */*และ operator ทำการตรวจสอบแล้วว่า request ที่ส่งมาถูกต้อง เช่นอาจจะตรวจอบแค่ host และ path ทาง operator จะทำการแปะเบอร์มาให้ พอขาออกจาก operator จะเพิ่ม header ตัวนึงที่อาจแตกต่างกันออกไปในแต่ผู้ให้บริการ เช่น
- X-UP-CALLING-LINE-ID
- X-NOKIA-MSISDN
- X-MSISDN
เมื่อ request นั้นถึงทางระบบของผู้ให้บริการแอป ทางก็จะได้รับว่า request นั้นเป็น
GET /what-is-my-phone-number HTTP/1.1
Host: api.someservice.co.th
User-Agent: myCustomHTTPClient/0.0.1
Accept: */*
X-Nokia-msisdn: 66812345678สังเกตุว่า request เปลี่ยนไป มี header ที่ชื่อว่า X-Nokia-msisdn เพิ่มเข้ามา ตรงนี้ ระบบของแอปก็จะแกะจาก header ที่ได้ตกลงกันไว้ ก็จะทราบได้ว่าเบอร์เป็นเบอร์ 66812345678 หรือที่บ้านเราเรียก 081-234-5678 นั่นเอง
แล้ววิธีการนี้ใช้ยืนยันตัวได้อย่างไร
- เมื่อโทรศัพท์และ SIM เราทำการยืนยันตัวตนกับสถานีฐานของโครงข่ายแล้ว ทางโครงข่ายจะรู้จักเราทันที
- ของจากตัวผู้ให้บริการโครงข่ายแล้ว ไม่ควรจะมีใครเข้าไป เปลี่ยนแปลงแก้ไขข้อมูลได้
- ถ้าเราอยากปลอมเป็นเบอร์ใด ๆ ก็ตามต้องมี SIM นั้น ๆ อยู่ในมือ เพราะการปลอม SIM ยากมาก
จากเอกสารในงาน DefCamp 2012 ได้รายงานว่า
- ช่องโหว่นี้ถูกค้นพบใน มกราคม 2012
- รายงานแรกถูกแจ้งไปยัง operators ต่าง ๆ ในโซนยุโรปในเดือนมีนาคม
- มีการรายงานไป GSMA ในเดือนเมษา หลังจากได้รับการยืนยันจากผู้ให้บริการ
- operators ทำการปิดช่องโหว่ภายหลังไม่นาน
- operators ส่วนใหญ่ได้ทำการปิดช่องโหว่นี้เรียบร้อยแล้ว เหลือแต่ 3rd party ที่ใช้ระบบนี้ และยังพัฒนาได้ไม่ดีพอ
แก้ปัญหาอย่างไร ไม่ช่วยให้ความปลอดภัยมากขึ้น
- ใช้ HTTP POST เพื่อส่งข้อมูลใน body แทน header
- ตรวจสอบ header, body เพิ่มเติม เพราะผู้ไม่หวังดีก็สามารถดักจับและลองเลียนได้ไม่ยาก
- ไม่ตอบอะไรกลับมาที่แอป แต่ทำให้แอปต้องส่งเลขบางอย่างไปแทน เช่นเลข
tokenซึ่งtokenนี้เองอาจไม่ได้ระวัง เพราะใช้เป็นเลขเดียวกับตอนที่วิ่งผ่าน HTTPS ซึ่งเข้ารหัส อาจทำให้โดนขโมยtokenระหว่างทางได้ (session hijack)
คำแนะนำ
- อย่าเชื่อเบอร์ที่มาจาก header
- สร้าง
tokenมาอีกตัวหนึ่งเพื่อใช้กับ api endpoint นี้โดยเฉพาะ และรู้กับระหว่าง แอป และ ระบบใน session นั้น ๆ ด้วย - หรือถ้าตกลงกับ operator ได้มากเราจะตกลงวิธีการ handshake แบบพิเศษอื่น ๆ เพิ่มเติมได้ เช่นให้จัดทำ api ที่เป็น https ให้ หรือทำการ request ไปที่ operator แล้วรับ
tokenกลับมาที่แอป แล้วให้แอปยิงไปหา api ของเรา แล้ว api ของเราเอาtokenไปตรวจสอบกับ operator อีกรอบ ซึ่ง api ของเราต้องทำการ authen กับ operator อย่างถูกต้อง - เพื่อให้ดักข้อมูลได้ยากขึ้น ให้แอปทำการตรวจสอบก่อนว่าได้ทำการเชื่อมต่อเครือข่ายโทรศัพท์แล้ว และไม่ได้เชื่อมต่อ WiFi จึงยิง api ตรวจสอบเบอร์
- เชื่อมต่อตรงกับผู้ให้บริการ เพื่อไม่ให้มีการดัก หรือแก้ไขข้อมูลระหว่างทาง
- ตรวจสอบว่ามีการดีบัคโทรศัพท์ หรือแอปอยู่หรือไม่ เพื่อป้องกันการดูพฤติกรรมแอป ถ้าใช่อาจจะแสดงข้อความเตือน หรือปิดแอปในทันที
- ทำการ obfuscate ตัวโค้ด เพื่อให้ยากแก่การ reverse engineer
อ่านเพิ่มเติม
บทความเดิม ยอมให้ iOS แอปใช้งาน http ได้ แบบเจาะจงโดนเมน หรือยอมให้ใช้วิธีการเข้ารหัสแบบเก่า ซึ่งได้แนะนำวิธีการเปิดใช้ http แบบที่ปลอดภัยมากขึ้นด้วย
และการทำ certificates pinning กับ Alamofire แบบที่ผู้ไม่ประสงค์ดีจะแกะยากขึ้นนิดหน่อย (มั้ง)
ถ้าใครอยู่กับ codebase หรือวิธีการแบบที่กล่าวมา ก็ให้ลองเชคกันดูครับว่า ที่ทำกันอยู่ยังปลอดภัยอยู่หรือ ไม่ หรือมีวิธีการที่ดีกว่าแล้ว
ถ้าใครมีข้อแนะนำเพิ่มเติม บอกได้เลยนะครับ จะขอบพระคุณมาก
อ้างอิง Vimeo, SlideShare, Mulliner, Github
สวัสดีครับ
