การสื่อสารแบบข้อความธรรมดา

หมวดหมู่ OWASP: MASVS-NETWORK: การสื่อสารผ่านเครือข่าย

ภาพรวม

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

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

ผลกระทบ

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

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

ความเสี่ยง: ช่องทางการสื่อสารที่ไม่ได้เข้ารหัส

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

การลดปัญหา

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

ความเสี่ยงที่เฉพาะเจาะจง

ส่วนนี้รวบรวมความเสี่ยงที่ต้องใช้กลยุทธ์การลดความเสี่ยงที่ไม่เป็นไปตามมาตรฐานหรือได้รับการลดความเสี่ยงที่ระดับ SDK บางระดับ และแสดงไว้ที่นี่เพื่อให้ข้อมูลครบถ้วน

ความเสี่ยง: HTTP

คำแนะนำในส่วนนี้ใช้ได้เฉพาะกับแอปที่กำหนดเป้าหมายเป็น Android 8.1 (API ระดับ 27) หรือเก่ากว่า ตั้งแต่ Android 9 (ระดับ API 28) เป็นต้นไป ไคลเอ็นต์ HTTP เช่น URLConnection, Cronet และ OkHttp จะบังคับให้ใช้ HTTPS ดังนั้นการรองรับข้อความธรรมดาจึงปิดใช้โดยค่าเริ่มต้น อย่างไรก็ตาม โปรดทราบว่าไลบรารีไคลเอ็นต์ HTTP อื่นๆ เช่น Ktor ไม่น่าจะบังคับใช้ข้อจำกัดเหล่านี้กับข้อความที่โอนหรือจัดเก็บได้โดยไม่ต้องเข้ารหัส และควรใช้อย่างระมัดระวัง

การลดปัญหา

ใช้ฟีเจอร์ NetworkSecurityConfig.xml เพื่อเลือกไม่ใช้การรับส่งข้อมูลแบบข้อความธรรมดา และบังคับใช้ HTTPS สำหรับแอป โดยมีข้อยกเว้นสำหรับโดเมนที่เฉพาะเจาะจงเท่านั้น ที่จำเป็น (โดยปกติเพื่อวัตถุประสงค์ในการแก้ไขข้อบกพร่อง) ดังนี้

Xml

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="false">
    <domain-config cleartextTrafficPermitted="true">
        <domain includeSubdomains="true">debug.domain.com</domain>
    </domain-config>
</network-security-config>

ตัวเลือกนี้ช่วยป้องกันการถดถอยของแอปโดยไม่ตั้งใจเนื่องจากการเปลี่ยนแปลง URL ที่ได้รับจากแหล่งภายนอก เช่น เซิร์ฟเวอร์แบ็กเอนด์

ความเสี่ยง: FTP

การใช้โปรโตคอล FTP เพื่อแลกเปลี่ยนไฟล์ระหว่างอุปกรณ์มีความเสี่ยงหลายประการ โดยความเสี่ยงที่สำคัญที่สุดคือการขาดการเข้ารหัสผ่านช่องทางการสื่อสาร ควรใช้ทางเลือกที่ปลอดภัยกว่า เช่น SFTP หรือ HTTPS แทน

การลดปัญหา

เมื่อใช้กลไกการแลกเปลี่ยนข้อมูลผ่านอินเทอร์เน็ตในแอปพลิเคชัน คุณควรใช้โปรโตคอลที่ปลอดภัย เช่น HTTPS Android มีชุด API ที่ช่วยให้นักพัฒนาแอปสร้างตรรกะไคลเอ็นต์-เซิร์ฟเวอร์ได้ คุณสามารถรักษาความปลอดภัยนี้ได้โดยใช้ Transport Layer Security (TLS) เพื่อให้มั่นใจว่าการแลกเปลี่ยนข้อมูลระหว่างอุปกรณ์ปลายทาง 2 เครื่องจะได้รับการเข้ารหัส ซึ่งจะช่วยป้องกันไม่ให้ผู้ใช้ที่เป็นอันตรายดักฟังการสื่อสารและดึงข้อมูลที่ละเอียดอ่อน

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

  • การตรวจสอบสิทธิ์ - ผู้ใช้ควรตรวจสอบสิทธิ์ของตนเองโดยใช้กลไกที่ปลอดภัย เช่น OAuth 2.0 โดยทั่วไปเราไม่แนะนำให้ใช้การตรวจสอบสิทธิ์พื้นฐาน เนื่องจากไม่มีกลไกการจัดการเซสชัน และหากจัดเก็บข้อมูลเข้าสู่ระบบอย่างไม่เหมาะสม ก็อาจถอดรหัสจาก Base64 ได้
  • การให้สิทธิ์ - ผู้ใช้ควรถูกจำกัดให้เข้าถึงเฉพาะทรัพยากรที่ต้องการ ตามหลักการให้สิทธิ์ขั้นต่ำที่สุด ซึ่งทำได้โดยการใช้ โซลูชันการควบคุมการเข้าถึงอย่างรอบคอบสำหรับชิ้นงานของแอปพลิเคชัน
  • ตรวจสอบว่าใช้ชุดการเข้ารหัสที่พิจารณาอย่างรอบคอบและล่าสุดตาม แนวทางปฏิบัติแนะนำด้านความปลอดภัย ตัวอย่างเช่น ให้พิจารณารองรับโปรโตคอล TLSv1.3 ที่มีความเข้ากันได้แบบย้อนหลัง หากจำเป็นสำหรับการสื่อสารผ่าน HTTPS

ความเสี่ยง: โปรโตคอลการสื่อสารที่กำหนดเอง

การใช้โปรโตคอลการสื่อสารที่กำหนดเองหรือการพยายามใช้โปรโตคอลที่รู้จักกันดีด้วยตนเองอาจเป็นอันตรายได้

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

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

การลดปัญหา

ใช้ไลบรารีที่ได้รับการดูแลเพื่อใช้โปรโตคอลการสื่อสารที่รู้จักกันดี

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

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

นอกจากนี้ การเลือกใช้โปรโตคอลที่รู้จักกันดีจะช่วยให้นักพัฒนาซอฟต์แวร์ได้รับประโยชน์จากความเข้ากันได้ในวงกว้าง ในระบบ แพลตฟอร์ม และ IDE ต่างๆ ซึ่งจะช่วยลด โอกาสเกิดข้อผิดพลาดจากผู้ปฏิบัติงานในกระบวนการพัฒนา

ใช้ SFTP

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

  • SFTP รองรับการตรวจสอบสิทธิ์หลายประเภท ควรใช้วิธีการตรวจสอบสิทธิ์คีย์สาธารณะแทนการตรวจสอบสิทธิ์ที่อิงตามรหัสผ่าน คีย์ดังกล่าว ควรสร้างและจัดเก็บอย่างปลอดภัย เราขอแนะนำให้ใช้ Android Keystore สำหรับ วัตถุประสงค์นี้
  • ตรวจสอบว่าการเข้ารหัสที่รองรับเป็นไปตามแนวทางปฏิบัติแนะนำด้านความปลอดภัย

แหล่งข้อมูล