ความปลอดภัยของแอปในยุคแห่งการทำงานเป็นตัวแทน

สวัสดี ฉันชื่อ Kristen

สวัสดี ฉันชื่อ Sabs

และเราจะมาพูดคุยกับคุณในวันนี้เกี่ยวกับความปลอดภัยในยุคของ Agent

ในปีที่ผ่านมา เราได้มอบรางวัลมูลค่ากว่า 2 ล้านดอลลาร์สำหรับโปรแกรม Android Bug Hunters และกว่า 2 แสนดอลลาร์สำหรับอุปกรณ์เคลื่อนที่

ในยุคของ Agentic ในปัจจุบัน ความปลอดภัยของแอปมีการพัฒนาอย่างต่อเนื่อง

เรามาพูดถึงเครื่องมือที่จะช่วยแก้ปัญหาเหล่านี้ได้อย่างรวดเร็วและมีประสิทธิภาพกัน

หากต้องการปรับปรุงประสิทธิภาพของ Agent สำหรับความปลอดภัยของ Android คำตอบไม่ใช่พรอมต์ที่ดีกว่า

ซึ่งเป็นเครื่องมือและเวิร์กโฟลว์ที่จะช่วยให้ Agent เข้าใจ Toolchain และ API ของเราเพื่อช่วยรักษาแอปของคุณให้ปลอดภัย

ตอนนี้เป็นเวลา 16:30 น.

ในวันพฤหัสบดี

คุณกำลังตัดรุ่น และ CI เปลี่ยนเป็นสีแดง โดยมีข้อผิดพลาดเพียงข้อเดียวคือ Broadcast Receiver ที่ลงทะเบียนโดยไม่มี Flag การส่งออก

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

เราเป็นวิศวกรผลิตภัณฑ์ที่เปิดตัวฟีเจอร์คุณภาพสูงอย่างรวดเร็ว และเราไม่จำเป็นต้องเป็นนักวิจัยด้านความปลอดภัย

แล้วสัญชาตญาณตามธรรมชาติคืออะไร

เราจึงส่งคำเตือนนั้นไปยังเครื่องมือ Agentic และขอให้ Agent แก้ไข

แต่เครื่องมือ Agentic ที่ทำงานโดยไม่มีบริบทของโปรเจ็กต์จะมีจุดบอด 3 จุด

เนื่องจากอาจไม่ทราบว่าแอปของคุณสร้างขึ้นจากโมดูลฟีเจอร์แบบไดนามิกหรือแพ็กเกจ Multi-APK

โดยจะเห็นเป็นไฟล์ ไม่ใช่อาร์ติแฟกต์ที่จัดส่ง

เครื่องมืออาจไม่ทราบหรือไม่สามารถติดตามขั้นตอนของข้อมูลจาก Kotlin UI ไปยังตรรกะที่แชร์ของ KMP ไปยังการเรียก JNI ของ C++ แบบเนทีฟ

โดยจะเห็นเพียงเลเยอร์เดียว

สุดท้ายแต่ไม่ท้ายสุด เครื่องมือนี้อาจไม่ทราบเกี่ยวกับ SDK ขั้นต่ำหรือเวอร์ชันบิลด์ Gradle ของคุณ

เราจึงชี้ให้เอเจนต์เห็นแอปและขอให้ตรวจสอบความปลอดภัย

พบผลลัพธ์ 6 รายการ

และนี่คือสิ่งที่คุณต้องรู้

ทุกๆ คนที่พูดแบบนั้นไม่ได้พูดผิด

ซึ่งก็เป็นไปได้ แต่มีเพียงข้อเดียวเท่านั้นที่เป็นข้อบกพร่องที่เราเริ่มพูดถึงในตอนแรก

ส่วนที่เหลือเป็นแนวทางปฏิบัติที่ดี สิ่งที่ต้องตรวจสอบเพิ่มเติม การคาดเดา และสิ่งที่ไม่เกี่ยวข้อง

ดังนั้น ตอนนี้คุณจึงปรับขนาดเป็นฐานของโค้ดจริง โดยมีคำเตือนเพิ่มเติม และในทุก Pull Request คุณจะถูกล่อลวงให้เข้าถึง Lint ที่ระงับ

คุณจะต้องทำการเปลี่ยนแปลงเพื่อผสานการเปลี่ยนแปลงนั้น หรืออาจพลาดช่องโหว่ไปเลยก็ได้

และนั่นคือวิธีที่ช่องโหว่ที่แท้จริงหลุดรอดไปได้

เครื่องมือนี้ไม่ได้ประมาท แต่ระมัดระวัง ทว่าความระมัดระวังไม่เหมือนกับความมีประโยชน์

มาดูตัวอย่างที่เป็นรูปธรรมกัน

