ทำความเข้าใจความเสี่ยง 10 อันดับแรกของ OWASP Mobile กับเคสในโลกแห่งความจริง

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

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

การช่วยให้เราอยู่เหนือเกมในเรื่องการรักษาความปลอดภัยคือการมีความรู้อย่างครบถ้วนเกี่ยวกับ แนวทางปฏิบัติในการเข้ารหัสที่ปลอดภัยของ OWASP (โครงการ Open Web Application Security) เป็นชุมชนออนไลน์ของผู้เชี่ยวชาญด้านความปลอดภัยที่ได้พัฒนาเอกสาร สื่อการเรียนรู้ และเครื่องมือฟรีสำหรับการสร้างแอปพลิเคชันมือถือและเว็บที่ปลอดภัย

นอกเหนือจากสิ่งอื่น ๆ พวกเขายังได้รวบรวมรายการ ภัยคุกคามความปลอดภัย OWASP Mobile Top 10 ในแอปพลิเคชันมือถือ

แม้ว่า เอกสาร หลักปฏิบัติด้านความปลอดภัยของ OWASP จะค่อนข้างชัดเจน แต่บางครั้งอาจเป็นเรื่องยากสำหรับธุรกิจที่จะเชื่อมต่อจากกรณีในโลกแห่งความเป็นจริง

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

ก่อนดูความเสี่ยง ให้เราดูสถิติก่อน

NowSecure ตรวจสอบแอปใน Google Play Store และ App Store ระบุว่าแอปมากกว่า 85% ละเมิดความเสี่ยงอย่างใดอย่างหนึ่ง

ของแอปพลิเคชันเหล่านี้ 50% มีการจัดเก็บข้อมูลที่ไม่ปลอดภัย และบางแอปจำนวนเท่ากันที่ทำงานกับ ความเสี่ยงในการสื่อสาร ที่ไม่ ปลอดภัย นี่คือกราฟที่แสดงเปอร์เซ็นต์การเกิดขึ้นของ ความเสี่ยง 10 อันดับแรกของ OWASP Mobile

รายชื่อ 10 ภัยคุกคามที่พบบ่อยที่สุดต่อแอปพลิเคชันมือถือและแนวทางปฏิบัติที่ดีที่สุดที่ควรหลีกเลี่ยง

M1: การใช้แพลตฟอร์มที่ไม่เหมาะสม

ประเภทของ การทดสอบความปลอดภัย OWASP ประกอบด้วยการใช้ฟังก์ชันการทำงานของอุปกรณ์ในทางที่ผิดหรืออินสแตนซ์ของความล้มเหลวเมื่อใช้การควบคุมความปลอดภัยของแพลตฟอร์ม มันสามารถรวมถึงการอนุญาตแพลตฟอร์ม, ความตั้งใจของ Android, การใช้ TouchID, พวงกุญแจ, ฯลฯ ในทางที่ผิด

กรณีในโลกแห่งความเป็นจริง:

แอพ iOS สามตัว : “แอพ Fitness Balance”, “Heart Rate Monitor” และ “แอพ Calories Tracker” มาเพื่อเลี่ยงผ่าน Touch ID ของ Apple พวกเขาขอให้ผู้ใช้ใช้ลายนิ้วมือเพื่อรับข้อมูลการออกกำลังกาย ในขณะที่พวกเขากำลังใช้ลายนิ้วมือเพื่อเรียกเก็บเงินจาก App Store

แนวทางปฏิบัติที่ดีที่สุดที่ควรหลีกเลี่ยง:

• ผู้พัฒนาต้องไม่อนุญาตให้เข้ารหัส Keychain ผ่านเส้นทางเซิร์ฟเวอร์และเก็บคีย์ไว้ในอุปกรณ์เดียวเท่านั้น เพื่อไม่ให้ถูกโจมตีบนเซิร์ฟเวอร์หรืออุปกรณ์อื่น
• นักพัฒนาต้องรักษาความปลอดภัยแอปผ่านพวงกุญแจเพื่อเก็บความลับของแอปที่มีรายการควบคุมการเข้าถึงโดยเฉพาะ
• นักพัฒนาต้องได้รับอนุญาตเพื่อจำกัดว่าแอปใดได้รับอนุญาตให้สื่อสารกับแอปพลิเคชันของตน
• นักพัฒนาต้องควบคุมรายการแรกของ OWASP Mobile Top 10 โดยกำหนดเจตนาที่ชัดเจนและบล็อกส่วนประกอบอื่น ๆ ทั้งหมดเพื่อเข้าถึงข้อมูลที่มีอยู่ในเจตนา

