Key Highlights:
- เราทำ Security เพื่อลดความเสี่ยงหรือปกป้องทรัพย์สินจากการถูกบุกรุก หรือโจรกรรม ให้อยู่ในระดับที่ยอมรับได้ภายใต้ทรัพยากรที่มีอยู่อย่างจำกัด
- Open Web Application Security Project (OWASP) เป็นองค์กรไม่แสวงหาผลกำไรที่ให้ความรู้เกี่ยวกับการทำให้ระบบคอมพิวเตอร์ มีความปลอดภัยมากยิ่งขึ้น โดยจะมีการจัดอันดับความเสี่ยงด้านความปลอดภัยในทุกๆปีเพื่อใช้เป็นแหล่งอ้างอิงเพื่อลดความเสี่ยงในด้านความปลอดภัยของระบบ
ก่อนที่เราจะเข้าเนื้อหาของ OWASP Top 10 ขอเท้าความกันก่อนสักนิดนะคะ สำหรับใครที่รู้อยู่แล้วสามารถข้ามไปอ่านในหัวข้ออื่นได้เลยนะคะ
Security คืออะไร?
คือ การลดความเสี่ยงหรือปกป้องทรัพย์สินจากการถูกบุกรุก หรือโจรกรรม ให้อยู่ในระดับที่ยอมรับได้ภายใต้ทรัพยากรที่มีอยู่อย่างจำกัด การลดความเสี่ยงในการถูกบุกรุก หรือโจรกรรมนั้นทำได้หลายระดับยกตัวอย่างเช่น
- Network security
- Application security
- Data security
- Cloud security, Infrastructure security
แล้วเราทำ security เพื่อวัตถุประสงค์อะไร?
- Confidentiality: การปกป้องความลับ หรือการจัดเก็บข้อมูลเพื่อความปลอดภัย โดยการความคุมระดับการเข้าถึงข้อมูลจากทั้งภายในและภายนอก เมื่อมีการควบคุบระดับการเข้าถึงของข้อมูลแล้วทำให้ลดโอกาสที่จะมีข้อมูลรั่วไหลโดยไม่ตั้งใจลดลง
- Integrity: คือ ความถูกต้องของข้อมูลโดยระบบจะต้องไม่ให้ข้อมูลถูกลบหรือแก้ไขโดยบุคคลที่ไม่ได้รับอนุญาต
- Availability: ระบบต้องมีความพร้อมใช้งานภายใต้สถานการณ์ต่างๆ รวมถึงไฟดับหรือภัยธรรมชาติ
OWASP คืออะไร?
Open Web Application Security Project (OWASP) เป็นองค์กรไม่แสวงหาผลกำไรที่ให้ความรู้เกี่ยวกับการทำให้ระบบคอมพิวเตอร์ มีความปลอดภัยมากยิ่งขึ้น โดยจะมีการจัดอันดับความเสี่ยงด้านความปลอดภัยในทุกๆปีเพื่อใช้เป็นแหล่งอ้างอิงเพื่อลดความเสี่ยงในด้านความปลอดภัยของระบบ การจัดอันดับในด้านความปลอดภัยหรือที่เราคุ้นกันดีคือ OWASP Top 10 โดยจะมีการเฉพาะเจาะจงความปลอดภัยในแต่ละประเภทเช่น mobile, web, API
Top 10 Mobile Risks - Final List 2016
M1: Improper Platform Usage
คือ การใช้คุณสมบัติแพลตฟอร์มในทางที่ผิด หรือความผิดพลาดในการความคุมความปลดภัยของแพลตฟอร์ม ซึ่งรวมถึง platform permissions, การใช้ TouchID ในทางที่ผิด, Keychain, หรือการความคุมความปลอดภัยอื่นๆ ที่เป็นส่วนหนึ่งของ moblie OS
จากคำอธิบายข้างต้นอาจจะเข้าใจยากไปสักนิดเราลองมายกตัวอย่างจากช่องโหว่ข้างต้นกัน
- Attacker อาจใช้ประโยชน์จากช่องโหว่ Cross-Site Scripting (XSS) ผ่าน mobile device
- KeyChain ใน iOS เป็นที่เก็บข้อมูลที่ปลอดภัยสำหรับทั้งข้อมูลของแอปและข้อมูลของระบบ ควรใช้จัดเก็บข้อมูลที่มีขนาดเล็กที่มีความสำคัญในด้านความปลอดภัย (e.g. session key, passwords, data, enrolment data) แต่ถ้าเราจัดเก็บข้อมูล sensitive data ลงใน app local storage โดยไม่ได้มีการเข้ารหัส
- การขอ platform permissions มากเกินความจำเป็น หรือผิดประเภท
- ใน Android การที่แอปลิเคชั่นอื่นสามารถเข้าถึงข้อมูลที่เป็น public หรือ sensitive information ได้โดยไม่ได้รับอนุญาต
การแก้ไขช่องโหว่นี้ต้องทำควบคู่ไปกับฝั่ง server-side ตามแนวทางในการพัฒนาแพลตฟอร์ม การเข้ารหัสที่ปลอดภัยและการตั้งค่า configuration ที่เหมาะสมในฝั่ง server-side จะช่วยลดความเสี่ยงได้ ยกตัวอย่างเช่น
- การจำกัดไม่ให้แอปสื่อสารระหว่างกัน, การจำกัดสิทธิในการเข้าถึง
- การใช้ protection class สำหรับ keychain เพื่อป้องกันการเข้าถึงที่ไม่พึงประสงค์
M2: Insecure Data Storage
การที่ mobile สูญหาย หรือถูกขโมยและตกไปอยู่ในมือ Attacker ได้โดย Attacker นั้นสามารถใช้ malware รันบนอุปกรณ์และสามารถใช้ประโยชน์จากช่องโหว่ทำให้เกิดการรั่วไหลของข้อมูลส่วนบุคคลและเข้าถึงข้อมูล sensitive ได้ เราคงเลี่ยงที่จะไม่จัดเก็บข้อมูลลงแอปพลิเคชันไม่ได้เสมอไป แต่สิ่งสำคัญที่สุดคือการจัดเก็บข้อมูลนั้นอย่างไรให้ปลอดภัย โดยที่แอปพลิเคชันอื่น หรือบุคคลอื่นไม่สามารถเข้าถึงได้ การ root หรือ Jailbreaking นั้นสามารถหลบเลี่ยงการป้องกันเข้ารหัสได้
การแก้ไขช่องโหว่นี้ ต้องทำความเข้าใจการจัดเก็บข้อมูลของแอปพลิเคชันนั้นทำงานอย่างไร และทำยังไงถึงจะช่วยลดความเสี่ยงได้ ยกตัวอย่างเช่น
- ประเมิณว่าการเข้ารหัสนั้นได้ประสิทธิภาพหรือไม่
- หลีกเลี่ยงการจัดเก็บหรือ cach ข้อมูล
- การตรวจสอบสิทธิ
M3: Insecure Communication
หากการติดต่อสื่อสารข้อมูลระหว่างกันโดยที่ข้อมูลไม่ได้มีการเข้ารหัสไว้ ทำให้ใครก็ตามที่ monitor network อยู่สามารถที่จะเข้าถึงข้อมูลที่มีการติดต่อสื่อสารกันใน network ได้ แอปพลิเคชันมือถือมักจะติดต่อสื่อสารข้อมูลในรูปแบบของ client-server และส่งข้อมมูลที่ใช้ติดต่อสื่สารกันผ่านผู้ให้บริการ internet และอุปกรณ์ network เมื่อ Attacker สามารถโจมตีอุปกรณ์ network ของคุณได้จะทำการติดตั้ง malware บนอุปกรณ์ network ของคุณ แล้วเราจะทำยังได้เพื่อที่จะช่วยลดความเสี่ยงได้ ยกตัวอย่างเช่น
- การใช้ SSL/TLS จากผู้ออก certificate ที่เชื่อถือได้ (CA) เพื่อป้องกันความปลอดภัยช่องทางที่ใช้ติดต่อสื่อสารกันทั้งหมด
- การแจ้งเตือนเมื่อตรวจพบการใช้ certificate SSL/TLS ที่ไม่ถูกต้อง หรือเกิดการตรวจสอบ certificate ผิดพลาด
M4: Insecure Authentication
การรับรองความถูกต้องที่ไม่ปลอดภัยนั้นมาจากช่องโหว่ความปลอดภัยบน mobile โดยที่ก่อนให้สิทธิการเข้าถึง แอปพลิเคชันจำเป็นต้องยืนยันตัวตนของผู้ใช้ แต่เกิดการ bypass ความถูกต้องในการยืนยันตัวตน จุดอ่อนในการตรวจสอบสิทธิสำหรับ mobile นั้นสามารถถูกโจมตีจาก Attacker ทำให้ Attacker สามารถหลีกเลี่ยงหรือ bypass password หรือทำการแก้ไขสิทธิเพิ่มเติมสิทธิและนำไปสู่การขโมยข้อมูล หรือเกิดความเสียหายอื่นๆ ได้ เราจะลดความเสี่ยงที่จะเกิดการ bypass ได้ยกตัวอย่างเช่น
- หลีกเลี่ยงการตรวจสอบความถูกต้องใน mobile โดยการเปลี่ยนไปตรวจสอบความถูกต้องที่ฝั่ง server แทนและโหลดข้อมูลต่างๆหลังจากการตรวจสอบสิทธิสำเร็จเท่านั้น
- ไม่เก็บ password ไว้, ทำ multi-factor authentication (MFA), ไม่ใช้ PIN 4 หลักแทน password
M5: Insufficient Cryptography
มี 2 วิธีที่ทำให้ข้อมูลที่ถูกเข้ารหัสถูกเปิดเผยได้
- Algorithm ที่ใช้ในการเข้ารหัสนั้น weak เกินไป
- กระบวนการการเข้ารหัสนั้นมีข้อบกพร่องในการทำงาน
การเข้ารหัสที่มีข้อบกพร่องในการทำงานนั้นมีปัจจัยหลายอย่าง ยกตัวอย่างเช่น
- การ bypass algorithm ในการเข้ารหัส
- การใช้ algorithm ในการเข้ารหัสที่เลิกใช้ไปแล้ว
ตัวอย่างของ algorithm เลิกใช้แล้วเช่น
- RC2
- MD4
- MD5
- SHA1
การเข้ารหัสข้อมูลไม่ได้นั้นอาจะทำให้เกิดการเข้าถึงข้อมูลส่วนบุคคล จากอุปกรณ์ที่ไม่ได้รับอนุญาต ซึ่งเราสามารถป้องกันได้ โดยใช้ algorithm ในการเข้ารหัสที่ National Institute of Standards and Technology (NIST) แนะนำ และเป็น alogorithm ที่สามารถรองรับอนาคตได้อย่างน้อยอีก 10 ปี
M6: Insecure Authorization
ในการใช้งานในแอปพลิเคชันนั้น มีการจำกัดสิทธิในการเข้าถึงตาม role ของผู้ใช้งาน แต่รูปแบบการให้สิทธิที่ไม่ดีทำให้ไม่สามารถตรวจสอบได้ว่าผู้ใช้งานเป็นใครทำให้ไม่สามารถตรวจสอบได้ว่าผู้ใช้งานสามารถเข้าถึงข้อมูลได้หรือไม่ ทำให้ Attacker ทำการยกระดับสิทธิในการเข้าถึงข้อมูลได้
ผลกระทบของการ Insecure authorization คล้ายกับ Insecure Authentication ซึ่งช่องโหว่ทั้งสองแบบนั้นสามารถทำให้เกิดดารขโมยข้อมูลได้ เราสามารถลดความเสี่ยงที่จะเกิดช่องโหว่นี้ได้โดยต้องทำควบคู่ไปกับฝั่ง server ยกตัวอย่างเช่น
- ฝั่ง server ตรวจสอบแต่ละ request ที่เข้ามา โดยแต่ละ request ที่เข้ามาต้องสามารถระบุตัวตันได้และข้อมูลถูกต้อง
- ตรวจสอบ role และการสิทธิในการใช้งานผ่านการตรวจสอบสิทธิของผู้ใช้งาน โดยอิงจากข้อมูลของผู้ใช้งานจากฝั่ง server ในการตรวจสอบและให้สิทธิ
M7: Client Code Quality
คือปัญหาที่เกิดในระดับโค้ดทั้งหมด โดยที่จะแตกต่างจาก Improper Platform Usage เพราะจะหมายถึงแค่ภาษาที่ใช้ในการเขียนโปรแกรม เช่น buffer overflow ใน C, DOM-based Cross-Site Scripting (XSS) ใน Webview mobile app ทั้งหมดเป็นปัญหาในเชิงคุณภาพของโค้ด
โดยถ้า code quality ของเราไม่ดี Attacker ทำใส่ input เพื่อเรียกใช้งานฟังก์ชั่นภายในแอปพลิเคชันเพื่อทดสอบแอปพลิเคชัน อาจทำให้ประสิทธิภาพลดลง, ใช้หน่วยความจำเพิ่มขึ้น ฯลฯ อาจนำไปสู่ปัญหาต่างๆ ได้เช่น
- ช่องโหว่ในรูปแบบ String
- Buffer overflows
- การ Integration กับ third-party libraries ที่ไม่ปลอดภัย
- Remote code execution
แอปพลิเคชันหลายตัวใช้ 3rd library ซึ่งมักจะมีข้อบกพร่อง หรือไม่ได้รับการทดสอบความปลดภัย ซึ่งปัญหาเหล่านี้อยู่นอกเหนือการควบคุมของนักพัฒนาเนื่องจากไม่ใช่เจ้าของโค้ด เราสามารถลดความเสี่ยงที่จะเกิดช่องโหว่นี้ได้ยกตัวอย่างเช่น
- ทดสอบเรื่อง Buffer overflows, memory leaks รวมถึงการใช้ automated tools ช่วยในการตรวจสอบ source code เพื่อทำให้การเขียนโค้ดเข้าใจง่ายขึ้น
- ใช้รูปแบบในการเขียนโค้ดที่เหมือนกันทั้งทีม
M8: Code Tampering
บน app store นั้นบางครั้งก็มีแอปพลิเคชันที่เป็นเวอร์ชั่นที่ถูกดัดแปลงแล้ว ตัวอย่างที่ถูกดัดแปลงเช่น แการแก้ไข binary ของแอปเพื่อเพิ่มหรือแก้ไขโค้ดดั่งเดิม, ติดตั้ง backdoor ฯลฯ โดย Attacker สามารถ re-sign แอปปลอมเหล่านี้เพื่อ publish เวอร์ชั่นที่ทำการแก้ไขไปยัง third-party app stores ได้ รวมถึงยังสามารถส่งแอปเหล่านี้ไปให้เหยื่อได้โดยตรงผ่านการโจมตีแบบ phishing เพื่อหลอกล่อเหยื่อให้ดาวน์โหลดแอป
แอปพลิเคชันที่เป็นเวอร์ชั่นที่ถูกดัดแปลงแล้วนั้นสามารถขโมยข้อมูล หรือก่อให้เกิดความเสียหายอื่นๆได้ เราสามารถลดความเสี่ยงที่ก่อให้เกิดช่องโหว่นี้ได้เช่น
- แอปพลิเคชันต้องกาสามารถระบุได้ว่าไม่มีการเพิ่มเติม หรือแก้ไขโค้ด ใช้ code signing certificate เพื่อช่วยให้ผู้ใช้งานทราบว่าโค้ดมีการเปลี่ยนแปลง
- ใช้เทคนิค anti-tamper เพื่อป้องกันไม่ให้แอปที่ผิดกฎหมายทำงาน โดยเช็คจาก checksums, digital signatures ฯลฯ
M9: Reverse Engineering
Attacker สามารถ reverse engineer เพื่อทำการถอดรหัสแอปและวิเคราะห์โค้ดได้ สิ่งนี้เป็นอัตารายอย่างมากเพราะทำให้ Attacker เข้าใจและตรวจสอบและแก้ไขโค้ดได้ เพื่อ Attacker เข้าใจวิธีการทำงานของแอปแล้ว ก็สามารถแก้ไขได้โดยใช้เครื่องมือต่างๆ (e.g. IDA Pro, Hopper หรือเครื่องมือตรวจสอบ binary อื่นๆ) เมื่อแอปทำงานตามที่ Attacker ต้องการแล้วสามารถ complie ใหม่และรันแอปได้ เราสามารถหลีกเลี่ยงช่องโหว่นี้ได้เช่น
- เพื่อป้องกันไม่ให้เกิดการทำ reverse engineer ได้ Attacker จะต้องไม่สามารถถอดรหัส source code ที่สร้างความสับสนได้โดยใช้เครื่องมืออย่าง IDA Pro, Hopper
M10: Extraneous Functionality
บางครั้งนักพัฒนาอาจทิ้ง backdoors หรือฟังก์ชั่นเพิ่มเติมได้โดยไม่ได้ตั้งใจ โดนการปิดไม่ให้ผู้ใช้งานเห็นทาง interface ทำให้เกิดความเสี่ยงในด้านความปลอดภัย โดยมักถูกโจมตีจาก Attacker ทำได้โดยการตรวจสอบไฟล์การกำหนดค่า หรือวิเคราะห์ binary เพื่อค้นหาฟังก์ชั่นต่างๆที่สามารถใช้โจมตีได้ เราสามารถหลีกเลี่ยงช่องโหว่นี้ได้เช่น
- ตรวจสอบการตั้งค่า configutation ของแอปเพื่อหา feature ที่ซ่อนอยู่
- ตรวจสอบให้แน่ใจว่าไม่มีการคอมเม้นท์ หรือคำอธิบายเกี่ยวกับระบบมากเกินไป
NIST คืออะไร?
National Institute of Standards and Technology (NIST) เป็นองค์กรของประเทศสหรัฐอเมริกาที่ถูกสร้างขึ้นเพราะในปัจุบันนั้นการโจมตีในโลกออนไลน์นั้นก่อให้เกิดความเสียหายแก่เศรษฐกิจ และความมั่นคงของประเทศ จึงทำให้ต้องมีการจัดทำแนวทางในการป้องกันและรับมือจากการโจมตีทางโลกออนไลน์ให้มีประสิทธิภาพมากที่สุด
การทำ Mobile security ใน Flutter
- National Institute of Standards and Technology (NIST) เป็นองค์กรของประเทศสหรัฐอเมริกาที่ถูกสร้างขึ้นเพราะในปัจุบันนั้นการโจมตีในโลกออนไลน์นั้นก่อให้เกิดความเสียหายแก่เศรษฐกิจ และความมั่นคงของประเทศ จึงทำให้ต้องมีการจัดทำแนวทางในการป้องกันและรับมือจากการโจมตีทางโลกออนไลน์ให้มีประสิทธิภาพมากที่สุด โดยเราจะทำการระบุ certificate ในแอปได้โดยการใช้ package ssl_pinning_plugin เพื่อทำการเช็ค certificate ที่ถูกใช้ในแอปนั้นใช่ certificate ที่ระบุไว้หรือไม่ (badCertificateCallback)
- ขอ Permission เท่าที่จำเป็น และขอ permission แค่ตอนที่จะใช้เท่านั้น ทำเราถึงต้องขอ permission กับผู้ใช้งานแค่ตอนที่จะใช้ล่ะ ในเชิง UX แล้วถ้าเราร้องขอ permission ทุกอย่างที่ต้องใช้ในแอปพลิเคชั่นตั้งแต่เปิดแอปมาครั้งแรกมีโอกาสสูงมาที่ผู้ใช้งานจะปฎิเสธที่จะให้ permission กับแอป
- Jailbreak และ Root Detection เราจะทำเช็คว่า mobile เครื่องนั้นได้มีการทำ Jailbreak หรือ Root มามั้ยโดยการใช้ package flutter_jailbreak_detection | Flutter Package ในการเช็ค เราสามารถลองเช็ค mobile ของเราว่าเครื่องนั้นทำการ Jailbreak หรือ Root มาแล้วก่อนได้ด้วย
- Anti-Debugging ใน android
- ใส่ flag debuggable เป็น false ในส่วนของ buildTypes release ในไฟล์ build.gradle
- นำโค้ดด้านล่างไปใส่ไว้ในไฟล์ MainActivity.kt ถ้าผลลัพธ์ที่ได้มามีค่าเป็น true นั้นหมายความว่าไม่ผ่าน security นั้นเอง
- ปิด 3rd Party Keyboard เพื่อลดความเสี่ยงที่ 3rd Party Keyboard จะแอบส่งข้อมูลอะไรที่เราทำการพิมพ์ลงไปบนคีย์บอร์ด โดยใน android นั้นเราจะเช็คยากหน่อยเพราะมันมองว่าคีย์บอร์ดทั้งหมดเป็นคีย์บอร์ด 3rd Party Keyboard ทุกอันโดยเราสามารถแก้ปัญหานี้ได้โดยการทำคีย์บอร์ดขึ้นเอง แต่ในส่วนของ iOS สามารถเช็คได้ง่ายกว่าโดยเช็คได้จากโค้ดด้านล่าง
- Code obfuscation คือการทำให้ attacker ที่ทำการ reverse engineer เพื่อวิเคราะห์โค้ดของเรานั้นไม่สามารถอ่านและวิเคราะห์โค้ดของเราได้ code obfuscation มี Commercial SDK ให้ใช้เช่นกัน โดยใน flutter เองนั้นก็มีเหมือนกันค่ะ สามารถอ่านเพิ่มเติมได้ที่ Obfuscating Dart code, How to obfuscate Flutter apps?
อภิธารศัพท์
- Cryptography algorithms: หมายถึง วิธีการเข้ารหัสสำหรับวัตถุประสงค์ด้านความปลอดภัย หลายๆคนอาจจะเคยได้ยินการ Encode, Encrypt มาบ้างแล้วมันต่างกันยังไงล่ะ
- Encode / Decode: สามารถแปลงค่าไปกลับได้โดยการใช้ algorithm โดยผลลัพธ์จะอยู่ในรูปของ Base64
- Encrypt / Decrypt: สามารถแปลงค่าไปกลับได้โดยการใช้ algorithm ร่วมกับ key โดยผลลัพธ์จะอยู่ในรูปของ AES, RC4
- Hash: ไม่สามารถแปลงค่ากลับได้ ความยาวของผลลัพท์จากฟังก์ชั่นจะเท่ากันตลอดโดยที่ input ก่อนที่จะเข้าฟังก์ชั่น hash นั้นจะมีความยาวไม่เท่ากันแต่ผลลัพธ์ที่ได้จะมีความยาวเท่ากัน การชนกันของค่าแฮช (collision) ที่ข้อมูลสองชุดกลับมีค่าแฮชตรงกันนั้นค่อนข้างต่ำเข่นกัน เนื่องจากเรามีการกำหนดผลลัพธ์เป็นความยาวไว้ ที่นิยมใช้กันมากในช่วงหนึ่งคือ CRC-32 ที่จริงแล้ว CRC เป็นเพียงการกำหนดกระบวนการคำนวณไว้กว้างๆ เท่านั้น แต่ความยาวของค่าที่ได้มักกำหนดเป็น 32 bit จึงเรียกว่า CRC-32 ซึ่ง CRC-32 สามารถคำนวณค่า checksum เพื่อยืนยันความถูกต้องของข้อความได้เป็นอย่างดี ด้วยความยาวถึง 32 บิตทำให้มีความเป็นไปได้ถึง 4 พันล้านรูปแบบจึงทำให้เกิดจากชนกันของค่า hash ค่อนข้างต่ำ
- Cross-Site Scripting (XSS): เป็นรูปแบบนึงของการทำ Injection โดยการแทรก script ที่เป็นอันตรายเข้าไปในระบบ
- Malware: หมายถึง software ที่ไม่ปลอดภัยซึ่งครอบคลุมถึง Virus, Worms, Trojans หรือโปรแรมที่เป็นอันตรายอื่นๆ
- bypass: ถ้าแปลเป็นไทยก็จะได้ความหมายว่า ทางเลี่ยง ฟังดูแล้วอาจจะยังไม่เข้าใจยกตัวอย่างเช่น ก่อนที่จะเข้าใช้งานระบบได้ผู้ใช้งานจะต้องเข้าสู่ระบบก่อน แต่ Attacker ได้ทำการ bypass login ระบบเข้าไปใช้งานโดยที่ไม่ได้ทำการ login ก่อน
- Backdoor: คือ ช่องทางที่นักพัฒนาระบบสร้างไว้ เพื่อทำการเข้าถึงระบบได้โดยไม่ต้องผ่านกระบวนการตรวจสอบปรกติ เป็นเหมือนทางลัดเพื่อใช้งานระบบได้โดยไม่ผ่านการตรวจสอบนั่นเอง
- Phishing: เป็นการหลอกล่อเหยื่อที่พบได้มากที่สุดในโลกออนไลน์ ฟิชชิงมีหลายรูปแบบการหลอกล่อเหยื่อประเภทนี้มักจะเกี่ยวกับการหลอกเหยื่อให้เชื่อว่าเว็บไซต์นั้นหรือระบบนั้นเป็นที่น่าเชื่อถือ ยกตัวอย่างที่เรามักจะเจอได้บ่อยๆคือ เหยื่อได้รับอีเมลที่เนื้อหาในเมลจะทำการหลอกล่อเหยื่อให้ทำการกดลิ้งค์จากในอีเมล โดยในลิ้งค์นั้นจะหลอกเอาข้อมูลของเหยื่อไปใช้งานต่อ
- Man in the Middle: คือ Attacker จะโจมตีระหว่าการติดต่อสื่อสารระหว่างต้นทางและปลายทาง
Reference:
OWASP top 10: OWASP Mobile Top 10 | OWASP Foundation, OWASP Mobile Top 10 Vulnerabilities & Mitigation Strategies – InfoSec Insights
NIST: NIST Policy on Hash Functions – Hash Functions | CSRC | CSRC, https://csrc.nist.gov/csrc/media/publications/sp/800-175b/archive/2016-03-11/documents/sp800-175b-draft.pdf
Use case: OWASP mobile top 10 security risks explained with real world examples
Flutter: Mobile Security via Flutter — ตอนที่ 1 SSL Pinning, Mobile Security via Flutter — ตอนที่ 2 Strong Device/ Strong Pin, 10 Tips to Secure Your Flutter Mobile Apps
Hash: Hash: ไม่รู้ว่ามันคืออะไรแต่มันใช่
Reference:
https://docs.flutter.dev/resources/architectural-overview
https://www.cuelogic.com/blog/flutter-vs-react-native-a-comparison-based-on-criteria
A special thank you to K'Theeraporn T. for their invaluable contribution to this blog.