สมมติว่าคุณขอให้ Agent "ตรวจสอบคอมโพเนนต์ที่ส่งออกทั้งหมดในแอปนี้เพื่อหาการเปลี่ยนเส้นทาง Intent ของแอป"

นั่นเป็นงานด้านความปลอดภัยที่แท้จริง และในแอปแบบหลายโมดูล งานนี้ถือเป็นงานใหญ่

คำขอประเภทนี้จะแสดงค่าใช้จ่ายจริง

และหากไม่มีคำแนะนำเฉพาะสำหรับ Android ตัวแทนก็ไม่มีกลยุทธ์สำหรับคำถามนั้น

ดังนั้นจึงเป็นการโจมตีแบบ Brute Force

โดยอาจอ่านโมดูลที่ไม่ได้ส่งออกอะไรเลย

โดยอาจดึงข้อมูลอีกครั้งจากหลักการแรกที่ทำให้การเปลี่ยนเส้นทาง Intent ถูกใช้ประโยชน์ได้

โดยอาจไปตามเส้นทางที่ไม่เคยเข้าถึงได้

คุณกำลังจ่ายเงินเพื่อการสำรวจ ไม่ใช่การวิเคราะห์

ทักษะคือสิ่งที่ช่วยเติมเต็มกลยุทธ์ที่ขาดหายไป

ตัวอย่างเช่น ทักษะด้านความปลอดภัยของ Android จะให้คำแนะนำแก่ Agent ตามคำแนะนำปัจจุบัน ซึ่งเป็นลำดับขั้นตอนเดียวกับที่นักวิจัยด้านความปลอดภัยจะปฏิบัติตามจริงๆ และ Agent จะหยุดคาดเดา

ระบบจะไม่ค้นหากฎอีกครั้งเนื่องจากกฎมาจากทักษะ

ปัจจุบันเราได้เปิดตัวทักษะด้านความปลอดภัย 2 รายการ ได้แก่ Intent Security และ Permissions

ความปลอดภัยของ Intent เกี่ยวข้องกับสิ่งที่แอปอื่นๆ สามารถทำให้แอปของคุณทำได้

แอปของคุณมีสิทธิ์ แต่เซสชันการลงชื่อเข้าใช้ไม่มี

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

ทักษะนี้จะช่วยป้องกันไม่ให้เกิดเหตุการณ์ดังกล่าว

ทักษะด้านสิทธิ์ช่วยลดช่องว่างระหว่างสิทธิ์ที่ประกาศไว้กับสิทธิ์ที่มีการบังคับใช้จริง

ซึ่งจะช่วยให้คุณเขียนการตรวจสอบสิทธิ์ที่เหมาะสมได้

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

รวมถึงตรวจจับการขอสิทธิ์มากเกินไป

เช่น การขอสิทธิ์เข้าถึงแบบกว้างในกรณีที่เครื่องมือเลือกรูปภาพก็เพียงพอแล้ว

ใช้เครื่องมือนี้กับ Android CLI แล้วถามว่า "ตรวจสอบความปลอดภัยของ Intent"

ไม่มีการกำหนดค่า

ไม่มีการปรับแต่งกฎ

ดังนั้นเอาต์พุตจึงไม่ใช่คำเตือนจำนวนมาก

เป็นรีวิว

นี่คือข้อบกพร่อง นี่คือสาเหตุที่ข้อบกพร่องนี้สำคัญต่อแอปของคุณ และนี่คือวิธีแก้ไข

เคล็ดลับมือโปรมีดังนี้

ใช้ Android CLI เพื่อให้ค้นหาและติดตั้งได้ง่าย

android skills list
android skills add android-intent-security
android skills add android-permissions-security

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

โดยจะคำนึงถึง SDK ขั้นต่ำของคุณเพื่อให้การแก้ไขคอมไพล์ เส้นทางไฟล์จริง และหมายเลขบรรทัดจริง

นี่คือรีวิวที่คุณได้รับกลับมา

โดยจะชี้ไปยังไฟล์และบรรทัดที่แน่นอน อธิบายภัยคุกคามที่แท้จริงและคำอธิบายสำหรับการเปลี่ยนแปลง ไม่ใช่แค่ Lint บอกว่าอย่างนั้น

โดยจะอ้างอิงทักษะที่ใช้

โดยจะอ่านการกำหนดค่าบิลด์ เห็น SDK ขั้นต่ำ 26 และเลือก ContextCompat เพื่อให้การแก้ไขทำงานได้ และจะแสดงความแตกต่างเพื่อให้คุณนำไปใช้ได้

นั่นคือคำเตือนที่เราเปิดขึ้นมา แต่ตอนนี้มีวิธีแก้ไขที่แนะนำและเหตุผลเพิ่มเติม

