OWASP Mobile Top 10 2023
ตอนนี้ OWASP Mobile Top 10 2023 ได้คลอดออกมาเรียบร้อยแล้วแต่ยังอยู่ในช่วงเริ่มต้น(Initial Release) หลังจากไม่ได้ update มาตั้งแต่ปี 2016 ซึ่งในแต่ละข้อจะเป็นความเสี่ยงอะไรบ้างมาลองดูกันทีละข้อ
- M1: Improper Credential Usage
- M2: Inadequate Supply Chain Security
- M3: Insecure Authentication/Authorization
- M4: Insufficient Input/Output Validation
- M5: Insecure Communication
- M6: Inadequate Privacy Controls
- M7: Insufficient Binary Protections
- M8: Security Misconfiguration
- M9: Insecure Data Storage
- M10: Insufficient Cryptography
M1: Improper Credential Usage
เป็นปัญหาที่เกิดขึ้นจากการเก็บ credentials(ทั้ง Token, API key และ username/password) ไม่เหมาะสม เช่น
- Hardcoded Credentials การเขียน username และ password ไว้ใน source code
- Insecure Credential Transmission การส่ง credentials ไปใน network โดยที่ไม่มีการเข้ารหัส เช่น http หรือ ftp
- Insecure Credential Storage การเก็บ key ไว้ใน storage อื่นๆที่ไม่ใช่ keystore หรือ keychain
- Weak User Authentication เป็นการใช้ Authentication ที่ bypass ได้ง่าย
วิธีการป้องกัน
- Encrypt credentials ทุกครั้งเมื่อมีการรับ-ส่งผ่าน network
- อย่าเก็บ credentials ไว้ใน mobile ควรจะส่งคำสั่งไปยัง server ให้ server เป็นคนเก็บ credentials
- ใช้วิธีการ Authentication ที่แข็งแรง
- ทำการเปลี่ยน API key หรือ tokens บ่อยๆ
M2: Inadequate Supply Chain Security
ปัญหานี้เกิดจากการใช้ Thid-party components ที่ไม่มีความปลอดภัย ซึ่งจะส่งผลให้ attacker สามารถฝัง code ต่างๆจำพวก malware หรือ malicious code เข้ามาดึงเอา sensitive data ออกไปจากเครื่องได้ ซึ่งผลกระทบที่เกิดจากการใช้ components ที่ไม่ปลอดภัยจะมี
- Data breach ข้อมูลรั่วไหล
- Malware Infection ส่ง malware เข้ามาในเครื่อง
- Unauthorize Access สามารถเข้าใช้งานฟังก์ชั่น หรือ service ต่างๆที่ attacker ไม่มีสิทธิ
- System Compromise attacker สามารถเข้ามาควบคุมเครื่องได้ทั้งหมด รวมทั้งอาจทำให้ผู้ใช้งานไม่สามารถควบคุมเครื่องได้เลย
วิธีการป้องกัน
- ต้องมีการ review source code ในทุกๆ components เพื่อให้รู้ว่ามีช่องโหว่อยู่ใน components ไหนบ้าง
- ต้องมีการทำ code signing(เหมือนตอนเราจะนำ application ขึ้น play store หรือ apple store)
- เลือกใช้ components จาก third-party ที่มีความน่าเชื่อถือ
- ทำการ update หรือ patch application ให้เป็น version ใหม่ล่าสุด
- Monitor หรือ Scan หาช่องโหว่ของ Third-party
M3: Insecure Authentication/Authorization
ปัญหานี้เป็นการโจมตีที่อาจเกิดจากการ bypass authentication(เข้าไปใช้งานระบบโดยที่ไม่มีการ authen) หรืออาจเป็นการเข้าไปใช้งาน API ที่อยู่หลังบ้านโดยตรง ซึ่งผลกระทบจากการ bypass authentication คือ
- Reputation Damage สูญเสียชื่อเสียง เพราะ authentication ถือได้ว่าเป็นความน่าเชื่อถือของระบบ
- Information Theft ขโมยข้อมูลของผู้ใช้งานออกไป
- Fraud เกิดการโกง เช่น ผู้ใช้งานเข้าใช้งานระบบได้โดยไม่ต้องจ่ายเงิน
- Unauthorized Access to Data เข้าถึงข้อมูลที่ attacker หรือผู้ใช้งานไม่มีสิทธิเข้าถึง เช่นผู้ใช้งานมีสิทธิแค่ read-only แต่สามารถ bypass access control เข้าไปแก้ไขข้อมูลได้
วิธีการป้องกัน
- ควรใช้หลาย factor ในการ authentication(Multi-factors authentication)
- ทำการ Authen ที่ฝั่ง server(backend) เท่านั้น
- ทำ Access control ที่ฝั่ง server(backend) เท่านั้น
- re-authenticate(เช่นใส่ password เพื่อ confirm) เมื่อต้องการทำ operation ที่สำคัญๆ
- ใช้ FaceID หรือ TouchID เพื่อปกป้องข้อมูลที่ใช้ในการทำ authentication เช่น API Key หรือ Tokens
M4: Insufficient Input/Output Validation
ปํญหานี้เกิดจากการส่ง input เช้ามาเพื่อโจมตีระบบ เช่น SQL Injection หรือ Cross-Site Scripting ซึ่งการแก้ปํญหาเหล่านี้คือการทำ Input Validation ดังนั้นในข้อนี้เลยหมายถึงการทำ Input Validation ที่อาจยังไม่ดีเพียงพอ ซึ่งผลกระทบที่เกิดขึ้นกับระบบ มีดังนี้
- Code Execution
- Data Breaches
- System Compromise
- Application Disruption
- Reputation Damage
- Legal and Compliance Issues
วิธีการป้องกัน
- ทำ Input validation ที่ฝั่ง server(backend)
- ทำ Input Validation ด้วย Whitelisting(ระบุให้ใส่เฉพาะอักขระที่เราอนุญาติเท่านั้น)
- ทำ Input Validation ให้เหมาะกับบริบทนั้นๆ เช่น หน้า file uploads ต้องป้องกันการทำ path traversal
- ทำการตรวจสอบความถูกต้อง(Integrity)ของ data ก่อนนำมาใช้งาน(ต้องไม่ถูกแก้ไขมาก่อน เราจะใช้ค่า Hash ในการตรวจสอบความถูกต้อง)
- ทำตาม Secure Coding Pratices เช่นการใช้ parameterize query หรือ การใช้ Object Relational Mapping(ORM)
M5: Insecure Communication
ในปัจจุบันคงไม่มี Application ที่สามารถทำงานได้โดยไม่มีการสื่อสาร ดังนั้นเมื่อมีการแลกเปลี่ยนข้อมูลกับ server ของเราเองหรือใช้บริการ third-party เราต้องเข้ารหัสข้อมูลหรือใช้ secure protocols เช่น https หรือ sftp เสมอ ผลกระทบของการสื่อสารที่ไม่ปลอดภัยจะมีอยู่ 2 อย่างด้วยกันคือ
- ถูกดักจับข้อมูล ซึ่งทำให้ attacker เห็นข้อมูล(sensitive data)ที่วิ่งอยู่ใน network
- ถูกแก้ไขหรือเปลี่ยนแปลงข้อมูล
วิธีการป้องกัน
- ใช้ TLS หรือ Https ในทุกๆการสื่อสาร
- ทำการ Encrypt ข้อมูลก่อนส่งไปใน network
- ใช้ Strong Algorithm(ต้องปรับใน configuration เรื่อยๆ)
- ใช้ Certificate ที่มาจาก Certificate Authority ที่น่าเชื่อถือ
- อย่างส่ง seneitive data ผ่านทาง SMS,MMS หรือ Notification
- อย่าใช้ self-sign certificate
M6: Inadequate Privacy Controls
ปัญหานี้ถูกเพิ่มเข้ามาในปี 2023 ให้เหมาะกับยุคของ Privacy data(ข้อมูลส่วนบุคคล) ถือเป็นเรื่องที่ต้องใส่ใจเป็นอย่างมากเพราะถ้าข้อมูลส่วนบุคคลหลุดออกไปเรามีสิทธิโดนฟ้องได้
ปัญหาของ Privacy Control คือ การป้องกันข้อมูลที่เรียกว่า Personally Identifiable Information (PII) ซึ่งจะประกอบไปด้วย ชื่อ, ที่อยู่, email เบอร์โทรศัพท์และอื่นๆ ซึ่ง information ต่างๆเหล่านี้สามารถนำไปใช้
- ปลอมตัวเป็นเจ้าของข้อมูล
- นำข้อมูลการชำระเงินไปใช้ในทางที่ไม่ถูกต้อง
- ส่ง blackmail ไปเรียกค่าไถ่
- เข้าไปลบหรือแก้ไขข้อมูลที่มีความสำคัญ
วิธีการป้องกัน
- พยายามไม่เก็บ sensitive data(ถ้าไม่ใช้ก็ไม่ต้องเก็บ)
- เก็บข้อมูลให้กว้างขึ้น เช่น แทนที่จะเก็บอายุ ก็เก็บเป็นช่วงอายุแทน
- ทำการ deanonymized หรือ blured ซึ่งมีหลายเทคนิคมากๆ เช่นการใช้ hash หรือ noise
- เก็บเป็นช่วงเวลาไม่ต้องเก็บตลอดไป(กำหนด data retaintion policy)
- ให้ user เป็นคนเลือกว่าจะให้เก็บข้อมูลหรือไม่(consent) ในจุดที่อาจไม่ได้จำเป็นต้องเก็บ
M7: Insufficient Binary Protections
Binary สามารถ reverse engineering(ย้อนกลับไปเป็น source code) ออกมาดูได้ ดังนั้น attacker จะเข้าไปหา secret ต่างๆเช่น API Key, tokens หรือ password ที่จะเข้าสูระบบอื่นๆต่อ
วิธีการป้องกัน
- ป้องกันการทำ Reverse Engineering ด้วยการทำ Obfuscation(ไม่ได้ป้องกัน 100%)
- การทำ Security controls หรือ Access controls ต้องทำที่ฝั่ง server(backend) เท่านั้น
- เช็คความถูกต้องของ application ตอน load binary ขึ้นมาให้ตรวจสอบค่า hash ว่ามีการเปลี่ยนแปลงหรือไม่
M8: Security Misconfiguration
ปัญหานี้ค่อนข้างกว้างเนื่องจาการโจมตีช่องโหว่ที่เกิดจาการ set security settings หรือ permissions ที่ไม่ถูกต้อง ทำให้เกิดการโจมตี โดย malicious app(application ที่ถูกหลอกให้ download หรืออาจเป็น malware ที่ติดมาจาก application อื่นๆ) ซึ่งผลกระทบจาก security misconfiguration คือ
- เข้าถึงข้อมูลส่วนตัว(sensitive data)
- โขมย account หรือปลอมตัวเข้าไปใช้งาน
- เอา sensitive data ไปเปิดเผย
- โจมตี backend ต่อ
วิธีการป้องกัน
- เช็ค default configurations ว่ามีความปลอดภัยหรือไม่
- ไม่ใช้ default credentials(username หรือ password ที่มีให้ตอนติดตั้ง เราไม่ได้ตั้ง password เอง)
- กำหนดสิทธิให้น้อยที่สุด เอาแต่พอใช้งานได้ไม่ต้องกำหนดเผื่อ
- Secured network configuration จัดการ Network access control และ disable protocols ที่เป็น plain-text
- Disable debugging
- Disable backup mode(Android)
- Export activities, content providers และ services ที่จะใช้งานเท่านั้น
M9: Insecure Data Storage
ปัญหานี้เป็นการโจมตีที่ storage ซึ่งจะมีทั้ง
- keys-values storage เช่น plist(บน iOS) และ preferences(บน android)
- file (เราสร้าง file ขึ้นมาเก็บข้อมูลเอง)
- database เช่น SQLite หรือ Realm
ซึ่งผลกระทบที่เกิดก็จะมีทั้ง
- Data breaches
- การยึด account (ขโมย credentials ที่เก็บอยู่ใน storage)
- แก้ไขข้อมูลที่อยู่ใน storage นั้น
- สามารถเข้าไปดู configuration files หรือ encryption keys ที่เก็บไว้ใน storage นั้นได้
วิธีการป้องกัน
- ใช้ Storage ที่มีการ Encryption เช่น SQL Cipher
- จัดเก็บ key ใน keychain(iOS) หรือ keystore(android)
- กำหนดสิทธิการเข้าถึงข้อมูลให้เหมาะสม
M10: Insufficient Cryptography
ปัญหาข้อนี้เป็นเรื่องที่ค่อนข้างซับซ้อนที่สุดเพราะ Cryptography จะแบ่งออกเป็น
- Encryption/Decryption
- Hashing เรื่องของการเลือก Algorithm และการจัดเก็บ key หรือ secret ที่ใช้เข้ารหัสมีความสำคัญมากๆ
วิธีการป้องกัน
- ใช้ Algorithm ที่มีความแข็งแรงและได้มาตรฐาน อย่าคิดเอง
- ใช้ key หรือ secret ที่มีความยาว(length)มากๆ
- จัดเก็บ key หรือ secret ใน storage ที่มีความปลอดภัย เช่น vault หรือ Hardware Security Module(HSM)
- ใช้ secure protocols ในการรับส่ง key
- ต้องทำการ Authen ก่อนเข้าถึง key
- ต้องมีการจัดเก็บ log ว่าใครนำ key ไปใช้บ้าง
- ถ้าเป็นการ hash ต้องมี salt
หลังจากนี้ลองไปตรวจสอบ Mobile Application ของเรากันดูว่ามีปัญหาต่างๆเหล่านี้หรือไม่ เพราะ Mobile Application ถือเป็นส่วนหนึ่งที่มีความสำคัญมากๆและขาดไม่ได้ในยุคปัจจุบัน