ความปลอดภัยแอป Mobile Banking — สิ่งที่ธนาคารและผู้ใช้ต้องรู้

การให้บริการ Mobile Banking มีความเสี่ยงทั้งจากมัลแวร์และการสวมรอยทำธุรกรรม ธนาคารแห่งประเทศไทย (ธปท.) ออก ประกาศที่ 4/2568 เพื่อกำหนดมาตรฐานขั้นต่ำในการป้องกัน Unauthorized Payment Fraud และรักษาความมั่นคงปลอดภัยของบริการ.[1]

ข้อกำหนด ธปท. ด้าน Mobile Banking Security

ประกาศ ธปท. ที่ 4/2568 — สาระสำคัญ

ข้อ 4 ของประกาศกำหนดขอบเขตเป็น สถาบันการเงินตามกฎหมายว่าด้วยธุรกิจสถาบันการเงินทุกแห่ง ไม่ควรขยายความว่าครอบคลุมสถาบันการเงินเฉพาะกิจหรือผู้ให้บริการ E-Money ทุกแห่งโดยอาศัยประกาศฉบับนี้เพียงฉบับเดียว.[1]

ข้อกำหนดหลัก:

เชื่อมกับมาตรฐานสากล

ตารางข้างต้นสรุปข้อ 5.3.1 และ 5.3.2 ไม่ใช่ข้อกำหนดทั้งหมด; เช่น การยืนยันใบหน้ามีข้อยกเว้นสำหรับข้อจำกัดของผู้ใช้และธุรกรรมความเสี่ยงต่ำตามเงื่อนไขประกาศ.[1]

OWASP MASVS ใช้จัดกลุ่มการตรวจ เช่น STORAGE, AUTH, NETWORK, CODE และ RESILIENCE โดยแยก Testing Profiles ออกจากตัวมาตรฐาน จึงไม่ควรกล่าวว่า MASVS ปัจจุบันบังคับแอปธนาคารทุกแห่งผ่าน L2 หรือมีเพียงระดับ L1/L2/R.[3]

ประเด็นความปลอดภัยที่ควรประเมินในแอปธนาคาร

ตัวอย่างประเด็นที่ควรทดสอบตามพื้นที่ควบคุมของ MASVS มีดังต่อไปนี้ ไม่ใช่ผลสำรวจความถี่หรือการเปิดเผยผลทดสอบธนาคารไทย.[3]

1. Certificate Pinning Bypass

Certificate Pinning เพิ่มข้อจำกัดว่าการเชื่อมต่อต้องใช้ Certificate หรือ Public Key ที่อนุญาตไว้ ตัวอย่าง Android Network Security Configuration ตรวจ Pin จาก Hash ของ Public Key ในสาย Certificate ไม่ใช่เพียงตรวจชื่อ Server.[5]

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

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

2. Reverse Engineering

การวิเคราะห์แอปอาจเปิดเผยโครงสร้างหรือข้อมูลที่ฝังอยู่ใน Binary แต่ไม่ได้คืน Source Code ต้นฉบับได้ครบเสมอ Code Obfuscation เพิ่มความยากในการทำความเข้าใจโค้ด ไม่ใช่ที่เก็บ Secret ที่เชื่อถือได้ OWASP จัดความทนทานต่อ Reverse Engineering และ Tampering ไว้ใน MASVS-RESILIENCE.[3]

ตัวอย่างประเด็นที่ควรทบทวน:

• Secret หรือ Encryption Key ที่ฝังอยู่ในแอป และขอบเขตสิทธิ์ของ API Key ที่ถูกเปิดเผย
• Business Logic สำคัญที่เชื่อการตัดสินใจฝั่ง Client โดยไม่มีการตรวจซ้ำ
• ความสามารถในการตรวจแอปดัดแปลงและกระบวนการรับมือแอปปลอม

3. Insecure Local Storage

ควรสำรวจข้อมูลสำคัญที่จัดเก็บบนอุปกรณ์ ทั้ง Token, PIN และข้อมูลส่วนบุคคล โดย ธปท. กำหนดให้หลีกเลี่ยงการจัดเก็บ หากจำเป็นต้องเข้ารหัสอย่างปลอดภัยและทำลายเมื่อสิ้นสุดการใช้งานข้อมูล.[1] ตัวอย่างตำแหน่งที่ควรตรวจ:

• SharedPreferences (Android) / UserDefaults (iOS) ที่เก็บ Token หรือ PIN
• SQLite Database ที่ไม่ Encrypt
• Log File ที่พิมพ์ข้อมูลสำคัญออกมา

