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

קטגוריה ב-OWASP: MASVS-NETWORK: Network Communication

סקירה כללית

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

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

השפעה

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

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

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

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

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

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

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

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

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

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

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

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

שימוש ב-SFTP

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

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

משאבים