קטגוריה של OWASP: MASVS-PLATFORM: Platform Interaction
סקירה כללית
Tapjacking הוא המקבילה באפליקציות ל-Android לפגיעות באינטרנט מסוג clickjacking: אפליקציה זדונית מטעה את המשתמש ללחוץ על אמצעי בקרה שקשור לאבטחה (כפתור אישור וכו') על ידי הסתרת ממשק המשתמש באמצעות שכבת-על או באמצעים אחרים. בדף הזה אנחנו מבחינים בין שני סוגים של התקפות: הסתרה מלאה והסתרה חלקית. בהסתרה מלאה, התוקף מכסה את אזור המגע, ואילו בהסתרה חלקית, אזור המגע נשאר גלוי.
השפעה
התקפות מסוג Tapjacking משמשות להטעיית משתמשים כדי שיבצעו פעולות מסוימות. ההשפעה תלויה בפעולה שהתוקף מנסה לבצע.
סיכון: חסימה מלאה
במקרה של הסתרה מלאה, התוקף מציב שכבת-על מעל אזור המגע כדי לחטוף את אירוע המגע:
אמצעי צמצום סיכונים
כדי למנוע הסתרה מלאה, צריך להגדיר את View.setFilterTouchesWhenObscured(true)
בקוד. ההגדרה הזו חוסמת נגיעות שמועברות על ידי שכבת-על. אם אתם מעדיפים גישה הצהרתית, אתם יכולים גם להוסיף android:filterTouchesWhenObscured="true"
לקובץ הפריסה של אובייקט View
שאתם רוצים להגן עליו.
סיכון: חסימה חלקית
במתקפות של הסתרה חלקית, אזור המגע נשאר גלוי:
אמצעי צמצום סיכונים
כדי לצמצם את ההסתרה החלקית, אפשר להתעלם באופן ידני מאירועי מגע שמוגדרים עם הדגל FLAG_WINDOW_IS_PARTIALLY_OBSCURED
. אין אמצעי הגנה שמוגדרים כברירת מחדל מפני התרחיש הזה.
Android 16 ו-accessibilityDataSensitive
: החל מ-Android 16 (רמת API 16) ומעלה, מפתחים יכולים להשתמש בדגל accessibilityDataSensitive
כדי להגן על נתונים רגישים מפני שירותי נגישות זדוניים שאינם כלים לנגישות לגיטימיים. כשמגדירים את הדגל הזה בתצוגות רגישות (למשל, מסכי כניסה, מסכי אישור של עסקאות), הוא מגביל את האפליקציות עם הרשאת נגישות מקריאה או מאינטראקציה עם הנתונים הרגישים, אלא אם הן מוצהרות כ-isA11yTool=true
במניפסט שלהן. ההגנה הזו חזקה יותר ומספקת הגנה ברמת המערכת מפני האזנות ומתקפות של החדרת קליקים, שמאפיינות תרחישים של הסתרה חלקית.
מפתחים יכולים לעיתים קרובות להפעיל את accessibilityDataSensitive
באופן מרומז על ידי ציון android:filterTouchesWhenObscured="true"
בקובצי הפריסה שלהם.
סיכונים ספציפיים
בקטע הזה מפורטים סיכונים שנדרשות לגביהם אסטרטגיות צמצום לא סטנדרטיות, או סיכונים שצומצמו ברמה מסוימת של ה-SDK ומופיעים כאן לצורך השלמת התמונה.
סיכון: android.Manifest.permission.SYSTEM_ALERT_WINDOW
ההרשאה SYSTEM_ALERT_WINDOW
מאפשרת לאפליקציה ליצור חלון שמוצג מעל כל האפליקציות.
אמצעי צמצום סיכונים
בגרסאות חדשות יותר של Android הוטמעו כמה אמצעי הגנה, כולל:
- ב-Android מגרסה 6 (API ברמה 23) ואילך, המשתמשים צריכים להעניק הרשאה באופן מפורש כדי שהאפליקציה תוכל ליצור חלון שכבת-על.
- ב-Android 12 (רמת API 31) ומעלה, אפליקציות יכולות להעביר
true
אלWindow.setHideOverlayWindows()
.
סיכון: טוסט בהתאמה אישית
תוקף יכול להשתמש ב-Toast.setView()
כדי להתאים אישית את המראה של הודעת טוסטי. ב-Android 10 (רמת API 29) ומטה, אפליקציות זדוניות יכולות להציג הודעות כאלה ברקע.
אמצעי צמצום סיכונים
אם אפליקציה מטרגטת ל-Android 11 (רמת API 30) ומעלה, המערכת חוסמת טוסטים מותאמים אישית ברקע. עם זאת, יש נסיבות שבהן אפשר לעקוף את אמצעי ההגנה האלה באמצעות הצגת הודעות טוסט ברצף. במקרה כזה, התוקף מוסיף כמה הודעות טוסט לתור בזמן שהאפליקציה בחזית, והן ממשיכות להופיע גם אחרי שהאפליקציה עוברת לרקע.
החל מ-Android 12 (רמת API 31), התקפות של טוסטים ברקע והתקפות של פרצי טוסטים מנוטרלות באופן מלא.
סיכון: פעילות סנדוויץ'
אם אפליקציה זדונית מצליחה לשכנע משתמש לפתוח אותה, היא עדיין יכולה להפעיל פעילות מאפליקציית הקורבן, ואז להציג את הפעילות שלה מעל הפעילות של אפליקציית הקורבן, וכך ליצור סנדוויץ' של פעילויות ולבצע מתקפת הסתרה חלקית.
אמצעי צמצום סיכונים
אמצעי ההגנה הכלליים מפני הסתרה חלקית מפורטים כאן. כדי להגן על הנתונים בצורה מקיפה, חשוב לוודא שלא מייצאים פעילויות שלא צריך לייצא, כדי למנוע מתוקף להשתמש בהן כסנדוויץ'.
משאבים
מומלץ
- הערה: טקסט הקישור מוצג כש-JavaScript מושבת
- android:exported
- # ניהול מפתחות {:#key-management}
- הפעלת קוד DEX מוטמע ישירות מ-APK