Siam Thanat Hack Co., Ltd.

OWASP Mobile Top 10:2024 สรุปความปลอดภัยแอปมือถือ

สรุป 10 หมวดความเสี่ยงสำคัญตามมาตรฐาน OWASP Mobile Top 10:2024 สำหรับแอปพลิเคชันบนระบบปฏิบัติการ Android และ iOS รวมถึงบริการ Backend และ API ที่เกี่ยวข้อง

อ้างอิงตามกรอบ OWASP ฉบับปี 2024 โดยระบุชื่อหมวดความเสี่ยงตามเอกสารทางการ

M1

Improper Credential Usage

Improper Credential Usage คือแอปมือถือฝัง, เก็บ, ส่ง หรือใช้ Password, API Key, Token หรือ Session อย่างไม่ปลอดภัย เช่น Hardcode Secret ใน Binary หรือเก็บรหัสผ่านในพื้นที่ทั่วไปของเครื่อง เมื่อแอปถูก Reverse Engineer หรือโทรศัพท์สูญหาย ผู้โจมตีอาจนำข้อมูลยืนยันตัวตนไปใช้กับ Backend ได้

สรุปความเสี่ยงแบบย่อ
สิ่งที่อาจผิดพลาดSecret, Token, API Key หรือรหัสผ่าน ถูกฝังในโค้ด นำกลับมาใช้ซ้ำ เปิดเผยสู่ภายนอก หรือจัดการโดยไม่มีวงจรชีวิตความปลอดภัยที่เหมาะสม
ผลกระทบต่อธุรกิจแพ็กเกจแอปพลิเคชันที่ถูกวิเคราะห์ย้อนกลับ หรือ Token ที่รั่วไหล อาจทำให้ผู้โจมตีเข้าถึงระบบ Backend หรือฟังก์ชันที่ได้รับการปกป้องได้อย่างต่อเนื่อง
จุดควบคุมแรกที่ควรตรวจไม่เก็บ Secret ระยะยาวไว้ในอุปกรณ์ฝั่ง Client
M1 Improper Credential Usage: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, มาตรการลดความเสี่ยง
M1 Improper Credential Usage

แอปบนอุปกรณ์ผู้ใช้ไม่ใช่ที่เก็บข้อมูลลับที่เชื่อถือได้

  • จุดเริ่มโจมตี — ผู้โจมตีแยก APK เพื่อดึง API Key หรือ Token ที่ฝังไว้
  • การควบคุมที่ล้มเหลว — Client เก็บหรือใช้ Secret ระยะยาวโดยไม่มีวงจรชีวิตที่เหมาะสม
  • ผลกระทบ — Token ที่รั่วให้สิทธิ์เข้าถึง Backend หรือฟังก์ชันที่ได้รับการป้องกันได้
  • มาตรการลดความเสี่ยง — ไม่เก็บ Secret ระยะยาวใน Client และออก Token อายุสั้นจาก Server

ภาพเปรียบเทียบเส้นทางที่ไม่ปลอดภัยกับจุดควบคุมที่ตัดเส้นทางนั้น กดภาพเพื่อดูขนาดเต็ม

ผลกระทบที่ควรพิจารณา

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

แนวทางลดความเสี่ยง

  • ไม่เก็บ Secret ระยะยาวไว้ในอุปกรณ์ฝั่ง Client
  • ใช้ข้อมูลยืนยันตัวตนที่จำกัดขอบเขต สามารถเพิกถอนและหมุนเวียนเปลี่ยนรหัสได้
  • ปกป้องจุดกรอกข้อมูลและช่องทางส่งข้อมูลยืนยันตัวตน
ตัวอย่าง Android ด้วย Kotlin

ตัวอย่างที่มีช่องโหว่

import android.content.Intent
import android.net.Uri
import androidx.appcompat.app.AppCompatActivity

class RedirectActivity : AppCompatActivity() {
    fun openRedirect(intent: Intent) {
        val rawTarget = intent.data?.getQueryParameter("redirect") ?: return
        startActivity(Intent(Intent.ACTION_VIEW, Uri.parse(rawTarget)))
    }
}

ตัวอย่างที่แก้ไขแล้ว

import android.content.Intent
import android.net.Uri
import androidx.browser.customtabs.CustomTabsIntent
import androidx.appcompat.app.AppCompatActivity

class RedirectActivity : AppCompatActivity() {
    private val allowedHosts = setOf("app.example.com")

    fun openRedirect(intent: Intent) {
        val rawTarget = intent.data?.getQueryParameter("redirect") ?: return
        val target = Uri.parse(rawTarget)
        if (target.scheme != "https" || target.host !in allowedHosts) return
        CustomTabsIntent.Builder().build().launchUrl(this, target)
    }
}
ตัวอย่าง iOS ด้วย Swift

ตัวอย่างที่มีช่องโหว่

import UIKit

final class RedirectViewController: UIViewController {
    func openRedirect(rawTarget: String) {
        guard let target = URL(string: rawTarget) else { return }
        UIApplication.shared.open(target)
    }
}

ตัวอย่างที่แก้ไขแล้ว

import SafariServices
import UIKit

final class RedirectViewController: UIViewController {
    private let allowedHosts: Set<String> = ["app.example.com"]

    func openRedirect(rawTarget: String) {
        guard let target = URL(string: rawTarget),
              target.scheme == "https",
              let host = target.host,
              allowedHosts.contains(host) else { return }

        let browser = SFSafariViewController(url: target)
        present(browser, animated: true)
    }
}

M2

Inadequate Supply Chain Security

Inadequate Supply Chain Security คือแอป, SDK, Dependency, ระบบ Build หรือการเซ็น Package ไม่ได้รับการควบคุมแหล่งที่มาและความถูกต้องเพียงพอ SDK ภายนอกที่ถูกเปลี่ยน, Pipeline ที่ถูกยึด หรือ Signing Key รั่ว อาจทำให้แอปที่ติดตั้งบนเครื่องผู้ใช้ทำสิ่งที่ทีมไม่ได้ตั้งใจ

สรุปความเสี่ยงแบบย่อ
สิ่งที่อาจผิดพลาดSDK มือถือ, Build Plugin, ระบบลงนามดิจิทัล และ Dependency ภายนอก ขาดการกำกับดูแลและความปลอดภัยในห่วงโซ่อุปทานที่เพียงพอ
ผลกระทบต่อธุรกิจSDK หรือ Release Pipeline ที่ถูกโจมตีอาจฝังระบบติดตาม แอบส่งออกข้อมูลสำคัญ หรือเปลี่ยนแปลงพฤติกรรมการทำงานของแอปพลิเคชัน
จุดควบคุมแรกที่ควรตรวจจัดทำบัญชี SDK ภายนอกและตรวจสอบเส้นทางการรับส่งข้อมูล
M2 Inadequate Supply Chain Security: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, การหยุดการโจมตี
M2 Inadequate Supply Chain Security

