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

Locale: `th`

Source: `/th/compliance/owasp-top-10/mobile/`

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

สารบัญ

1. [ภาพรวม](/th/compliance/owasp-top-10/mobile/#topic-overview)
2. [M1 Improper Credential Usage](/th/compliance/owasp-top-10/mobile/#improper-client-access-use)
3. [M2 Inadequate Supply Chain Security](/th/compliance/owasp-top-10/mobile/#inadequate-supply-chain-security)
4. [M3 Insecure Authentication and Authorization](/th/compliance/owasp-top-10/mobile/#insecure-authentication-authorization)
5. [M4 Insufficient Input/Output Validation](/th/compliance/owasp-top-10/mobile/#insufficient-input-output-validation)
6. [M5 Insecure Communication](/th/compliance/owasp-top-10/mobile/#insecure-communication)
7. [M6 Inadequate Privacy Controls](/th/compliance/owasp-top-10/mobile/#inadequate-privacy-controls)
8. [M7 Insufficient Binary Protections](/th/compliance/owasp-top-10/mobile/#insufficient-binary-protections)
9. [M8 Security Misconfiguration](/th/compliance/owasp-top-10/mobile/#security-misconfiguration)
10. [M9 Insecure Data Storage](/th/compliance/owasp-top-10/mobile/#insecure-data-storage)
11. [M10 Insufficient Cryptography](/th/compliance/owasp-top-10/mobile/#insufficient-cryptography)
12. [OWASP MASVS v2.1 และ MASTG v2.0](/th/compliance/owasp-top-10/mobile/#owasp-masvs-verification)
13. [ประเมินความพร้อม](/th/compliance/owasp-top-10/mobile/#compliance-readiness-checklist)
14. [หัวข้อที่เกี่ยวข้อง](/th/compliance/owasp-top-10/mobile/#related-compliance-frameworks)

# 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: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, มาตรการลดความเสี่ยง](/assets/compliance/owasp-mobile-improper-client-access-use-th-v3.webp)](/assets/compliance/owasp-mobile-improper-client-access-use-th-v3.webp)

**M1 Improper Credential Usage**

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

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

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

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

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

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

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

**ตัวอย่าง Android ด้วย Kotlin**

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

```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)))
    }
}
```

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

```kotlin
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**

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

```swift
import UIKit

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

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

```swift
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: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, การหยุดการโจมตี](/assets/compliance/owasp-mobile-inadequate-supply-chain-security-th-v1.webp)](/assets/compliance/owasp-mobile-inadequate-supply-chain-security-th-v1.webp)

**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**

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

```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)))
    }
}
```

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

```kotlin
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**

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

```swift
import UIKit

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

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

```swift
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: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, การหยุดการโจมตี](/assets/compliance/owasp-mobile-insecure-authentication-authorization-th-v1.webp)](/assets/compliance/owasp-mobile-insecure-authentication-authorization-th-v1.webp)

**M3 Insecure Authentication and Authorization**

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

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

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

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

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

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

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

**ตัวอย่าง Android ด้วย Kotlin**

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

```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)))
    }
}
```

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

```kotlin
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**

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

```swift
import UIKit

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

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

```swift
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: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, การหยุดการโจมตี](/assets/compliance/owasp-mobile-insufficient-input-output-validation-th-v1.webp)](/assets/compliance/owasp-mobile-insufficient-input-output-validation-th-v1.webp)

**M4 Insufficient Input/Output Validation**

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

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

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

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

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

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

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

**ตัวอย่าง Android ด้วย Kotlin**

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

```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)))
    }
}
```

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

```kotlin
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**

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

```swift
import UIKit

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

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

```swift
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: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, การหยุดการโจมตี](/assets/compliance/owasp-mobile-insecure-communication-th-v1.webp)](/assets/compliance/owasp-mobile-insecure-communication-th-v1.webp)

**M5 Insecure Communication**

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

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

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

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

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

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

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

**ตัวอย่าง Android ด้วย Kotlin**

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

```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)))
    }
}
```

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

```kotlin
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**

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

```swift
import UIKit

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

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

```swift
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: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, การหยุดการโจมตี](/assets/compliance/owasp-mobile-inadequate-privacy-controls-th-v1.webp)](/assets/compliance/owasp-mobile-inadequate-privacy-controls-th-v1.webp)

**M6 Inadequate Privacy Controls**

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

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

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

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

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

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

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

**ตัวอย่าง Android ด้วย Kotlin**

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

```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)))
    }
}
```

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

```kotlin
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**

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

```swift
import UIKit

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

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

```swift
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: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, การหยุดการโจมตี](/assets/compliance/owasp-mobile-insufficient-binary-protections-th-v1.webp)](/assets/compliance/owasp-mobile-insufficient-binary-protections-th-v1.webp)

**M7 Insufficient Binary Protections**

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

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

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

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

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

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

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

**ตัวอย่าง Android ด้วย Kotlin**

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

```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)))
    }
}
```

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

```kotlin
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**

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

```swift
import UIKit

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

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