M2: การจัดเก็บข้อมูลที่ไม่ปลอดภัย

OWASP พิจารณาว่าเป็นภัยคุกคามเมื่อมีคนเข้าถึงอุปกรณ์พกพาที่สูญหาย/ถูกขโมย หรือเมื่อมัลแวร์หรือแอปที่บรรจุใหม่อื่นเริ่มดำเนินการในนามของฝ่ายตรงข้ามและดำเนินการกับอุปกรณ์มือถือ

ช่องโหว่ในการจัดเก็บข้อมูลที่ไม่ปลอดภัยมักจะนำไปสู่ความเสี่ยงเหล่านี้:

• การฉ้อโกง
• ขโมยข้อมูลประจำตัว
• การสูญเสียวัสดุ
• ชื่อเสียงเสียหาย
• การละเมิดนโยบายภายนอก (PCI)

กรณีในโลกแห่งความเป็นจริง :

แอพหาคู่ เช่น Tinder, OKCupid และ Bumble ได้รับการพิจารณาครั้งแล้วครั้งเล่าสำหรับแนวทางปฏิบัติในการจัดเก็บข้อมูลที่ไม่ปลอดภัย ระยะการรักษาความปลอดภัยที่มีอยู่ในแอปเหล่านี้แตกต่างกันไปตามความเป็นไปได้ ความรุนแรง และความเป็นไปได้ สามารถเปิดเผยชื่อผู้ใช้ รายละเอียดการเข้าสู่ระบบ ประวัติข้อความ และแม้แต่ตำแหน่ง นอกเหนือจากกิจกรรมบัญชีส่วนตัวอื่นๆ

แนวทางปฏิบัติที่ดีที่สุดที่ควรหลีกเลี่ยง:

• สำหรับ iOS แนวทางปฏิบัติด้านความปลอดภัยของ OWASP แนะนำให้ใช้แอปที่มีช่องโหว่เช่น iGoat เพื่อคุกคามโมเดลเฟรมเวิร์กการพัฒนาและแอป ซึ่งจะช่วยให้ นักพัฒนาแอป ios เข้าใจว่า API จัดการกับกระบวนการของแอปและสินทรัพย์ข้อมูลอย่างไร
• นัก พัฒนาแอพ Android สามารถใช้เชลล์ Android Debug Bridge เพื่อตรวจสอบการอนุญาตไฟล์ของแอพเป้าหมายและ DBMS เพื่อตรวจสอบการเข้ารหัสฐานข้อมูล พวกเขาควรใช้ Memory Analysis Tool และ Android Device Monitor เพื่อให้แน่ใจว่าหน่วยความจำของอุปกรณ์ไม่มีข้อมูลที่ไม่ได้ตั้งใจ

M3: การสื่อสารที่ไม่ปลอดภัย

เมื่อสร้างแอพมือถือ ข้อมูลจะถูกแลกเปลี่ยนในรูปแบบไคลเอนต์-เซิร์ฟเวอร์ ดังนั้น เมื่อมีการส่งข้อมูล อันดับแรกควรผ่านเครือข่ายผู้ให้บริการของอุปกรณ์และอินเทอร์เน็ต ตัวแทนภัยคุกคามสามารถใช้ประโยชน์จากจุดอ่อนและสกัดกั้นข้อมูลที่ละเอียดอ่อนขณะเดินทางข้ามสาย ต่อไปนี้คือตัวแทนภัยคุกคามต่างๆ ที่มีอยู่:

• ปฏิปักษ์ที่แชร์เครือข่ายท้องถิ่นของคุณ – Wi-Fi ที่ถูกบุกรุก
• อุปกรณ์เครือข่ายหรือผู้ให้บริการ – เสาส่งสัญญาณมือถือ พร็อกซี่ เราเตอร์ ฯลฯ
• มัลแวร์บนอุปกรณ์มือถือ

การสกัดกั้นข้อมูลที่ละเอียดอ่อนผ่านช่องทางการสื่อสารจะจบลงด้วยการละเมิดความเป็นส่วนตัว ซึ่งอาจนำไปสู่:

• ขโมยข้อมูลประจำตัว
• การฉ้อโกง
• ความเสียหายต่อชื่อเสียง

กรณีในโลกแห่งความเป็นจริง:

บริษัทรักษาความปลอดภัย Rapid7 เปิดเผยช่องโหว่หลาย จุดที่ มาพร้อมกับสมาร์ทวอทช์สำหรับเด็ก นาฬิกาเหล่านั้นถูกวางตลาดโดยผู้ปกครองใช้เพื่อติดตามลูก ๆ ของพวกเขาและส่งข้อความหรือโทรออกบนสมาร์ทวอทช์ของพวกเขา

นาฬิกาควรได้รับการติดต่อจากหมายเลขติดต่อที่ได้รับอนุมัติผ่านโหมดของรายการที่อนุญาต แต่บริษัทพบว่าตัวกรองไม่ทำงานด้วยซ้ำ นาฬิกายังยอมรับคำสั่งการกำหนดค่าผ่านข้อความ หมายความว่าแฮ็กเกอร์สามารถเปลี่ยนการตั้งค่านาฬิกาและทำให้เด็กตกอยู่ในความเสี่ยงได้

"คุณสามารถระบุได้ว่าโทรศัพท์หรือเด็กอยู่ที่ไหน คุณสามารถเข้าถึงเสียง หรือโทรออกหาเด็กได้" Deral Heiland หัวหน้าฝ่ายวิจัย IoT ของ Rapid7 กล่าว

แนวทางปฏิบัติที่ดีที่สุดที่ควรหลีกเลี่ยง:

• นักพัฒนาซอฟต์แวร์ไม่ควรมองหาการรั่วไหลของทราฟฟิกที่สื่อสารระหว่างแอปและเซิร์ฟเวอร์เท่านั้น แต่ยังรวมถึงอุปกรณ์ที่มีแอปและอุปกรณ์อื่นๆ หรือเครือข่ายท้องถิ่นด้วย

• การใช้ TLS/SSL สำหรับการขนส่งช่องสัญญาณเป็นหนึ่งใน แนวทางปฏิบัติที่ดีที่สุดด้านความปลอดภัยของแอปบนอุปกรณ์เคลื่อนที่ที่ ควรพิจารณาเมื่อต้องส่งข้อมูลที่มีความละเอียดอ่อนและข้อมูล ที่ละเอียดอ่อนอื่นๆ

• ใช้ใบรับรองที่ได้รับจากการตรวจสอบลูกโซ่ SSL ที่เชื่อถือได้
• อย่าส่งข้อมูลที่ละเอียดอ่อนผ่านช่องทางอื่น เช่น MMS, SMS หรือการแจ้งเตือนแบบพุช
• ใช้ชั้นการเข้ารหัสแยกต่างหากกับข้อมูลที่ละเอียดอ่อนก่อนที่จะมอบให้กับช่องทาง SSL

M4: การตรวจสอบสิทธิ์ที่ไม่ปลอดภัย

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

ผลกระทบทางธุรกิจของ M4 สามารถ:

• ขโมยข้อมูล
• ความเสียหายต่อชื่อเสียง
• การเข้าถึงข้อมูลโดยไม่ได้รับอนุญาต

กรณีในโลกแห่งความเป็นจริง :

ในปี 2019 ธนาคารสหรัฐถูกแฮ็กโดยผู้โจมตีทางไซเบอร์ซึ่งใช้ประโยชน์จากข้อบกพร่องของเว็บไซต์ของธนาคารและหลีกเลี่ยงการตรวจสอบสิทธิ์แบบสองปัจจัยซึ่งนำมาใช้เพื่อปกป้องบัญชี

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