ความปลอดภัยของแอปมือถือขึ้นกับทุก SDK ระบบ Build และกุญแจลงนาม

  • จุดเริ่มโจมตี — SDK ภายนอกหรือระบบเซ็น Package ถูกยึดก่อนเข้าสู่ Release
  • การควบคุมที่ล้มเหลว — ทีมไม่กำกับ SDK Plugin Build และการกระจายแอปอย่างเพียงพอ
  • ผลกระทบ — แอป Release มีการติดตาม เปิดเผยข้อมูล หรือพฤติกรรมที่ถูกเปลี่ยน
  • การหยุดการโจมตี — จัดทำบัญชี SDK และ Data Flow พร้อมตรวจที่มาและเจ้าของ Dependency

ภาพเปรียบเทียบเส้นทางที่ไม่ปลอดภัยกับจุดควบคุมที่ตัดเส้นทางนั้น กดภาพเพื่อดูขนาดเต็ม

ผลกระทบที่ควรพิจารณา

SDK หรือ Release Pipeline ที่ถูกโจมตีอาจฝังระบบติดตาม แอบส่งออกข้อมูลสำคัญ หรือเปลี่ยนแปลงพฤติกรรมการทำงานของแอปพลิเคชัน

แนวทางลดความเสี่ยง

  • จัดทำบัญชี SDK ภายนอกและตรวจสอบเส้นทางการรับส่งข้อมูล
  • จำกัดและตรวจสอบสิทธิ์ในการลงนามดิจิทัลและการ Release แอปพลิเคชัน
  • ตรวจสอบที่มา ความถูกต้องสมบูรณ์ และประกาศอัปเดตของแพ็กเกจ
ตัวอย่าง Android ด้วย Kotlin

ตัวอย่างที่มีช่องโหว่

import android.content.Intent
import android.net.Uri
import androidx.appcompat.app.AppCompatActivity

class RedirectActivity : AppCompatActivity() {
    fun openRedirect(intent: Intent) {
        val rawTarget = intent.data?.getQueryParameter("redirect") ?: return
        startActivity(Intent(Intent.ACTION_VIEW, Uri.parse(rawTarget)))
    }
}

ตัวอย่างที่แก้ไขแล้ว

import android.content.Intent
import android.net.Uri
import androidx.browser.customtabs.CustomTabsIntent
import androidx.appcompat.app.AppCompatActivity

class RedirectActivity : AppCompatActivity() {
    private val allowedHosts = setOf("app.example.com")

    fun openRedirect(intent: Intent) {
        val rawTarget = intent.data?.getQueryParameter("redirect") ?: return
        val target = Uri.parse(rawTarget)
        if (target.scheme != "https" || target.host !in allowedHosts) return
        CustomTabsIntent.Builder().build().launchUrl(this, target)
    }
}
ตัวอย่าง iOS ด้วย Swift

ตัวอย่างที่มีช่องโหว่

import UIKit

final class RedirectViewController: UIViewController {
    func openRedirect(rawTarget: String) {
        guard let target = URL(string: rawTarget) else { return }
        UIApplication.shared.open(target)
    }
}

ตัวอย่างที่แก้ไขแล้ว

import SafariServices
import UIKit

final class RedirectViewController: UIViewController {
    private let allowedHosts: Set<String> = ["app.example.com"]

    func openRedirect(rawTarget: String) {
        guard let target = URL(string: rawTarget),
              target.scheme == "https",
              let host = target.host,
              allowedHosts.contains(host) else { return }

        let browser = SFSafariViewController(url: target)
        present(browser, animated: true)
    }
}

M3

Insecure Authentication and Authorization

Insecure Authentication and Authorization คือแอปยืนยันว่าใครเป็นผู้ใช้หรืออนุญาตให้ทำอะไรไม่ถูกต้อง เช่น ไม่ตรวจ Token ให้ครบ, เชื่อ Role ที่ส่งจาก Client, หรือปล่อย Session ใช้ต่อหลัง Logout ผู้โจมตีอาจยึดบัญชี ใช้ข้อมูลของผู้อื่น หรือเรียกฟังก์ชันที่ควรจำกัดเฉพาะบทบาทได้

สรุปความเสี่ยงแบบย่อ
สิ่งที่อาจผิดพลาดแอปพลิเคชันหรือระบบ Backend ยอมรับกระบวนการยืนยันตัวตน การจัดการ Session หรือการกำหนดสิทธิ์ที่มีช่องโหว่
ผลกระทบต่อธุรกิจผู้ใช้บนอุปกรณ์หรือผู้โจมตีจากระยะไกลอาจเข้าถึงบัญชี ฟีเจอร์ หรือชุดข้อมูลของผู้อื่นโดยมิชอบ
จุดควบคุมแรกที่ควรตรวจตรวจสอบสิทธิ์คำขอบนระบบ Backend เสมอ ไม่พึ่งพาการตรวจฝั่งแอปเพียงอย่างเดียว
M3 Insecure Authentication and Authorization: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, การหยุดการโจมตี
M3 Insecure Authentication and Authorization

การควบคุมบนแอปไม่แทนการยืนยันสิทธิ์จาก Backend

  • จุดเริ่มโจมตี — แอปที่ถูกแก้ไขส่ง Role หรือ Token ที่ไม่ผ่านการตรวจสอบไป Backend
  • การควบคุมที่ล้มเหลว — ระบบเชื่อการตัดสินใจตัวตนและสิทธิ์จาก Client
  • ผลกระทบ — ผู้ใช้หรือผู้โจมตีเข้าถึงบัญชี ฟังก์ชัน หรือข้อมูลของผู้อื่นได้
  • การหยุดการโจมตี — ยืนยัน Token และตรวจสิทธิ์ทุกคำขอบน Backend

ภาพเปรียบเทียบเส้นทางที่ไม่ปลอดภัยกับจุดควบคุมที่ตัดเส้นทางนั้น กดภาพเพื่อดูขนาดเต็ม

ผลกระทบที่ควรพิจารณา

ผู้ใช้บนอุปกรณ์หรือผู้โจมตีจากระยะไกลอาจเข้าถึงบัญชี ฟีเจอร์ หรือชุดข้อมูลของผู้อื่นโดยมิชอบ

แนวทางลดความเสี่ยง

  • ตรวจสอบสิทธิ์คำขอบนระบบ Backend เสมอ ไม่พึ่งพาการตรวจฝั่งแอปเพียงอย่างเดียว
  • ใช้ Session ที่ปลอดภัยและระบบ MFA ตามระดับความเสี่ยง
  • ทดสอบการเข้าถึงจาก Deep Link, Component ของแอป และออบเจ็กต์บน Backend
ตัวอย่าง Android ด้วย Kotlin

ตัวอย่างที่มีช่องโหว่

import android.content.Intent
import android.net.Uri
import androidx.appcompat.app.AppCompatActivity