4. Weak Biometric Implementation

ต้องแยก Local Biometric ของระบบปฏิบัติการ ออกจาก Face Comparison สำหรับยืนยันธุรกรรม ข้อกำหนด Face Comparison ร่วมกับ Presentation Attack Detection ในประกาศ ธปท. เป็นบริบทหลัง ไม่ใช่ข้อสรุปว่าการยืนยันชีวมิติทุกแบบต้องให้แอปสร้าง Liveness เอง.[1]

ตัวอย่างจุดทบทวนที่แนะนำ:

• ผลยืนยันตัวตนผูกกับการอนุญาตงานหรือการใช้ Key ที่จำเป็นหรือไม่ ไม่ใช่เปลี่ยนเพียงหน้าจอ
• กระบวนการยืนยันใบหน้าตรวจการปลอมแปลงตามความเสี่ยงและข้อกำหนดหรือไม่
• Fallback, การจำกัดความพยายาม และการกู้คืนบัญชีมีการควบคุมเหมาะสมหรือไม่ ไม่ตัดสินจากจำนวนหลักของ PIN เพียงอย่างเดียว

5. API Vulnerabilities

ตัวอย่างข้อผิดพลาดฝั่ง Backend ที่ควรรวมในแผนตรวจ ไม่ใช่การยืนยันว่าธนาคารใดมีช่องโหว่เหล่านี้:

• Broken Object Level Authorization (BOLA) — เข้าถึงข้อมูลบัญชีคนอื่น
• Mass Assignment — แก้ไข Field ที่ไม่ควรแก้ได้
• การจำกัดความพยายามไม่เพียงพอ — เพิ่มความเสี่ยงจากการเดา OTP หรือ PIN โดยต้องพิจารณาอายุ Token และ Control อื่นร่วมด้วย

RASP คืออะไร — ป้องกันแอปอย่างไร?

RASP (Runtime Application Self-Protection) สำหรับมือถือเป็นชั้นตรวจจับและตอบสนองต่อภัยขณะแอปทำงาน ตามคำอธิบายของ Guardsquare มุ่งลดความเสี่ยงจาก Tampering และ Dynamic Analysis; ไม่ได้ทดแทนการตรวจสิทธิ์ธุรกรรมฝั่ง Server.[6]

ตัวอย่างความสามารถที่ควรประเมินใน RASP:

ความสามารถต่อไปนี้ขึ้นอยู่กับผลิตภัณฑ์ ระบบปฏิบัติการ และการตั้งค่า ไม่ใช่คุณสมบัติรับประกันของ RASP ทุกตัว

การเลือก RASP

ควรทดสอบการรองรับแพลตฟอร์ม ผลกระทบต่อผู้ใช้ และการตอบสนองต่อภัยกับแอปจริง เอกสาร Guardsquare เป็นตัวอย่างคำอธิบาย RASP จากผู้ผลิต ไม่ใช่หลักฐานส่วนแบ่งตลาดหรือการใช้งานของธนาคารไทย.[6]

มาตรการป้องกันและข้อควรตรวจสอบ

Root/Jailbreak Detection

ประกาศ ธปท. ข้อ 5.3.2(3.1) ไม่อนุญาตให้ใช้งานแอปบนอุปกรณ์ที่ตรวจพบ Root/Jailbreak.[1] ควรประเมินหลายสัญญาณร่วมกัน ทดสอบ False Positive บนอุปกรณ์ที่รองรับ และกำหนดแนวทางช่วยเหลือผู้ใช้เมื่อถูกจำกัดบริการ โดยไม่ถือว่าผลตรวจ Client เพียงจุดเดียวเป็นหลักฐานว่าอุปกรณ์ปลอดภัย

SSL Pinning

ประกาศ ธปท. ข้อ 5.3.2(1.3) กำหนด Secure Protocol และ Certificate Pinning หรือวิธีอื่นที่เทียบเท่า รวมทั้งเข้ารหัสข้อมูลสำคัญในระดับ Application Layer จึงไม่ควรสรุปว่าการเปิด TLS อย่างเดียวครบข้อกำหนดนี้.[1]

ข้อควรระวัง: Android Network Security Configuration รองรับ Pin ของ Public Key และแนะนำให้มี Backup Key หากเลือกใช้ Pinning การหมุน Certificate โดยใช้ Key เดิมอาจไม่ต้องเปลี่ยน Pin แต่การเปลี่ยน Key หรือ CA ต้องวางแผนล่วงหน้า มิฉะนั้นแอปอาจเชื่อมต่อไม่ได้.[5]