ดังนั้น ทักษะก่อนหน้านี้จะตรวจจับข้อบกพร่องด้านความปลอดภัย

ตอนนี้เรามาพูดถึงอีกเรื่องหนึ่งกัน นั่นคือการปฏิบัติตามนโยบายแอป

ตัวอย่างเช่น สมมติว่าคุณเป็นนักพัฒนาแอปรายใหม่ที่ต้องการเปิดตัวแอปใน Play Store

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

ทักษะนโยบาย Play จะทำการวิเคราะห์แบบคงที่ในฐานของโค้ด

หากคุณเผยแพร่แอป Play Store ที่มีอยู่ ระบบจะตรวจสอบเพื่อเปรียบเทียบการวิเคราะห์โค้ดแบบคงที่นั้นกับการประกาศของ Play Store ด้วย

การใช้ทักษะนี้จะช่วยให้คุณตรวจพบปัญหาที่อาจเกิดขึ้นเกี่ยวกับนโยบายของ Google Play ก่อนส่งแอปเข้ารับการตรวจสอบ ไม่ใช่หลังจากนั้น และช่วยเร่งกระบวนการส่งแอปให้เร็วขึ้น

เวิร์กโฟลว์จะคล้ายกับทักษะอื่นๆ ที่เราได้พูดถึงไปแล้ว นั่นคือ นำเข้าแอป แล้วถามว่า "ตรวจสอบแอปนี้เพื่อดูว่าสอดคล้องกับนโยบายของ Google Play หรือไม่ก่อนที่ฉันจะส่ง"

คุณจะเห็นภาพหน้าจอของรายงานตัวอย่างทางด้านขวา และคำสั่ง Android CLI เพื่อติดตั้งที่ด้านล่าง

android skills list
android skills add play-policy-insights

ดังนั้น ทุกสิ่งที่เราพูดถึงจนถึงตอนนี้จะเกิดขึ้นก่อนที่คุณจะจัดส่ง ได้แก่ การตรวจสอบ Intent, การตรวจสอบสิทธิ์, การตรวจสอบความสอดคล้อง

ซึ่งเป็นการรักษาความปลอดภัยในเวลาบิลด์และเป็นสิ่งสำคัญ

แต่ยังมีภัยคุกคามอีกประเภทหนึ่งที่จะเกิดขึ้นเมื่อ APK ของคุณเผยแพร่ออกไปและทำงานบนอุปกรณ์ที่คุณอาจควบคุมไม่ได้

Play Integrity API จะตอบคำถาม 3 ข้อในรันไทม์ที่โค้ดของคุณเองตอบเกี่ยวกับตัวโค้ดเองไม่ได้ นั่นคือ บิลด์นี้เป็นบิลด์ของแท้ที่ไม่มีการแก้ไขของแอปคุณใช่ไหม

แอปนี้ทำงานในอุปกรณ์ Android ของแท้หรือไม่

และบัญชีนี้เป็นบัญชีผู้ใช้ Play ใช่ไหม

ดังนั้น คุณจึงใช้ Play Integrity API เพื่อแสดงผลการตัดสินเกี่ยวกับความสมบูรณ์ของแอป ความสมบูรณ์ของอุปกรณ์ และอื่นๆ ได้

นอกจากจะช่วยให้คุณเผยแพร่แอปได้อย่างปลอดภัย รวดเร็ว และง่ายดายยิ่งขึ้นแล้ว เรายังช่วยให้คุณปกป้องรายได้และชื่อเสียงของแอปได้ง่ายขึ้นด้วย

ดังนั้น คุณจึงควรปกป้องธุรกิจจากการประพฤติมิชอบและการละเมิด

แดชบอร์ด "ได้รับการปกป้องด้วย Google Play" ใหม่ที่คุณเห็นอยู่นี้จะช่วยให้คุณตรวจสอบและกำหนดค่าการป้องกันความสมบูรณ์ การจัดจำหน่าย และการสร้างรายได้ได้ในที่เดียว

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

เราเพิ่งพูดถึงฟีเจอร์และเครื่องมือของ Android ที่ช่วยรักษาแอปให้ปลอดภัย แต่ผู้ใช้ของคุณล่ะ

ก่อนอื่นมาดูการปกป้อง OTP ทาง SMS กัน

สมมติว่าคุณต้องการใช้การยืนยันผู้ใช้ทาง SMS สำหรับแอปและส่งรหัสยืนยัน

สิทธิ์เข้าถึง SMS ช่วยให้แอปเข้าถึงข้อมูลการรับส่งข้อความ รวมถึงข้อมูลที่ละเอียดอ่อน เช่น OTP

