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

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

אמצעי צמצום סיכונים

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

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 למטרה הזו.
  • מוודאים שהצפנות הנתמכות פועלות בהתאם לשיטות המומלצות לאבטחה.

משאבים