แนวทางปฏิบัติที่ดีที่สุดที่ควรหลีกเลี่ยง:

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

M5: ความเสี่ยงในการเข้ารหัสไม่เพียงพอ

ตัวแทนภัยคุกคามในกรณีนี้คือผู้ที่มีการเข้าถึงข้อมูลทางกายภาพซึ่งถูกเข้ารหัสอย่างไม่ถูกต้อง หรือที่ที่มัลแวร์ดำเนินการในนามของศัตรู

การเข้ารหัสที่ใช้งานไม่ได้มักส่งผลให้เกิดกรณีเหล่านี้:

• ขโมยข้อมูล
• ขโมยทรัพย์สินทางปัญญา
• ขโมยรหัส
• การละเมิดความเป็นส่วนตัว
• ความเสียหายต่อชื่อเสียง

กรณีในโลกแห่งความเป็นจริง :

บางครั้งที่ผ่านมา การแจ้งเตือนจากทีมรับมือเหตุฉุกเฉินทางไซเบอร์ของ DHS Industrial Control Systems และที่ปรึกษาของ Philips ได้เตือนผู้ใช้ถึงช่องโหว่ที่อาจเกิดขึ้นใน แอ ป Philips HealthSuite Health สำหรับ Android

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

แนวทางปฏิบัติที่ดีที่สุดที่ควรหลีกเลี่ยง:

• ในการแก้ปัญหา OWASP Top 10 Mobile ความเสี่ยง ที่เกิดขึ้นบ่อยที่สุด นักพัฒนาต้องเลือกอัลกอริธึมการเข้ารหัสที่ทันสมัยเพื่อเข้ารหัสแอปของตน การเลือกอัลกอริทึมจะดูแลช่องโหว่ในระดับที่ดี
• หากผู้พัฒนาไม่ใช่ผู้เชี่ยวชาญด้านความปลอดภัย พวกเขาต้องละเว้นจากการสร้างรหัสเข้ารหัสของตัวเอง

M6: ความเสี่ยงในการอนุญาตที่ไม่ปลอดภัย

ในกรณีนี้ ตัวแทนภัยคุกคามสามารถเข้าถึงแอปพลิเคชันของผู้อื่นได้ตามปกติผ่านการโจมตีอัตโนมัติซึ่งใช้เครื่องมือที่สร้างขึ้นเองหรือเครื่องมือที่พร้อมใช้งาน

สามารถนำไปสู่ปัญหาต่อไปนี้:

• ขโมยข้อมูล
• ความเสียหายต่อชื่อเสียง
• การฉ้อโกง

กรณีในโลกแห่งความเป็นจริง :

ผู้เชี่ยวชาญด้านความปลอดภัยของข้อมูลที่ Pen Test Partners แฮ็ก ระบบเตือนภัยรถอัจฉริยะ Pandora ตามทฤษฎีแล้ว แอปพลิเคชั่นนี้ใช้เพื่อติดตามรถ ตัดเครื่องยนต์หากถูกขโมย และล็อครถจนกว่าตำรวจจะมาถึง

อีกด้านหนึ่งของเหรียญ แฮ็กเกอร์สามารถจี้บัญชีและเข้าถึงข้อมูลทั้งหมดและฟังก์ชันการแจ้งเตือนอัจฉริยะ นอกจากนี้ พวกเขาสามารถ:

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

แนวทางปฏิบัติที่ดีที่สุดที่ควรหลีกเลี่ยง:

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

M7: ความเสี่ยงด้านคุณภาพของโค้ดไม่ดี

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

กรณีในโลกแห่งความเป็นจริง :

ปีที่แล้ว WhatsApp ได้แก้ไขช่องโหว่ที่แฮ็กเกอร์ใช้ประโยชน์จากการติดตั้งมัลแวร์เฝ้าระวังที่เรียกว่า Pegasus Spyware บนสมาร์ทโฟน สิ่งที่พวกเขาต้องทำคือโทรผ่านเสียงของ WhatsApp ไปยังหมายเลขโทรศัพท์เป้าหมาย