```swift
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: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, การหยุดการโจมตี](/assets/compliance/owasp-mobile-security-misconfiguration-th-v1.webp)](/assets/compliance/owasp-mobile-security-misconfiguration-th-v1.webp)

**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**

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

```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)))
    }
}
```

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

```kotlin
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**

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

```swift
import UIKit

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

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

```swift
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: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, การหยุดการโจมตี](/assets/compliance/owasp-mobile-insecure-data-storage-th-v1.webp)](/assets/compliance/owasp-mobile-insecure-data-storage-th-v1.webp)

**M9 Insecure Data Storage**

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

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

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

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

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

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

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

**ตัวอย่าง Android ด้วย Kotlin**

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

```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)))
    }
}
```

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

```kotlin
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**

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

```swift
import UIKit

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

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

```swift
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: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, การหยุดการโจมตี](/assets/compliance/owasp-mobile-insufficient-cryptography-th-v1.webp)](/assets/compliance/owasp-mobile-insufficient-cryptography-th-v1.webp)

**M10 Insufficient Cryptography**

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

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

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

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

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

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

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

**ตัวอย่าง Android ด้วย Kotlin**

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

```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)))
    }
}
```

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

```kotlin
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**

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

```swift
import UIKit

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

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

```swift
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](/assets/compliance/guide-owasp-mobile-masvs-verification-th-v2.webp)](/assets/compliance/guide-owasp-mobile-masvs-verification-th-v2.webp)

**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%

M1:2024 - ป้องกันการรั่วไหลของข้อมูลรับรอง (Credential) และไม่ฝัง API Key ระยะยาวในโค้ดแอปมือถือ (Improper Credential Usage)
          
          
            
            M2:2024 - ตรวจสอบที่มาและความถูกต้องของ SDK บุคคลที่สามและกระบวนการลงนามแอป (Inadequate Supply Chain Security)
          
          
            
            M3:2024 - ตรวจสิทธิ์คำขอบนระบบฝั่งเซิร์ฟเวอร์ (Backend) และใช้การจัดการเซสชันที่ปลอดภัย (Insecure Authentication/Authorization)
          
          
            
            M4:2024 - ตรวจสอบความถูกต้องของข้อมูลนำเข้าผ่าน Deep Link, Intent, QR Code และไฟล์นำเข้า (Insufficient Input/Output Validation)
          
          
            
            M5:2024 - บังคับใช้ TLS สำหรับการสื่อสารและตรวจสอบความถูกต้องของใบรับรองอิเล็กทรอนิกส์ (Insecure Communication)
          
          
            
            M6:2024 - จำกัดการขอสิทธิ์อุปกรณ์ (Permission) เท่าที่จำเป็นและคุ้มครองความเป็นส่วนตัวของผู้ใช้ (Inadequate Privacy Controls)
          
          
            
            M7:2024 - ใส่กลไกป้องกันการทำ Reverse Engineering, Tampering และตรวจจับ Rooted / Jailbroken Device (Insufficient Binary Protections)
          
          
            
            M8:2024 - ปิด Debug Mode, ทำ Hardening การตั้งค่าระบบ และปิดการเข้าถึง Exported Component ที่ไม่จำเป็น (Security Misconfiguration)
          
          
            
            M9:2024 - เข้ารหัสข้อมูลที่จัดเก็บในอุปกรณ์ (SharedPreferences, SQLite, Keychain/Keystore) ป้องกันข้อมูลรั่วไหล (Insecure Data Storage)
          
          
            
            M10:2024 - ใช้กลไกเข้ารหัสมาตรฐานของแพลตฟอร์มและจัดการกุญแจเข้ารหัสอย่างปลอดภัย (Insufficient Cryptography)

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

เลือกรายการด้านบนเพื่อประเมินผล

[ปรึกษาผู้เชี่ยวชาญ และขอใบเสนอราคา](/th/#contact)

## หัวข้อและกฎหมายกำกับดูแลที่เกี่ยวข้อง

- [
                สถาบันการเงินต้องทำ Pentest อะไรบ้างตามหลักเกณฑ์ ธปท.
                
              ](/th/compliance/bank-of-thailand/)
- [
                ธุรกิจภายใต้ ก.ล.ต. ต้องทำ Penetration Testing ไหม
                
              ](/th/compliance/sec/)
- [
                OWASP API Security Top 10:2023 สรุปช่องโหว่ API
                
              ](/th/compliance/owasp-top-10/api/)
- [
                PCI DSS v4.0.1: VA, ASV Scan, Pentest และ Segmentation
                
              ](/th/compliance/pci-dss/)

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

[เปิดเอกสาร OWASP ฉบับทางการ ](https://owasp.org/www-project-mobile-top-10/)

เปิดภาพขนาดเต็มเพื่อซูม

## ต้องการทำ Pentest ให้สอดคล้องกับข้อกำหนดเหล่านี้?

เล่าขอบเขตระบบและข้อกำหนดที่ต้องปฏิบัติตามให้เราฟัง ทีม STH จะช่วยประเมินแนวทางและจัดทำใบเสนอราคาให้

[ขอใบเสนอราคา Pentest](/th/#contact)

อัปเดตล่าสุด 16 ตุลาคม 2569