אנחנו ב-Google Play מחויבים לשמור על הבטיחות של המשתמשים והמפתחים. אנחנו מבינים שפיתוח עסק אפליקציות משגשג מסתמך על פלטפורמה מהימנה – כזו שמבטיחה את ההחזר על ההשקעה שלכם על ידי הגנה יזומה מפני גורמים זדוניים.
במאמר הזה מוסבר איך למנוע מתקפות על מערכת החיוב ולהפחית את ההשפעה של ניצול לרעה באפליקציה.
שיפור ההגנות
ממשקי ה-API והכלים הבאים יכולים לצמצם את הסיכונים באפליקציה:
- Voided Purchases API: ביטול הגישה להזמנות שבוטלו.
- מספר חשבון שעבר טשטוש: עוזר לזהות מקרים שבהם כמה מכשירים מבצעים רכישות באותו חשבון בפרק זמן קצר.
- צריכה בשרת העורפי: כלים כמו Purchases.products:consume מעבירים את הלוגיקה העסקית לשרתים העורפיים המאובטחים שלכם, ומונעים שיבוש בצד הלקוח. בנוסף לשימוש בממשקי ה-API האלה של הפלטפורמה, כדאי לאמץ את השיטות המומלצות הבאות כדי להגביר את האבטחה של השילובים מפני גישה לא מורשית.
מניעת זיוף מיקום
ב-Google Play יש אמצעי הגנה מובנים שנועדו למנוע מגורמים זדוניים להשתמש במיקומים מזויפים כדי לנצל את ההבדלים בין מטבעות אזוריים (התופעה הזו נקראת גם זיוף מיקום), לנצל לרעה מבצעים ותמריצים למינויים ולנסות לבצע הונאות שקשורות לכרטיסי מתנה.
העברת לוגיקה רגישה אל ה-Backend
ככל שעיצוב האפליקציה מאפשר זאת, כדאי להעביר מידע אישי רגיש ולוגיקה לשרת backend שאתם שולטים בו. ככל שיש יותר נתונים ולוגיקה במכשיר קצה, כך הוא פגיע יותר לשינויים או לזיוף.
לדוגמה, במשחק שחמט באינטרנט צריך לאמת את כל המהלכים בקצה העורפי במקום להניח שהקצה החזיתי תמיד שולח מהלכים חוקיים.
בנוסף, אם אתם מוצאים נקודות חולשה או בעיות אבטחה, יכול להיות שיהיה לכם קל יותר לבצע ניפוי באגים, לתקן ולפרוס עדכונים בבק-אנד ולא בקצה הקדמי, בהתאם לעיצוב המערכת.
אימות רכישות לפני הענקת הרשאות
מקרה מיוחד של מידע אישי רגיש ולוגיקה שצריך לטפל בהם בקצה העורפי הוא אימות רכישה ואישור שלה. אחרי שמשתמש מבצע רכישה, צריך לבצע את הפעולות הבאות:
- שולחים את purchaseToken המתאים לשרת העורפי. כלומר, אתם צריכים לשמור תיעוד של כל הערכים של purchaseToken לכל הרכישות.
- מוודאים שהערך של purchaseToken עבור הרכישה הנוכחית לא תואם לאף ערך קודם של purchaseToken. הערך של purchaseToken הוא ייחודי באופן גלובלי, כך שאפשר להשתמש בו בבטחה כמפתח ראשי במסד הנתונים.
- כדי לוודא עם Google שהרכישה לגיטימית, אפשר להשתמש בנקודות הקצה Purchases.products:get או Purchases.subscriptionsv2:get בממשק API של Google Play למפתחים.
- אם הרכישה לגיטימית ולא נעשה בה שימוש בעבר, אפשר להעניק בבטחה זכאות לפריט באפליקציה או למינוי.
- במינויים, אם הפרמטר linkedPurchaseToken מוגדר ב-Purchases.subscriptionsv2:get, צריך גם להסיר את הפרמטר linkedPurchaseToken ממסד הנתונים ולבטל את ההרשאה שניתנה ל-linkedPurchaseToken כדי לוודא שלכמה משתמשים לא תהיה הרשאה לאותה רכישה.
- צריך להעניק זכאות רק כשמצב הרכישה הוא PURCHASED, וחשוב לטפל ברכישות במצב PENDING בצורה נכונה. אם יש עלייה פתאומית במספר הרכישות עם הסטטוס CANCELED, יכול להיות שאתם מעניקים הרשאות כשהרכישה עדיין במצב PENDING. מידע נוסף זמין במאמר טיפול בעסקאות בהמתנה.
אחרי שהמשתמשים יאשרו את הרכישה, אם רוצים להשלים ולאשר רכישה של מוצר מתכלה, צריך להשתמש ב-Play Developer API Purchases.products:consume בשרת הקצה העורפי המאובטח. כדי לאשר מוצר חד-פעמי או מינוי, צריך להתקשר לנקודת קצה ל-API הרלוונטית של Play Developer, Purchases.products:acknowledge או Purchases.subscriptions:acknowledge, בשרת הבק-אנד המאובטח. נדרש אישור, כי הוא מודיע ל-Google Play שהמשתמש קיבל הרשאה לרכישה. אחרי שהמשתמשים יאשרו את הרכישה, באפליקציה שלך חייב להופיע אישור על הרכישה.
שימו לב שאפשר לאשר את הרכישה או להשתמש בה בצד הלקוח דרך האפליקציה, אבל ממשקי API בצד השרת מספקים הגנה נוספת מפני בעיות כמו קישוריות רשת לקויה ופעילות זדונית. לדוגמה, נניח שמשתמש רכש פריט מהאפליקציה שלך, אבל איבד את החיבור לרשת בזמן שהרכישה הייתה בתהליך אימות. בלי אישור מהשרת, יכול להיות שהם יצטרכו להיכנס שוב דרך האפליקציה כדי להשלים את תהליך האישור. אחרת, אם המשתמש לא יתחבר מחדש תוך שלושה ימים, יתקבל החזר כספי אוטומטי על הרכישה בגלל שלא התקבל אישור רכישה. אישור מהשרת מונע את התרחיש הזה. האישור נשלח ברגע ש-Google Play מודיע לשרת שהרכישה תקפה.
מידע נוסף על אישור רכישות וצריכה זמין במאמר בנושא עיבוד רכישות.
הגנה על תוכן לא נעול
כדי למנוע ממשתמשים זדוניים להפיץ מחדש את התוכן שלא נעול, אל תצרפו אותו לקובץ ה-APK. במקום זאת, צריך לבצע אחת מהפעולות הבאות:
- להשתמש בשירות בזמן אמת כדי להעביר את התוכן, כמו פיד תוכן. הצגת תוכן באמצעות שירות בזמן אמת מאפשרת לכם גם לשמור על עדכניות התוכן.
- שימוש בשרת מרוחק כדי להעביר את התוכן. כשמעבירים תוכן משרת מרוחק או משירות בזמן אמת, אפשר לאחסן את התוכן הלא נעול בזיכרון המכשיר או בכרטיס ה-SD של המכשיר. אם אתם מאחסנים תוכן בכרטיס SD, הקפידו להצפין את התוכן ולהשתמש במפתח הצפנה ספציפי למכשיר.
זיהוי וטיפול ברכישות מבוטלות
רכישות שבוטלו הן רכישות שבוטלו, בוטלו או שבוצע לגביהן צ'ארג'בק. אם רכישה שבוטלה העניקה בעבר פריטים באפליקציה או תוכן אחר למשתמש, אפשר להשתמש ב-Voided Purchases API כדי לקבל את הסיבה לביטול הרכישה, יחד עם כל התוכן שמשויך אליה שאפשר להחזיר.
אפשר לבטל רכישות של פריטים באפליקציה ומינויים ממגוון סיבות, כולל הסיבות הבאות:
- רכישה בוטלה על ידי המשתמש, על ידי המפתח או על ידי Google (כולל רכישות שבוטלו אוטומטית ולא אושרו). במקרה של מינויים, חשוב לזכור שהכוונה היא לביטול הרכישה של המינוי, ולא לביטול המינוי עצמו.
- בוצע צ'ארג' בק לרכישה.
מפתח האפליקציה מבטל הזמנה של משתמש או מחזיר לו כסף, ומסמן את האפשרות 'ביטול' במסוף. על סמך הסיבה לביטול הרכישה, ובהתחשב בנתוני ההתנהגות הקודמים של המשתמש, תוכלו להחליט על דרך פעולה. מומלץ להטמיע אחת או יותר מהאפשרויות הבאות:
ביצוע החזרים: כשמבטלים רכישה, אפשר לבצע החזר על פריטים שלא נעשה בהם שימוש כאילו הם מעולם לא נרכשו. לדוגמה, אם רכישה של כסף וירטואלי במשחק בוטלה, אפשר להחזיר את המטבע שכבר הוענק למשתמש. אם המשתמש כבר השתמש במטבע, אפשר להגדיר את יתרת המטבע כערך שלילי ולהגביל את הפעילות באפליקציה ואת הרכישות העתידיות עד שיתרת המטבע תהיה חיובית.
הטמעה של מספר אזהרות: כדאי לשקול נקיטת פעולות פחות קיצוניות במקרים של הפרה ראשונה, כמו הצגת אזהרות בתוך האפליקציה. במקרים של הפרות חוזרות, כדאי לשקול אמצעים חמורים יותר.
השבתה זמנית של רכישות: בדומה להטמעה של מספר פסילות, כדאי להשבית רכישות למשתמשים עם רכישות שבוטלו עד שתהיה לכם אפשרות לבדוק לעומק למה הרכישות בוטלו.
השעיה זמנית או ביטול סופי של הגישה לאפליקציה: במקרים קיצוניים של פעילות זדונית חוזרת, כדאי לשקול השעיה זמנית או ביטול סופי של הגישה לאפליקציה.
שליחת קריאות תכופות ל- Voided Purchases API: כשמזהים רכישה או רכישות שבוטלו, מומלץ לשלוח קריאות תכופות יותר ל-Voided Purchases API כדי לבטל את הרכישות לפני שהמשתמש יוכל להשתמש בהן. מידע נוסף על מכסות של Voided Purchases API זמין במאמרי העזרה של ה-Voided Purchases API.
איך עוזרים ל-Google לזהות הונאות לפני שהן קורות
חלק מסוגי ההונאה קשורים למשתמשים זדוניים שיוצרים כמה חשבונות Google וכמה חשבונות באפליקציה כדי להסתיר את הפעילות שלהם.
כדי לעזור ל-Google למפות חשבונות Google לחשבונות באפליקציה, משתמשים בשיטות setObfuscatedAccountId ו-setObfuscatedProfileId בבונה של BillingFlowParams.
Google משתמשת בנתונים האלה כדי לזהות התנהגות חשודה ולחסום סוגים מסוימים של עסקאות הונאה לפני שהן מושלמות.
פעולות נגד הפרות של סימנים מסחריים והפרת זכויות יוצרים
אם אתם משתמשים בשרת מרוחק כדי להציג או לנהל תוכן, האפליקציה צריכה לאמת את מצב הרכישה של התוכן שנפתח בכל פעם שמשתמש ניגש לתוכן. כך תוכלו לבטל את השימוש כשצריך ולצמצם את הפיראטיות. אם אתם רואים שהתוכן שלכם מופץ מחדש ב-Google Play, חשוב לפעול במהירות ובנחישות. פרטים נוספים זמינים בדף שאלות נפוצות בנושא זכויות יוצרים במרכז העזרה בנושא זכויות יוצרים.