class RedirectActivity : AppCompatActivity() {
    fun openRedirect(intent: Intent) {
        val rawTarget = intent.data?.getQueryParameter("redirect") ?: return
        startActivity(Intent(Intent.ACTION_VIEW, Uri.parse(rawTarget)))
    }
}

ตัวอย่างที่แก้ไขแล้ว

import android.content.Intent
import android.net.Uri
import androidx.browser.customtabs.CustomTabsIntent
import androidx.appcompat.app.AppCompatActivity

class RedirectActivity : AppCompatActivity() {
    private val allowedHosts = setOf("app.example.com")

    fun openRedirect(intent: Intent) {
        val rawTarget = intent.data?.getQueryParameter("redirect") ?: return
        val target = Uri.parse(rawTarget)
        if (target.scheme != "https" || target.host !in allowedHosts) return
        CustomTabsIntent.Builder().build().launchUrl(this, target)
    }
}
ตัวอย่าง iOS ด้วย Swift

ตัวอย่างที่มีช่องโหว่

import UIKit

final class RedirectViewController: UIViewController {
    func openRedirect(rawTarget: String) {
        guard let target = URL(string: rawTarget) else { return }
        UIApplication.shared.open(target)
    }
}

ตัวอย่างที่แก้ไขแล้ว

import SafariServices
import UIKit

final class RedirectViewController: UIViewController {
    private let allowedHosts: Set<String> = ["app.example.com"]

    func openRedirect(rawTarget: String) {
        guard let target = URL(string: rawTarget),
              target.scheme == "https",
              let host = target.host,
              allowedHosts.contains(host) else { return }

        let browser = SFSafariViewController(url: target)
        present(browser, animated: true)
    }
}

M4

Insufficient Input/Output Validation

Insufficient Input/Output Validation คือแอปเชื่อ Deep Link, QR, Intent, File, Response จาก Server หรือข้อมูลที่แสดงผลโดยไม่ตรวจรูปแบบ แหล่งที่มา และขอบเขตก่อนใช้งาน ข้อมูลที่ดัดแปลงจึงอาจพาแอปเปิดปลายทางที่ไม่ปลอดภัย, ทำงานผิด Flow หรือส่งข้อมูลกลับออกไปผิดที่

สรุปความเสี่ยงแบบย่อ
สิ่งที่อาจผิดพลาดข้อมูลที่ส่งข้ามระหว่างแอปพลิเคชัน อุปกรณ์ ระบบ Backend เบราว์เซอร์ หรือบริการภายนอก ถูกเชื่อถือโดยไม่มีการตรวจสอบรูปแบบและความถูกต้องอย่างเพียงพอ
ผลกระทบต่อธุรกิจเนื้อหาที่เป็นอันตรายอาจเปลี่ยนแปลงขั้นตอนการทำงานของแอป แสดงผลอย่างไม่ปลอดภัย หรือทำให้ระบบ Backend ดำเนินการที่ไม่ปลอดภัย
จุดควบคุมแรกที่ควรตรวจตรวจสอบข้อมูลภายนอกทั้งหมด ณ ทุกจุดเชื่อมต่อความเชื่อถือ
M4 Insufficient Input/Output Validation: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, การหยุดการโจมตี
M4 Insufficient Input/Output Validation

ข้อมูลที่ผ่านอุปกรณ์ แอป Backend และบริการภายนอกต้องตรวจซ้ำตามบริบท

  • จุดเริ่มโจมตี — Deep Link หรือข้อมูลภายนอกที่ดัดแปลงถูกส่งเข้าสู่แอป
  • การควบคุมที่ล้มเหลว — แอปเชื่อข้อมูลข้ามขอบเขตโดยไม่ตรวจรูปแบบ แหล่งที่มา และขอบเขต
  • ผลกระทบ — ข้อมูลอันตรายเปลี่ยน Flow แสดงผลไม่ปลอดภัย หรือสั่งงาน Backend ผิด
  • การหยุดการโจมตี — ตรวจข้อมูลภายนอกทุกชนิดที่แต่ละ Trust Boundary

ภาพเปรียบเทียบเส้นทางที่ไม่ปลอดภัยกับจุดควบคุมที่ตัดเส้นทางนั้น กดภาพเพื่อดูขนาดเต็ม

ผลกระทบที่ควรพิจารณา

เนื้อหาที่เป็นอันตรายอาจเปลี่ยนแปลงขั้นตอนการทำงานของแอป แสดงผลอย่างไม่ปลอดภัย หรือทำให้ระบบ Backend ดำเนินการที่ไม่ปลอดภัย

แนวทางลดความเสี่ยง

  • ตรวจสอบข้อมูลภายนอกทั้งหมด ณ ทุกจุดเชื่อมต่อความเชื่อถือ
  • Encode ข้อมูลออกให้เหมาะสมกับบริบทของการแสดงผล
  • ใช้ Schema ชนิดข้อมูลที่ชัดเจนและปฏิเสธ Field ที่ไม่คาดคิด
ตัวอย่าง Android ด้วย Kotlin

ตัวอย่างที่มีช่องโหว่

import android.content.Intent
import android.net.Uri
import androidx.appcompat.app.AppCompatActivity

class RedirectActivity : AppCompatActivity() {
    fun openRedirect(intent: Intent) {
        val rawTarget = intent.data?.getQueryParameter("redirect") ?: return
        startActivity(Intent(Intent.ACTION_VIEW, Uri.parse(rawTarget)))
    }
}

ตัวอย่างที่แก้ไขแล้ว

import android.content.Intent
import android.net.Uri
import androidx.browser.customtabs.CustomTabsIntent
import androidx.appcompat.app.AppCompatActivity

class RedirectActivity : AppCompatActivity() {
    private val allowedHosts = setOf("app.example.com")

    fun openRedirect(intent: Intent) {
        val rawTarget = intent.data?.getQueryParameter("redirect") ?: return
        val target = Uri.parse(rawTarget)
        if (target.scheme != "https" || target.host !in allowedHosts) return
        CustomTabsIntent.Builder().build().launchUrl(this, target)
    }
}
ตัวอย่าง iOS ด้วย Swift

ตัวอย่างที่มีช่องโหว่

import UIKit

final class RedirectViewController: UIViewController {
    func openRedirect(rawTarget: String) {
        guard let target = URL(string: rawTarget) else { return }
        UIApplication.shared.open(target)
    }
}

ตัวอย่างที่แก้ไขแล้ว

import SafariServices
import UIKit

final class RedirectViewController: UIViewController {
    private let allowedHosts: Set<String> = ["app.example.com"]

    func openRedirect(rawTarget: String) {
        guard let target = URL(string: rawTarget),
              target.scheme == "https",
              let host = target.host,
              allowedHosts.contains(host) else { return }

        let browser = SFSafariViewController(url: target)
        present(browser, animated: true)
    }
}

M5

Insecure Communication

