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

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

ภาพรวม

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

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

ผลกระทบ

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

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

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

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

การผ่อนปรนชั่วคราว

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

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

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

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

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

การลดปัญหา

ใช้ฟีเจอร์ NetworkSecurityConfig.xml เพื่อเลือกไม่รับการเข้าชมแบบข้อความธรรมดา (Cleartext) และบังคับใช้ 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 โดยไม่ใช้ระบบปฏิบัติการหรือไลบรารีของบุคคลที่สามที่ได้รับการดูแลรักษาเป็นอย่างดี จะเพิ่มโอกาสที่จะเกิดข้อผิดพลาดในการเขียนโค้ด ซึ่งอาจทำให้อัปเดตโปรโตคอลที่คุณติดตั้งใช้งานเมื่อจำเป็นได้ยากหรือเป็นไปไม่ได้ นอกจากนี้ การดำเนินการนี้ยังอาจทำให้เกิดช่องโหว่ด้านความปลอดภัยประเภทเดียวกับการใช้โปรโตคอลที่กำหนดเอง

การลดปัญหา

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

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

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

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

ใช้ SFTP

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

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

แหล่งข้อมูล