תקשורת טקסט ללא הצפנה

קטגוריית OWASP: MASVS-NETWORK: תקשורת רשת

סקירה כללית

אם מאפשרים תקשורת ברשת ללא הצפנה באפליקציה ל-Android, כל מי שמשגיח על תעבורת הנתונים ברשת יכול לראות את הנתונים המועברים ולבצע בהם שינויים. זו נקודת חולשה אם הנתונים שמועברים כוללים מידע רגיש כמו סיסמאות, מספרים של כרטיסי אשראי או פרטים אישיים אחרים.

גם אם אתם לא שולחים מידע רגיש, שימוש בטקסט ללא הצפנה עדיין עלול להוות נקודת חולשה, כי אפשר גם לשנות את התנועה בטקסט ללא הצפנה באמצעות התקפות רשת כמו ARP או הרעלת DNS, וכך לאפשר לתוקפים להשפיע על התנהגות האפליקציה.

השפעה

כשאפליקציה ל-Android שולחת או מקבלת נתונים כטקסט ללא הצפנה ברשת, כל מי שעוקב אחרי הרשת יכול ליירט ולקרוא את הנתונים האלה. אם הנתונים האלה כוללים מידע רגיש כמו סיסמאות, מספרי כרטיסי אשראי או הודעות אישיות, הם עלולים להוביל לגניבת זהות, לתרמיות פיננסיות ולבעיות חמורות אחרות.

לדוגמה, אפליקציה שמשדרת סיסמאות בטקסט ללא הצפנה עלולה לחשוף את פרטי הכניסה לגורם זדוני שמיירט את תעבורת הנתונים. לאחר מכן אפשר להשתמש בנתונים האלה כדי לקבל גישה לא מורשית לחשבונות של המשתמש.

סיכון: ערוצי תקשורת לא מוצפנים

שידור נתונים בערוצי תקשורת לא מוצפנים חושף את הנתונים שמשותפים בין המכשיר לנקודות הקצה (endpoints) של האפליקציה. תוקף יכול ליירט את הנתונים האלה ולשנות אותם.

פעולות מיטיגציה

יש לשלוח את הנתונים דרך ערוצי תקשורת מוצפנים. צריך להשתמש בפרוטוקולים מאובטחים כחלופה לפרוטוקולים שאין להם יכולות הצפנה.

סיכונים ספציפיים

בקטע הזה מוצגים סיכונים שמחייבים אסטרטגיות הפחתה לא סטנדרטיות או שהצמצמו אותם ברמת 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), כדי לוודא שחילופי הנתונים בין שני נקודות קצה מוצפנים, וכך למנוע ממשתמשים זדוניים לצותת לתקשורת ולשלוף מידע רגיש.

בדרך כלל, ארכיטקטורות שרתי לקוח מסתמכות על ממשקי API בבעלות המפתחים. אם האפליקציה שלכם תלויה בקבוצה של נקודות קצה ל-API, כדאי לפעול לפי השיטות המומלצות הבאות לאבטחה כדי להגן על תקשורות HTTPS:

  • אימות – המשתמשים צריכים לבצע אימות באמצעות מנגנונים מאובטחים כמו OAuth 2.0. בדרך כלל לא מומלץ להשתמש באימות בסיסי, כי הוא לא מספק מנגנונים לניהול סשנים, ואם פרטי הכניסה מאוחסנים בצורה לא נכונה, אפשר לפענח אותם מ-Base64.
  • הרשאה – יש להגביל את הגישה של המשתמשים רק למשאבים המיועדים, בהתאם לעקרון של הרשאות מינימליות. כדי ליישם את זה, צריך להשתמש בפתרונות קפדניים לבקרת גישה בנכסים של האפליקציה.
  • חשוב לוודא שנעשה שימוש בחבילות ההצפנה העדכניות ביותר, בהתאם לשיטות המומלצות בנושא אבטחה. לדוגמה, כדאי לתמוך בפרוטוקול TLSv1.3 עם תאימות לאחור, אם יש צורך, לתקשורת HTTPS.

סיכון: פרוטוקולים של תקשורת בהתאמה אישית

הטמעה של פרוטוקולי תקשורת בהתאמה אישית או ניסיון להטמיע פרוטוקולים ידועים באופן ידני עלולים להיות מסוכנים.

פרוטוקולים מותאמים אישית מאפשרים למפתחים להתאים פתרון ייחודי לצרכים שלהם, אבל כל שגיאה בתהליך הפיתוח עלולה לגרום לנקודות חולשה באבטחה. לדוגמה, שגיאות בפיתוח מנגנונים לטיפול בסשנים עלולות לאפשר לתוקפים לצותת לתקשורת ולשלוף מידע רגיש בזמן אמת.

מצד שני, הטמעה של פרוטוקולים ידועים כמו HTTPS בלי להשתמש במערכת הפעלה או בספריות של צד שלישי שמתוחזקות היטב, מגדילה את הסבירות להוספת שגיאות בקוד שעשויות להקשות, אם לא למנוע, את העדכון של הפרוטוקול שהטמעתם בעת הצורך. בנוסף, השימוש בפרוטוקולים מותאמים אישית עלול להוביל לאותו סוג של נקודות חולשה באבטחה.

פעולות מיטיגציה

שימוש בספריות מתוחזקות כדי להטמיע פרוטוקולי תקשורת ידועים

כדי להטמיע באפליקציה פרוטוקולים ידועים כמו HTTPS, צריך להשתמש בספריות של מערכת ההפעלה או בספריות של צד שלישי שמתוחזקות.

כך המפתחים יכולים לבחור בבטחה פתרונות שנבדקו לעומק, שופרו לאורך זמן ומקבלים עדכוני אבטחה באופן קבוע כדי לתקן נקודות חולשה נפוצות.

בנוסף, הבחירה בפרוטוקולים ידועים מאפשרת למפתחים ליהנות מתאימות רחבה למערכות, לפלטפורמות ולסביבות פיתוח משולבות (IDE) שונות, וכך להקטין את הסבירות לשגיאות אנושיות בתהליך הפיתוח.

שימוש ב-SFTP

הפרוטוקול הזה מצפין את הנתונים במעבר. כשמשתמשים בפרוטוקול כזה של החלפת קבצים, צריך להביא בחשבון את הפעולות הבאות:

  • SFTP תומך בסוגים שונים של אימות. במקום לבצע אימות באמצעות סיסמה, צריך להשתמש בשיטת האימות של המפתח הציבורי. צריך ליצור ולאחסן מפתחות כאלה באופן מאובטח. מומלץ להשתמש לצורך זה ב-Android Keystore.
  • חשוב לוודא שהצפנים הנתמכים פועלים לפי השיטות המומלצות לאבטחה.

משאבים