Insecure Communication คือข้อมูลระหว่างแอปกับบริการไม่ได้รับการปกป้องจากการดักฟังหรือแก้ไขอย่างพอเพียง เช่น ยอมรับ Certificate ที่ไม่น่าเชื่อถือ, ใช้ HTTP, ตรวจ TLS ไม่ครบ หรือส่งข้อมูลลับผ่านช่องทางอื่นที่ไม่ปลอดภัย ผู้โจมตีบนเครือข่ายเดียวกันจึงอาจอ่านข้อความหรือแทรกข้อมูลได้

สรุปความเสี่ยงแบบย่อ
สิ่งที่อาจผิดพลาดการรับส่งข้อมูลผ่านเครือข่าย การตรวจสอบใบรับรอง หรือการเลือกใช้ช่องทางสื่อสาร ไม่ได้ปกป้องข้อมูลระหว่างการรับส่งอย่างปลอดภัย
ผลกระทบต่อธุรกิจผู้โจมตีบนเครือข่ายที่ไม่ปลอดภัยอาจดักดู แก้ไข หรือเปลี่ยนทิศทางการรับส่งข้อมูลสำคัญได้
จุดควบคุมแรกที่ควรตรวจบังคับใช้โปรโตคอล TLS เวอร์ชันปัจจุบันสำหรับการเชื่อมต่อสำคัญ
M5 Insecure Communication: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, การหยุดการโจมตี
M5 Insecure Communication

การเข้ารหัสระหว่างทางต้องป้องกันทั้งการดักฟังและการแก้ไขข้อมูล

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

ภาพเปรียบเทียบเส้นทางที่ไม่ปลอดภัยกับจุดควบคุมที่ตัดเส้นทางนั้น กดภาพเพื่อดูขนาดเต็ม

ผลกระทบที่ควรพิจารณา

ผู้โจมตีบนเครือข่ายที่ไม่ปลอดภัยอาจดักดู แก้ไข หรือเปลี่ยนทิศทางการรับส่งข้อมูลสำคัญได้

แนวทางลดความเสี่ยง

  • บังคับใช้โปรโตคอล TLS เวอร์ชันปัจจุบันสำหรับการเชื่อมต่อสำคัญ
  • ตรวจสอบใบรับรองดิจิทัลและหลีกเลี่ยงพฤติกรรมที่ยอมรับทุกใบรับรอง
  • ลดการส่งข้อมูลสำคัญในคำขอและข้อมูลวินิจฉัย
ตัวอย่าง Android ด้วย Kotlin

ตัวอย่างที่มีช่องโหว่

import android.content.Intent
import android.net.Uri
import androidx.appcompat.app.AppCompatActivity

class RedirectActivity : AppCompatActivity() {
    fun openRedirect(intent: Intent) {
        val rawTarget = intent.data?.getQueryParameter("redirect") ?: return
        startActivity(Intent(Intent.ACTION_VIEW, Uri.parse(rawTarget)))
    }
}

ตัวอย่างที่แก้ไขแล้ว

import android.content.Intent
import android.net.Uri
import androidx.browser.customtabs.CustomTabsIntent
import androidx.appcompat.app.AppCompatActivity

class RedirectActivity : AppCompatActivity() {
    private val allowedHosts = setOf("app.example.com")

    fun openRedirect(intent: Intent) {
        val rawTarget = intent.data?.getQueryParameter("redirect") ?: return
        val target = Uri.parse(rawTarget)
        if (target.scheme != "https" || target.host !in allowedHosts) return
        CustomTabsIntent.Builder().build().launchUrl(this, target)
    }
}
ตัวอย่าง iOS ด้วย Swift

ตัวอย่างที่มีช่องโหว่

import UIKit

final class RedirectViewController: UIViewController {
    func openRedirect(rawTarget: String) {
        guard let target = URL(string: rawTarget) else { return }
        UIApplication.shared.open(target)
    }
}

ตัวอย่างที่แก้ไขแล้ว

import SafariServices
import UIKit

final class RedirectViewController: UIViewController {
    private let allowedHosts: Set<String> = ["app.example.com"]

    func openRedirect(rawTarget: String) {
        guard let target = URL(string: rawTarget),
              target.scheme == "https",
              let host = target.host,
              allowedHosts.contains(host) else { return }

        let browser = SFSafariViewController(url: target)
        present(browser, animated: true)
    }
}

M6

Inadequate Privacy Controls

Inadequate Privacy Controls คือแอปเก็บ ใช้ เปิดเผย หรือเก็บรักษาข้อมูลส่วนบุคคลเกินวัตถุประสงค์หรือโดยไม่มีการควบคุมที่เข้าใจได้ เช่น ขอ Permission เกินจำเป็น, ส่ง Analytics ที่ระบุตัวบุคคลได้ หรือไม่มีทางให้ผู้ใช้จัดการ Consent ความเสี่ยงครอบคลุมทั้งผู้ใช้ ความเชื่อมั่น และข้อกำหนดด้านข้อมูลส่วนบุคคล

สรุปความเสี่ยงแบบย่อ
สิ่งที่อาจผิดพลาดแอปพลิเคชันรวบรวม แบ่งปัน จัดเก็บ หรือเปิดเผยข้อมูลส่วนบุคคลเกินกว่าวัตถุประสงค์ที่ได้แจ้งไว้และเกินความจำเป็น
ผลกระทบต่อธุรกิจผู้ใช้อาจสูญเสียการควบคุมข้อมูลส่วนบุคคลผ่านระบบ Telemetry, Permission, ระบบวิเคราะห์การใช้งาน หรือการแบ่งปันข้อมูลกับบุคคลที่สาม
จุดควบคุมแรกที่ควรตรวจทำแผนที่การจัดเก็บข้อมูลส่วนบุคคลและรายชื่อผู้รับข้อมูล
M6 Inadequate Privacy Controls: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, การหยุดการโจมตี
M6 Inadequate Privacy Controls

การเก็บข้อมูลส่วนบุคคลต้องจำเป็น โปร่งใส และควบคุมได้

  • จุดเริ่มโจมตี — แอปขอ Permission เกินจำเป็นและส่ง Analytics ที่ระบุตัวบุคคลได้
  • การควบคุมที่ล้มเหลว — ไม่มีการกำกับวัตถุประสงค์ ผู้รับข้อมูล และระยะเวลาเก็บรักษาอย่างชัดเจน
  • ผลกระทบ — ผู้ใช้สูญเสียการควบคุมข้อมูลส่วนบุคคลผ่าน Telemetry หรือการแชร์ภายนอก
  • การหยุดการโจมตี — ทำแผนที่ข้อมูล ลดการเก็บ และควบคุม Consent กับผู้รับข้อมูล

ภาพเปรียบเทียบเส้นทางที่ไม่ปลอดภัยกับจุดควบคุมที่ตัดเส้นทางนั้น กดภาพเพื่อดูขนาดเต็ม

ผลกระทบที่ควรพิจารณา