ภายในไม่กี่ขั้นตอนง่ายๆ แฮกเกอร์สามารถเข้าไปในอุปกรณ์ของผู้ใช้และเข้าถึงได้จากระยะไกล

แนวทางปฏิบัติที่ดีที่สุดที่ควรหลีกเลี่ยง:

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

M8: ความเสี่ยงจากการปลอมแปลงรหัส

โดยปกติ ในกรณีนี้ ผู้โจมตีจะใช้ประโยชน์จากการแก้ไขโค้ดผ่านรูปแบบที่เป็นอันตรายของแอปที่โฮสต์อยู่ในร้านแอปของบุคคลที่สาม พวกเขายังอาจหลอกให้ผู้ใช้ติดตั้งแอปพลิเคชันผ่านการโจมตีแบบฟิชชิง

แนวทางปฏิบัติที่ดีที่สุดที่ควรหลีกเลี่ยง:

• นักพัฒนาซอฟต์แวร์ต้องตรวจสอบให้แน่ใจว่าแอปสามารถตรวจจับการเปลี่ยนแปลงโค้ดได้ในขณะใช้งานจริง
• ต้องตรวจสอบไฟล์ build.prop ว่ามี ROM ที่ไม่เป็นทางการใน Android หรือไม่ และตรวจสอบว่าอุปกรณ์ได้รับการรูทหรือไม่
• นักพัฒนาต้องใช้เช็คซัมและประเมินลายเซ็นดิจิทัลเพื่อดูว่ามีการแก้ไขไฟล์หรือไม่
• ผู้เข้ารหัสสามารถตรวจสอบให้แน่ใจว่าคีย์ของแอป โค้ด และข้อมูลจะถูกลบออกเมื่อพบการปลอมแปลง

M9: ความเสี่ยงด้านวิศวกรรมย้อนกลับ

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

กรณีในโลกแห่งความเป็นจริง :

เมื่อเร็วๆ นี้ Pokemon Go ต้องเผชิญกับการละเมิดความปลอดภัยเมื่อพบว่าผู้ใช้ได้ทำวิศวกรรมย้อนกลับแอปเพื่อทราบบริเวณใกล้เคียงของ Pokemons และจับพวกเขาในไม่กี่นาที

แนวทางปฏิบัติที่ดีที่สุดที่ควรหลีกเลี่ยง:

• วิธีที่ดีที่สุดที่จะปกป้องแอปจากความเสี่ยง ตาม OWASP mobile security คือการใช้เครื่องมือเดียวกับที่แฮกเกอร์ใช้สำหรับวิศวกรรมย้อนกลับ
• นักพัฒนายังต้องสร้างความสับสนให้กับซอร์สโค้ดเพื่อให้อ่านยากและทำวิศวกรรมย้อนกลับ

M10: ความเสี่ยงจากการทำงานภายนอก

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

กรณีในโลกแห่งความเป็นจริง :

แนวคิดของแอป Wifi File Transfer คือการเปิดพอร์ตบน Android และอนุญาตการเชื่อมต่อจากคอมพิวเตอร์ ปัญหา ? ไม่มีการพิสูจน์ตัวตน เช่น รหัสผ่าน หมายความว่าทุกคนสามารถเชื่อมต่อกับอุปกรณ์และเข้าถึงได้เต็มรูปแบบ

แนวทางปฏิบัติที่ดีที่สุดที่ควรหลีกเลี่ยง:

• ตรวจสอบให้แน่ใจว่าไม่มีโค้ดทดสอบใน build ขั้นสุดท้าย
• ตรวจสอบให้แน่ใจว่าไม่มีสวิตช์ที่ซ่อนอยู่ในการตั้งค่าการกำหนดค่า
• บันทึกต้องไม่มีคำอธิบายกระบวนการเซิร์ฟเวอร์แบ็กเอนด์
• ตรวจสอบให้แน่ใจว่าบันทึกของระบบทั้งหมดไม่ได้เปิดเผยต่อแอปโดย OEM
• ปลายทาง API จะต้องมีการจัดทำเอกสารไว้อย่างดี