เราจึงได้เปิดตัว API บางรายการในแอปเพื่อให้คุณนำไปใช้ได้ โดยที่คุณไม่จำเป็นต้องขอสิทธิ์ SMS แบบกว้าง แต่ยังคงรับรหัส OTP ทาง SMS เพื่อยืนยันได้

SMS Retriever API ช่วยให้แอปของคุณยืนยัน OTP โดยอัตโนมัติได้โดยไม่ต้องขอสิทธิ์ SMS ในวงกว้าง

คุณเพิ่มแฮช 11 อักขระที่ระบุแอปของคุณลงในข้อความ แล้วระบบจะส่งข้อความนั้นให้คุณเพียงข้อความเดียว

และหากควบคุมรูปแบบข้อความไม่ได้ ให้ใช้ SMS User Consent API

ระบบจะแสดงข้อความแจ้งเพียงครั้งเดียว

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

แต่ก็ยังไม่จำเป็นต้องมีสิทธิ์เข้าถึง SMS แบบกว้าง

บางแอปอาจต้องใช้ตำแหน่งที่แน่นอนเพียงครั้งเดียวเพื่อทำงานให้เสร็จสมบูรณ์

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

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

ซึ่งเป็นองค์ประกอบ UI ของ Android ที่นักพัฒนาแอปสามารถปรับแต่งและฝังได้

เราได้เปิดตัวไลบรารี Jetpack ของปุ่มตำแหน่งเวอร์ชันอัลฟ่าเวอร์ชันแรกไปเมื่อเดือนมิถุนายน

คุณสามารถดูสิทธิ์ที่จำเป็นในการเปิดใช้ปุ่มตำแหน่งในไฟล์ Manifest ของ Android ได้ที่นี่

<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"
    android:usesPermissionFlags="onlyForLocationButton"/>

<uses-permission android:name="android.permission.USE_LOCATION_BUTTON" />

    <application
        android:icon="@mipmap/ic_launcher"
        android:label="LocationButtonSample"
        android:theme="@style/Theme.PinPoint">
        <activity
            android:name=".MainActivity"
            android:exported="true">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>

คุณต้องประกาศสิทธิ์เข้าถึงตำแหน่งมาตรฐานโดยเพิ่มแฟล็กสิทธิ์ onlyForLocationButton พร้อมกับสิทธิ์ USE_LOCATION_BUTTON เฉพาะที่บริการแสดงผลระยะไกลของระบบกำหนด

ทางด้านขวาคือโค้ด Jetpack ที่จะใช้

...
import androidx.core.locationbutton.compose.LocationButton

@Composable
fun LocationPermissionScreen(onPermissionGranted: () -> Unit, onPermissionDenied: () -> Unit) {
    // Renders the secure system-trusted Location Button composable
    LocationButton(
        // Callback triggered when the user taps the secure button and makes a decision on the permission dialog
        onPermissionResult = { isGranted ->
            if (isGranted) {
                onPermissionGranted()
            } else {
                onPermissionDenied()
            }
        },
...

คุณจะเห็นว่าเรากำลังสร้างปุ่มตำแหน่งและเริ่มต้นการเรียกกลับ

ระบบจะทริกเกอร์ Callback นี้เมื่อผู้ใช้แตะปุ่มตำแหน่งเพื่อตัดสินใจว่าจะให้หรือปฏิเสธสิทธิ์

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

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

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

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

เราจะแสดงวิธีผสานรวมเข้ากับแอปของคุณที่นี่

คุณต้องขอสิทธิ์ ค้นหาโหมดการปกป้องขั้นสูง และตรวจสอบว่าผู้ใช้เปิดโหมดการปกป้องขั้นสูงไว้หรือไม่โดยใช้การเรียกใช้บริการระบบ Advanced Protection Mode Manager ในอุปกรณ์

class AdvancedProtectionManager() {
  // Check the current status
  fun isAdvancedProtectionEnabled(): Boolean

  // Be alerted when status changes
  fun registerAdvancedProtectionCallback(executor: Executor,
                                         callback: Callback)

  fun unregisterAdvancedProtectionCallback(callback: Callback)
}

interface Callback() {
  // Called when advanced protection state changes
  fun onAdvancedProtectionChanged(enabled: Boolean)
}

จากนั้นคุณจะฟังการเปลี่ยนแปลงรันไทม์ได้โดยการลงทะเบียน Callback

วันนี้เราได้พูดถึงหัวข้อต่างๆ มากมาย

ลิงก์ด่วนต่อไปนี้จะช่วยให้คุณดูข้อมูลเพิ่มเติมเกี่ยวกับเรื่องดังกล่าวได้

เราจะหยุดตรงนี้สักครู่เพื่อให้คุณจด URL ที่ต้องการ

ขอขอบคุณ

ขอขอบคุณ