ผู้ใช้อาจสูญเสียการควบคุมข้อมูลส่วนบุคคลผ่านระบบ Telemetry, Permission, ระบบวิเคราะห์การใช้งาน หรือการแบ่งปันข้อมูลกับบุคคลที่สาม

แนวทางลดความเสี่ยง

  • ทำแผนที่การจัดเก็บข้อมูลส่วนบุคคลและรายชื่อผู้รับข้อมูล
  • ขอ Permission เฉพาะที่จำเป็นและในเวลาที่เหมาะสม
  • ใช้มาตรการควบคุมระยะเวลาจัดเก็บ ความยินยอม และการลบข้อมูล
ตัวอย่าง Android ด้วย Kotlin

ตัวอย่างที่มีช่องโหว่

import android.content.Intent
import android.net.Uri
import androidx.appcompat.app.AppCompatActivity

class RedirectActivity : AppCompatActivity() {
    fun openRedirect(intent: Intent) {
        val rawTarget = intent.data?.getQueryParameter("redirect") ?: return
        startActivity(Intent(Intent.ACTION_VIEW, Uri.parse(rawTarget)))
    }
}

ตัวอย่างที่แก้ไขแล้ว

import android.content.Intent
import android.net.Uri
import androidx.browser.customtabs.CustomTabsIntent
import androidx.appcompat.app.AppCompatActivity

class RedirectActivity : AppCompatActivity() {
    private val allowedHosts = setOf("app.example.com")

    fun openRedirect(intent: Intent) {
        val rawTarget = intent.data?.getQueryParameter("redirect") ?: return
        val target = Uri.parse(rawTarget)
        if (target.scheme != "https" || target.host !in allowedHosts) return
        CustomTabsIntent.Builder().build().launchUrl(this, target)
    }
}
ตัวอย่าง iOS ด้วย Swift

ตัวอย่างที่มีช่องโหว่

import UIKit

final class RedirectViewController: UIViewController {
    func openRedirect(rawTarget: String) {
        guard let target = URL(string: rawTarget) else { return }
        UIApplication.shared.open(target)
    }
}

ตัวอย่างที่แก้ไขแล้ว

import SafariServices
import UIKit

final class RedirectViewController: UIViewController {
    private let allowedHosts: Set<String> = ["app.example.com"]

    func openRedirect(rawTarget: String) {
        guard let target = URL(string: rawTarget),
              target.scheme == "https",
              let host = target.host,
              allowedHosts.contains(host) else { return }

        let browser = SFSafariViewController(url: target)
        present(browser, animated: true)
    }
}

M7

Insufficient Binary Protections

Insufficient Binary Protections คือ Binary ของแอปเปิดให้ถูกแกะ วิเคราะห์ ดัดแปลง หรือ Repack ได้ง่ายจนกลไกป้องกันที่อยู่ฝั่ง Client ถูกข้ามได้ เช่น ไม่มี Tamper Detection หรือไม่ตรวจว่าแอปทำงานบนเครื่องที่ถูกดัดแปลง การป้องกันนี้ไม่แทน Server-side Control แต่ช่วยเพิ่มต้นทุนและสัญญาณตรวจจับการโจมตี

สรุปความเสี่ยงแบบย่อ
สิ่งที่อาจผิดพลาดไฟล์ Binary ของแอปพลิเคชันไม่มีกลไกป้องกันการแกะโค้ด การดัดแปลงแก้ไข หรือการบรรจุใหม่ที่เหมาะสมตาม Threat Model
ผลกระทบต่อธุรกิจแอปพลิเคชันฝั่ง Client ที่ถูกแก้ไขอาจปลดมาตรการความปลอดภัย เปิดเผยตรรกะภายใน หรือปลอมเป็นแอปพลิเคชันจริงเพื่อหลอกลวงผู้ใช้
จุดควบคุมแรกที่ควรตรวจเก็บการตัดสินใจด้านความเชื่อถือและ Secret ไว้บนระบบ Backend
M7 Insufficient Binary Protections: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, การหยุดการโจมตี
M7 Insufficient Binary Protections

การป้องกัน Binary เพิ่มต้นทุนโจมตี แต่การบังคับใช้สิทธิ์ต้องอยู่ฝั่ง Server

  • จุดเริ่มโจมตี — ผู้โจมตีแกะ วิเคราะห์ และ Repackage Binary ของแอป
  • การควบคุมที่ล้มเหลว — แอปต้านการแก้ไขหรือวิเคราะห์ไม่พอตาม Threat Model
  • ผลกระทบ — Client ที่ถูกแก้ไขลบกลไกป้องกันหรือแอบอ้างเป็นแอปที่เชื่อถือได้
  • การหยุดการโจมตี — เก็บ Secret และการตัดสินใจเชื่อถือไว้ Server พร้อมตรวจ Tamper

ภาพเปรียบเทียบเส้นทางที่ไม่ปลอดภัยกับจุดควบคุมที่ตัดเส้นทางนั้น กดภาพเพื่อดูขนาดเต็ม

ผลกระทบที่ควรพิจารณา

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

แนวทางลดความเสี่ยง

  • เก็บการตัดสินใจด้านความเชื่อถือและ Secret ไว้บนระบบ Backend
  • ใช้การลงนามดิจิทัลของแพลตฟอร์มและสัญญาณตรวจเช็กความสมบูรณ์
  • ตรวจจับการแก้ไขแอปพลิเคชันและวางแผนการตอบสนองที่ปลอดภัย
ตัวอย่าง Android ด้วย Kotlin

ตัวอย่างที่มีช่องโหว่

import android.content.Intent
import android.net.Uri
import androidx.appcompat.app.AppCompatActivity

class RedirectActivity : AppCompatActivity() {
    fun openRedirect(intent: Intent) {
        val rawTarget = intent.data?.getQueryParameter("redirect") ?: return
        startActivity(Intent(Intent.ACTION_VIEW, Uri.parse(rawTarget)))
    }
}

ตัวอย่างที่แก้ไขแล้ว

import android.content.Intent
import android.net.Uri
import androidx.browser.customtabs.CustomTabsIntent
import androidx.appcompat.app.AppCompatActivity

class RedirectActivity : AppCompatActivity() {
    private val allowedHosts = setOf("app.example.com")

    fun openRedirect(intent: Intent) {
        val rawTarget = intent.data?.getQueryParameter("redirect") ?: return
        val target = Uri.parse(rawTarget)
        if (target.scheme != "https" || target.host !in allowedHosts) return
        CustomTabsIntent.Builder().build().launchUrl(this, target)
    }
}
ตัวอย่าง iOS ด้วย Swift

ตัวอย่างที่มีช่องโหว่

import UIKit

final class RedirectViewController: UIViewController {
    func openRedirect(rawTarget: String) {
        guard let target = URL(string: rawTarget) else { return }
        UIApplication.shared.open(target)
    }
}

ตัวอย่างที่แก้ไขแล้ว

import SafariServices
import UIKit

