קטגוריית OWASP: MASVS-PLATFORM: Platform Interaction
סקירה כללית
אפליקציות רבות לנייד משתמשות ב-API חיצוני כדי לספק תכונות. בדרך כלל, נעשה שימוש באסימון או במפתח סטטיים כדי לאמת את האפליקציה שמתחברת לשירות.
עם זאת, בהקשר של הגדרת שרת לקוח (או אפליקציה לנייד ו-API) – שימוש במפתח סטטי בדרך כלל לא נחשב לשיטת אימות מאובטחת לגישה לנתונים או לשירותים רגישים. בניגוד לתשתית פנימית, כל אחד יכול לגשת ל-API חיצוני ולנצל לרעה את השירות אם יש לו גישה למפתח הזה.
לדוגמה, יכול להיות שמפתח סטטי יעבור הנדסה הפוכה מהאפליקציה או ייורט כשאפליקציה לנייד מתקשרת עם ה-API החיצוני. בנוסף, יש סיכוי גבוה יותר שהמפתח הסטטי הזה יוצפן בהארדקוד באפליקציה.
הסיכון לנתונים ולשירותים של ה-API מתרחש כשלא משתמשים באימות ובאמצעי בקרה מספיק מאובטחים לגישה.
כשמשתמשים במפתח סטטי, אפשר לנצל את ה-API על ידי הפעלה חוזרת של בקשות או על ידי יצירת בקשות חדשות באמצעות המפתח (שנחטף או שבוצע לו הנדסה הפוכה) ללא הגבלות זמן.
השפעה
אם מפתח משלם על שירות API של AI או ML, יהיה יחסית קל לתוקף לגנוב את המפתח הזה ולצבור חוב בשירות שלו או להשתמש בו כדי ליצור תוכן מזויף.
כל נתוני המשתמשים, הקבצים או הפרטים האישיים המזהים (PII) שמאוחסנים ב-API יהיו זמינים באופן חופשי, מה שיוביל לדליפות מזיקות.
תוקף יכול גם להשתמש בגישה הזו כדי לבצע הונאה, להפנות שירותים מחדש, ובמקרים נדירים, לקבל שליטה מלאה בשרתים.
אמצעי צמצום סיכונים
Stateful API
אם האפליקציה מספקת למשתמשים אפשרות להתחבר או יכולה לעקוב אחרי סשנים של משתמשים, מומלץ למפתחים להשתמש בשירות API כמו Google Cloud לשילוב עם האפליקציה שלהם תוך שמירה על מצב.
בנוסף, מומלץ להשתמש באימות מאובטח, באימות לקוח ובאמצעי בקרה על סשנים שמוצעים על ידי שירות ה-API, ולשקול שימוש באסימון דינמי כחלופה למפתח סטטי. חשוב לוודא שתוקף האסימון יפוג תוך זמן קצר יחסית (שעה היא פרק זמן אופייני).
לאחר מכן, צריך להשתמש באסימון הדינמי לאימות כדי לספק גישה ל-API. ההנחיות האלה מראות איך אפשר לעשות את זה באמצעות OAuth 2.0. בנוסף להנחיות האלה, אפשר לחזק עוד יותר את OAuth 2.0 כדי לצמצם את נקודות החולשה באפליקציית Android שלכם באמצעות הטמעה של התכונות הבאות.
הטמעת טיפול נכון בשגיאות ורישום ביומן:
- צריך לטפל בשגיאות OAuth בצורה חלקה וברורה, ולתעד אותן למטרות ניפוי באגים.
- צמצום השטח החשוף להתקפה יעזור לכם גם לזהות ולפתור בעיות שעלולות להתעורר.
- מוודאים שכל ההודעות שנרשמות ביומן או מוצגות למשתמש ברורות, אבל לא מכילות מידע שיכול להיות שימושי ליריב.
הגדרת OAuth באפליקציה באופן מאובטח:
- שולחים את הפרמטר
redirect_uriלנקודות הקצה של ההרשאה ושל הטוקן. - אם האפליקציה שלכם משתמשת ב-OAuth עם שירות של צד שלישי, צריך להגדיר שיתוף משאבים בין מקורות (CORS) כדי להגביל את הגישה למשאבים של האפליקציה.
- כך אפשר למנוע מתקפות לא מורשות של סקריפטים חוצי אתרים (XSS).
- כדי למנוע תקיפות CSRF, צריך להשתמש בפרמטר state.
שימוש בספריית אבטחה:
- מומלץ להשתמש בספריית אבטחה כמו AppAuth כדי לפשט את ההטמעה של תהליכי OAuth מאובטחים.
- ספריות Android האלה יכולות לעזור להפוך לאוטומטיות רבות מהשיטות המומלצות לאבטחה שצוינו קודם.
שיטות אימות אחרות, כולל אסימוני Firebase ואסימוני Google ID, מתוארות במסמכי ה-OpenAPI.
Stateless API
אם שירות ה-API לא מציע אף אחת מההגנות שמומלצות למעלה, ויש דרישה להפעלת סשנים ללא שמירת מצב (stateless) ללא התחברות של משתמש, יכול להיות שהמפתחים יצטרכו לספק פתרונות משלהם לתוכנת ביניים.
התהליך הזה כולל 'העברת' בקשות בין האפליקציה לנקודת הקצה של ה-API. אחת הדרכים לעשות זאת היא להשתמש באסימוני JWT (JSON Web Tokens) ובחתימת JWS (JSON Web Signature), או לספק שירות מאומת באופן מלא כמומלץ קודם. כך אפשר לאחסן את המפתח הסטטי הפגיע בצד השרת ולא באפליקציה (הלקוח).
יש בעיות מובנות באספקת פתרון חסר מצב מקצה לקצה באפליקציות לנייד. חלק מהאתגרים הקריטיים ביותר הם אימות הלקוח (האפליקציה) ואחסון מאובטח של המפתח הפרטי או הסוד במכשיר.
Play Integrity API מספק אימות של התקינות של האפליקציה והבקשות. הפעולה הזו יכולה לצמצם את הסיכון לניצול לרעה של הגישה הזו בתרחישים מסוימים. בנוגע לניהול מפתחות, במקרים רבים מאגר המפתחות הוא המקום הטוב ביותר לאחסון מאובטח של מפתחות פרטיים.
חלק מהאפליקציות לנייד משתמשות בשלב הרשמה כדי לבדוק את התקינות של האפליקציה ולספק מפתח באמצעות חילופי נתונים מאובטחים. השיטות האלה מורכבות ולא נכללות במסמך הזה. עם זאת, שירות לניהול מפתחות בענן הוא פתרון אפשרי.