Code Obfuscation

ทำให้โค้ดอ่านเข้าใจยากขึ้นเพื่อลดความเสี่ยงจากการวิเคราะห์ ไม่ใช่ป้องกัน Reverse Engineering ได้เด็ดขาด ประกาศ ธปท. ยก Source Code Obfuscation เป็นตัวอย่างในข้อ 5.3.2(2.5).[1] เทคนิคที่ควรประเมินตามความเหมาะสม ได้แก่:

• Identifier Renaming — เปลี่ยนชื่อตัวแปร/ฟังก์ชันให้อ่านไม่ออก
• Control Flow Obfuscation — ทำให้ Logic ซับซ้อนขึ้น
• String Encryption — เข้ารหัส String ที่มีข้อมูลสำคัญ
• Resource Encryption — เข้ารหัสไฟล์ Resource

Anti-Tampering

ตรวจสอบ Integrity ของแอปทุกครั้งที่เปิด:

• ตรวจ Code Signing / APK Signature
• ตรวจ Checksum ของไฟล์สำคัญ
• ตรวจจับ Dynamic Instrumentation (Frida, Xposed)

ทำไม Pentest ยังสำคัญ?

แม้จะมี RASP และมาตรการอื่น Mobile Penetration Testing ยังช่วยประเมินช่องว่างของการป้องกัน โดยต้องกำหนดขอบเขตและความถี่ตามความเสี่ยง เพราะ:

1. ตรวจสอบมาตรการตามความเสี่ยง

ประกาศ 4/2568 กำหนดให้ติดตามดูแลและปรับปรุงความปลอดภัยตามมาตรฐานสากลและภัยคุกคามใหม่ ส่วนการออกแบบแผน Static/Dynamic Testing ควรใช้ MASVS/MASTG และเกณฑ์อื่นที่ใช้บังคับกับองค์กร ไม่อ้างว่าประกาศฉบับนี้ระบุวิธีทดสอบทั้งสามแบบหรือความถี่ Pentest ไว้โดยตรง.[1][3]

2. ตรวจความทนทานของ RASP ที่ติดตั้งจริง

ควรประเมินการตรวจ Integrity สภาพแวดล้อมเสี่ยง และการตอบสนองของแอปจริง รวมถึงกรณีตรวจไม่พบภัยหรือจำกัดผู้ใช้ปกติผิดพลาด ผู้ผลิต Guardsquare เองอธิบาย Testing และ Monitoring เป็นส่วนหนึ่งของวงจร Mobile App Security ไม่ใช่เพียงติดตั้ง RASP แล้วจบ.[6]

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

3. ช่องโหว่ใน Business Logic

การตรวจ Tampering ของ RASP ไม่ได้ยืนยันว่า Business Logic ฝั่ง Server ถูกต้อง ตัวอย่างเงื่อนไขที่ควรตรวจ ได้แก่:

• การโอนเงินเป็นจำนวนติดลบ
• การ Bypass ขั้นตอนการยืนยันตัวตน
• Race Condition ในการทำธุรกรรมพร้อมกัน

4. API Security

Backend API ต้องมีการตรวจสิทธิ์และข้อมูลฝั่ง Server รวมทั้ง Code Review, Security Testing และ Monitoring; Pentest เป็นส่วนหนึ่งของการประเมิน ไม่ใช่วิธีเดียว

สรุป

ความปลอดภัยของ Mobile Banking ต้องอาศัย การป้องกันหลายชั้น — แปลงข้อกำหนด ธปท. เป็น Control ที่ตรวจสอบได้ ใช้การป้องกันฝั่งแอปร่วมกับ Server-side Validation และ ทดสอบตามความเสี่ยง เพื่อค้นหาช่องว่าง ไม่มีผลิตภัณฑ์หรือผลทดสอบครั้งเดียวที่รับรองความปลอดภัยทั้งหมด

• บริการ Mobile Penetration Testing →
• Compliance: ธปท. i-Pentest →
• อ่านเพิ่ม: Pentest สำหรับธุรกิจการเงิน →

---

Sources

[1] บนอุปกรณ์เคลื่อนที่(Mobile Banking Security) สาหรับสถาบันการเงิน

[3] OWASP MASVS - OWASP Mobile Application Security

[5] Network security configuration  |  Security  |  Android Developers

[6] What is Runtime Application Self-Protection (RASP)? | Guardsquare