final class RedirectViewController: UIViewController {
    private let allowedHosts: Set<String> = ["app.example.com"]

    func openRedirect(rawTarget: String) {
        guard let target = URL(string: rawTarget),
              target.scheme == "https",
              let host = target.host,
              allowedHosts.contains(host) else { return }

        let browser = SFSafariViewController(url: target)
        present(browser, animated: true)
    }
}

M8

Security Misconfiguration

Security Misconfiguration บนมือถือคือการเปิดใช้ Capability, Component, Debug Setting, Permission หรือ Network Policy เกินความจำเป็น เช่น Exported Activity ที่ไม่ควรเปิด, Backup ที่นำข้อมูลออกได้ หรือ Debug Endpoint ที่ยังอยู่ใน Release แอปอาจถูกเรียกจากแอปอื่นหรือเปิดข้อมูลในลักษณะที่หน้าจอปกติไม่เคยอนุญาต

สรุปความเสี่ยงแบบย่อ
สิ่งที่อาจผิดพลาดการกำหนดค่าใน Build Variant, การตั้งค่าแพลตฟอร์ม, Component ที่เปิดเผยภายนอก หรือการตั้งค่า Backend ทำให้เกิดช่องโหว่ที่ไม่ตั้งใจ
ผลกระทบต่อธุรกิจฟีเจอร์สำหรับ Debug, Component ที่เปิดเผยภายนอก, การเปิดให้สำรองข้อมูลได้ หรือการตั้งค่าสื่อสารที่อ่อนแอ อาจถูกเข้าถึงได้ในเวอร์ชันใช้งานจริง
จุดควบคุมแรกที่ควรตรวจทบทวน Manifest ของเวอร์ชัน Release และการตั้งค่าแพลตฟอร์ม
M8 Security Misconfiguration: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, การหยุดการโจมตี
M8 Security Misconfiguration

การตั้งค่า Build และแพลตฟอร์มเป็นส่วนหนึ่งของพื้นที่โจมตีของแอป

  • จุดเริ่มโจมตี — แอปอื่นเรียก Component ที่ Exported หรือฟีเจอร์ Debug ใน Release
  • การควบคุมที่ล้มเหลว — Manifest และการตั้งค่า Platform ของเวอร์ชัน Release ไม่ผ่านการทบทวน
  • ผลกระทบ — ฟีเจอร์ Debug Backup ที่เปิดกว้าง หรือ Transport อ่อนแอถูกเข้าถึงได้
  • การหยุดการโจมตี — ทบทวน Release Manifest แยก Debug Production และตรวจอัตโนมัติใน CI

ภาพเปรียบเทียบเส้นทางที่ไม่ปลอดภัยกับจุดควบคุมที่ตัดเส้นทางนั้น กดภาพเพื่อดูขนาดเต็ม

ผลกระทบที่ควรพิจารณา

ฟีเจอร์สำหรับ Debug, Component ที่เปิดเผยภายนอก, การเปิดให้สำรองข้อมูลได้ หรือการตั้งค่าสื่อสารที่อ่อนแอ อาจถูกเข้าถึงได้ในเวอร์ชันใช้งานจริง

แนวทางลดความเสี่ยง

  • ทบทวน Manifest ของเวอร์ชัน Release และการตั้งค่าแพลตฟอร์ม
  • แยกการตั้งค่าระหว่าง Debug และ Production อย่างเด็ดขาด
  • ใช้ระบบอัตโนมัติในการตรวจเช็กการกำหนดค่าในขั้นตอน CI/CD
ตัวอย่าง Android ด้วย Kotlin

ตัวอย่างที่มีช่องโหว่

import android.content.Intent
import android.net.Uri
import androidx.appcompat.app.AppCompatActivity

class RedirectActivity : AppCompatActivity() {
    fun openRedirect(intent: Intent) {
        val rawTarget = intent.data?.getQueryParameter("redirect") ?: return
        startActivity(Intent(Intent.ACTION_VIEW, Uri.parse(rawTarget)))
    }
}

ตัวอย่างที่แก้ไขแล้ว

import android.content.Intent
import android.net.Uri
import androidx.browser.customtabs.CustomTabsIntent
import androidx.appcompat.app.AppCompatActivity

class RedirectActivity : AppCompatActivity() {
    private val allowedHosts = setOf("app.example.com")

    fun openRedirect(intent: Intent) {
        val rawTarget = intent.data?.getQueryParameter("redirect") ?: return
        val target = Uri.parse(rawTarget)
        if (target.scheme != "https" || target.host !in allowedHosts) return
        CustomTabsIntent.Builder().build().launchUrl(this, target)
    }
}
ตัวอย่าง iOS ด้วย Swift

ตัวอย่างที่มีช่องโหว่

import UIKit

final class RedirectViewController: UIViewController {
    func openRedirect(rawTarget: String) {
        guard let target = URL(string: rawTarget) else { return }
        UIApplication.shared.open(target)
    }
}

ตัวอย่างที่แก้ไขแล้ว

import SafariServices
import UIKit

final class RedirectViewController: UIViewController {
    private let allowedHosts: Set<String> = ["app.example.com"]

    func openRedirect(rawTarget: String) {
        guard let target = URL(string: rawTarget),
              target.scheme == "https",
              let host = target.host,
              allowedHosts.contains(host) else { return }

        let browser = SFSafariViewController(url: target)
        present(browser, animated: true)
    }
}

M9

Insecure Data Storage

Insecure Data Storage คือแอปบันทึกข้อมูลสำคัญไว้ในเครื่องโดยไม่มีการคุ้มครองที่เหมาะสม เช่น Shared Preferences, Cache, Log, Screenshot, Clipboard หรือไฟล์ Backup ที่อ่านได้ ข้อมูลอาจหลุดผ่านเครื่องที่ Root/Jailbreak, Backup, Malware หรือผู้ที่เข้าถึงอุปกรณ์ชั่วคราว

สรุปความเสี่ยงแบบย่อ
สิ่งที่อาจผิดพลาดข้อมูลสำคัญถูกจัดเก็บหรือบันทึก Cache ไว้ในอุปกรณ์ โดยไม่มีการคุ้มครองจนแอปอื่น ผู้ใช้เครื่อง ระบบสำรองข้อมูล หรือกระบวนการตรวจพิสูจน์สามารถเข้าถึงได้
ผลกระทบต่อธุรกิจหากอุปกรณ์สูญหาย ถูก Root หรือ Jailbreak มีผู้ใช้เครื่องร่วมกัน หรือถูกสำรองข้อมูล อาจทำให้ข้อมูลบัญชีผู้ใช้ ข้อมูลธุรกิจ หรือข้อมูลส่วนบุคคลหลุดรอดได้
จุดควบคุมแรกที่ควรตรวจลดการจัดเก็บข้อมูลสำคัญไว้ในอุปกรณ์และลดระยะเวลาของ Cache
M9 Insecure Data Storage: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, การหยุดการโจมตี
M9 Insecure Data Storage

ข้อมูลสำคัญที่ไม่ถูกเก็บในอุปกรณ์ย่อมไม่รั่วจากอุปกรณ์หรือ Backup

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

ภาพเปรียบเทียบเส้นทางที่ไม่ปลอดภัยกับจุดควบคุมที่ตัดเส้นทางนั้น กดภาพเพื่อดูขนาดเต็ม

ผลกระทบที่ควรพิจารณา

หากอุปกรณ์สูญหาย ถูก Root หรือ Jailbreak มีผู้ใช้เครื่องร่วมกัน หรือถูกสำรองข้อมูล อาจทำให้ข้อมูลบัญชีผู้ใช้ ข้อมูลธุรกิจ หรือข้อมูลส่วนบุคคลหลุดรอดได้

แนวทางลดความเสี่ยง

  • ลดการจัดเก็บข้อมูลสำคัญไว้ในอุปกรณ์และลดระยะเวลาของ Cache
  • ใช้ระบบจัดเก็บข้อมูลที่ได้รับการคุ้มครองจากแพลตฟอร์ม (เช่น Key Store / Keychain) สำหรับ Secret
  • ตรวจสอบ Log, Screenshot, ไฟล์สำรองข้อมูล และพื้นที่จัดเก็บข้อมูลร่วม
ตัวอย่าง Android ด้วย Kotlin

ตัวอย่างที่มีช่องโหว่

import android.content.Intent
import android.net.Uri
import androidx.appcompat.app.AppCompatActivity

class RedirectActivity : AppCompatActivity() {
    fun openRedirect(intent: Intent) {
        val rawTarget = intent.data?.getQueryParameter("redirect") ?: return
        startActivity(Intent(Intent.ACTION_VIEW, Uri.parse(rawTarget)))
    }
}

ตัวอย่างที่แก้ไขแล้ว

import android.content.Intent
import android.net.Uri
import androidx.browser.customtabs.CustomTabsIntent
import androidx.appcompat.app.AppCompatActivity

class RedirectActivity : AppCompatActivity() {
    private val allowedHosts = setOf("app.example.com")

    fun openRedirect(intent: Intent) {
        val rawTarget = intent.data?.getQueryParameter("redirect") ?: return
        val target = Uri.parse(rawTarget)
        if (target.scheme != "https" || target.host !in allowedHosts) return
        CustomTabsIntent.Builder().build().launchUrl(this, target)
    }
}
ตัวอย่าง iOS ด้วย Swift

ตัวอย่างที่มีช่องโหว่

import UIKit

final class RedirectViewController: UIViewController {
    func openRedirect(rawTarget: String) {
        guard let target = URL(string: rawTarget) else { return }
        UIApplication.shared.open(target)
    }
}

ตัวอย่างที่แก้ไขแล้ว

import SafariServices
import UIKit

final class RedirectViewController: UIViewController {
    private let allowedHosts: Set<String> = ["app.example.com"]

    func openRedirect(rawTarget: String) {
        guard let target = URL(string: rawTarget),
              target.scheme == "https",
              let host = target.host,
              allowedHosts.contains(host) else { return }

        let browser = SFSafariViewController(url: target)
        present(browser, animated: true)
    }
}

M10

Insufficient Cryptography

Insufficient Cryptography คือแอปเลือกหรือใช้อัลกอริทึม, Key, Random Number หรือ Library ผิดวิธี แม้จะมีคำว่า Encryption อยู่ในระบบก็ตาม เช่น Key เดาง่าย, ใช้โหมดเข้ารหัสไม่เหมาะสม หรือเก็บ Key แบบอ่านได้ ผู้โจมตีที่ได้ข้อมูลหรือ Key อาจถอดรหัสหรือปลอมข้อมูลได้

สรุปความเสี่ยงแบบย่อ
สิ่งที่อาจผิดพลาดการเลือกใช้อัลกอริทึมการเข้ารหัส โหมดการทำงาน ค่าสุ่ม กุญแจเข้ารหัส หรือกลไกการเข้ารหัสที่ไม่เหมาะสม ทำให้ไม่สามารถปกป้องข้อมูลในแอปมือถือได้อย่างปลอดภัย
ผลกระทบต่อธุรกิจข้อมูลที่ปกป้องด้วยอัลกอริทึมการเข้ารหัสที่อ่อนแอ หรือใช้กลไกเข้ารหัสที่ไม่ถูกต้อง อาจถูกถอดรหัส กู้คืน หรือแก้ไขดัดแปลงโดยผู้ไม่หวังดีได้
จุดควบคุมแรกที่ควรตรวจใช้ API การเข้ารหัสมาตรฐานของแพลตฟอร์มและผ่านการรับรอง
M10 Insufficient Cryptography: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, การหยุดการโจมตี
M10 Insufficient Cryptography

การเข้ารหัสที่ปลอดภัยต้องเลือกและใช้อัลกอริทึม กุญแจ และค่า Random อย่างถูกต้อง

  • จุดเริ่มโจมตี — ผู้โจมตีวิเคราะห์ข้อมูลที่ป้องกันด้วยอัลกอริทึมหรือ Random ที่อ่อนแอ
  • การควบคุมที่ล้มเหลว — อัลกอริทึม Mode Key หรือ Implementation ไม่ปกป้องข้อมูลตามที่ตั้งใจ
  • ผลกระทบ — ข้อมูลที่เข้ารหัสถูกกู้คืนหรือแก้ไขได้
  • การหยุดการโจมตี — ใช้ API เข้ารหัสของแพลตฟอร์มและไลบรารีที่ผ่านการตรวจสอบ

ภาพเปรียบเทียบเส้นทางที่ไม่ปลอดภัยกับจุดควบคุมที่ตัดเส้นทางนั้น กดภาพเพื่อดูขนาดเต็ม

ผลกระทบที่ควรพิจารณา

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

แนวทางลดความเสี่ยง

  • ใช้ API การเข้ารหัสมาตรฐานของแพลตฟอร์มและผ่านการรับรอง
  • สร้างและจัดเก็บกุญแจเข้ารหัสด้วยกลไกการปกป้องของแพลตฟอร์ม
  • หลีกเลี่ยงการเขียนอัลกอริทึมเข้ารหัสขึ้นเองและอัลกอริทึมที่ล้าสมัย
ตัวอย่าง Android ด้วย Kotlin

ตัวอย่างที่มีช่องโหว่

import android.content.Intent
import android.net.Uri
import androidx.appcompat.app.AppCompatActivity

class RedirectActivity : AppCompatActivity() {
    fun openRedirect(intent: Intent) {
        val rawTarget = intent.data?.getQueryParameter("redirect") ?: return
        startActivity(Intent(Intent.ACTION_VIEW, Uri.parse(rawTarget)))
    }
}

ตัวอย่างที่แก้ไขแล้ว

import android.content.Intent
import android.net.Uri
import androidx.browser.customtabs.CustomTabsIntent
import androidx.appcompat.app.AppCompatActivity

class RedirectActivity : AppCompatActivity() {
    private val allowedHosts = setOf("app.example.com")

    fun openRedirect(intent: Intent) {
        val rawTarget = intent.data?.getQueryParameter("redirect") ?: return
        val target = Uri.parse(rawTarget)
        if (target.scheme != "https" || target.host !in allowedHosts) return
        CustomTabsIntent.Builder().build().launchUrl(this, target)
    }
}
ตัวอย่าง iOS ด้วย Swift

ตัวอย่างที่มีช่องโหว่

import UIKit

final class RedirectViewController: UIViewController {
    func openRedirect(rawTarget: String) {
        guard let target = URL(string: rawTarget) else { return }
        UIApplication.shared.open(target)
    }
}

ตัวอย่างที่แก้ไขแล้ว

import SafariServices
import UIKit

final class RedirectViewController: UIViewController {
    private let allowedHosts: Set<String> = ["app.example.com"]

    func openRedirect(rawTarget: String) {
        guard let target = URL(string: rawTarget),
              target.scheme == "https",
              let host = target.host,
              allowedHosts.contains(host) else { return }

        let browser = SFSafariViewController(url: target)
        present(browser, animated: true)
    }
}

เกณฑ์ทวนสอบ OWASP MASVS v2.1.0 และแนวทางทดสอบ OWASP MASTG v2.0.0

OWASP MASVS v2.1 และ MASTG v2.0: STORAGE และ CRYPTO, AUTH และ NETWORK, PLATFORM และ CODE, RESILIENCE และ PRIVACY
OWASP MASVS v2.1 และ MASTG v2.0

จากความเสี่ยง Mobile Top 10 สู่ 24 Control ใน 8 หมวดของ MASVS

  • STORAGE และ CRYPTO
    • จัดเก็บข้อมูลอ่อนไหวอย่างปลอดภัย ใช้การเข้ารหัสที่แข็งแรง และจัดการ Key อย่างถูกต้อง
  • AUTH และ NETWORK
    • ยืนยันตัวตนอย่างปลอดภัย ยืนยันเพิ่มก่อนธุรกรรมสำคัญ ป้องกัน Traffic และทำ Identity Pinning
  • PLATFORM และ CODE
    • ใช้ IPC, WebView และ UI อย่างปลอดภัย บังคับอัปเดต ตรวจ Component และตรวจสอบอินพุต
  • RESILIENCE และ PRIVACY
    • ตรวจความสมบูรณ์ของแพลตฟอร์ม ต้านการดัดแปลงและการวิเคราะห์แอป ลดการเข้าถึงข้อมูล และให้ผู้ใช้ควบคุมข้อมูล

การทดสอบเจาะระบบแอปพลิเคชันมือถือ iOS และ Android ของ STH อ้างอิงความเสี่ยง OWASP Mobile Top 10 2024 ควบคู่กับ OWASP Mobile Application Security Verification Standard (MASVS) v2.1.0 และ OWASP Mobile Application Security Testing Guide (MASTG) v2.0.0 โดย MASVS กำหนด 24 Control ใน 8 หมวด

  • MASVS-STORAGE มี 2 Control ได้แก่ จัดเก็บข้อมูลอ่อนไหวอย่างปลอดภัย (MASVS-STORAGE-1) และป้องกันข้อมูลอ่อนไหวรั่วไหล (MASVS-STORAGE-2)
  • MASVS-CRYPTO มี 2 Control ได้แก่ ใช้การเข้ารหัสที่แข็งแรงและเป็นปัจจุบันตามแนวปฏิบัติของอุตสาหกรรม (MASVS-CRYPTO-1) และจัดการ Key ตามแนวปฏิบัติของอุตสาหกรรม (MASVS-CRYPTO-2)
  • MASVS-AUTH มี 3 Control ได้แก่ ใช้โปรโตคอลยืนยันตัวตนและการอนุญาตสิทธิ์ที่ปลอดภัย (MASVS-AUTH-1) ยืนยันตัวตนภายในเครื่องอย่างปลอดภัยตามแนวปฏิบัติของแพลตฟอร์ม (MASVS-AUTH-2) และยืนยันตัวตนเพิ่มเติมก่อนดำเนินการที่มีความอ่อนไหว (MASVS-AUTH-3)
  • MASVS-NETWORK มี 2 Control ได้แก่ ป้องกัน Network Traffic ทั้งหมดตามแนวปฏิบัติปัจจุบัน (MASVS-NETWORK-1) และทำ Identity Pinning กับ Remote Endpoint ทุกจุดที่นักพัฒนาควบคุม (MASVS-NETWORK-2)
  • MASVS-PLATFORM มี 3 Control ได้แก่ ใช้กลไก IPC อย่างปลอดภัย (MASVS-PLATFORM-1) ใช้ WebView อย่างปลอดภัย (MASVS-PLATFORM-2) และใช้ส่วนติดต่อผู้ใช้อย่างปลอดภัย (MASVS-PLATFORM-3)
  • MASVS-CODE มี 4 Control ได้แก่ กำหนดให้ใช้ระบบปฏิบัติการเวอร์ชันปัจจุบัน (MASVS-CODE-1) มีกลไกบังคับอัปเดตแอป (MASVS-CODE-2) ใช้เฉพาะ Component ที่ไม่มีช่องโหว่ที่ทราบแล้ว (MASVS-CODE-3) และตรวจสอบและกรองอินพุตที่ไม่น่าเชื่อถือทั้งหมด (MASVS-CODE-4)
  • MASVS-RESILIENCE มี 4 Control ได้แก่ ตรวจสอบความสมบูรณ์ของแพลตฟอร์ม (MASVS-RESILIENCE-1) มีกลไกป้องกันการดัดแปลง (MASVS-RESILIENCE-2) มีกลไกป้องกันการวิเคราะห์แบบ Static (MASVS-RESILIENCE-3) และมีเทคนิคป้องกันการวิเคราะห์แบบ Dynamic (MASVS-RESILIENCE-4)
  • MASVS-PRIVACY มี 4 Control ได้แก่ ลดการเข้าถึงข้อมูลและทรัพยากรที่อ่อนไหว (MASVS-PRIVACY-1) ป้องกันการระบุตัวตนผู้ใช้ (MASVS-PRIVACY-2) เปิดเผยการเก็บและใช้ข้อมูลอย่างโปร่งใส (MASVS-PRIVACY-3) และให้ผู้ใช้ควบคุมข้อมูลของตนเอง (MASVS-PRIVACY-4)

เครื่องมือประเมินความพร้อม

คลิกเลือกรายการที่องค์กรของท่านได้ดำเนินการแล้ว เพื่อคำนวณระดับความพร้อมเบื้องต้น

0%

เอกสารอ้างอิง OWASP

เปิดเอกสาร OWASP ฉบับทางการ

ขอใบเสนอราคา