נלחמים בהונאות ובהתנהלות פוגעת

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

במאמר הזה מוסברות המלצות למניעת מתקפות על מערכת החיוב ולהפחתת ההשפעה של ניצול לרעה באפליקציה.

שיפור ההגנות

ממשקי ה-API והכלים הבאים יכולים לצמצם את הסיכונים באפליקציה:

• ‫Voided Purchases API: ביטול הגישה להזמנות שבוטלו.
• מספר חשבון שעבר טשטוש: עוזר לזהות מקרים שבהם כמה מכשירים מבצעים רכישות באותו חשבון בפרק זמן קצר.
• צריכה בשרת העורפי: כלים כמו Purchases.products:consume מעבירים את הלוגיקה העסקית לשרתים העורפיים המאובטחים שלכם, ומונעים שיבוש בצד הלקוח. בנוסף לשימוש בממשקי ה-API של הפלטפורמה, מומלץ לפעול לפי השיטות המומלצות הבאות כדי לאבטח עוד יותר את השילובים מפני גישה לא מורשית.

מניעת זיוף מיקום

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

העברת לוגיקה רגישה לחלק האחורי של האפליקציה

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

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

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

אימות רכישות לפני הענקת הרשאות

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

• שולחים את purchaseToken המתאים לשרת העורפי. כלומר, אתם צריכים לשמור תיעוד של כל הערכים של purchaseToken לכל הרכישות.
• מוודאים שהערך של purchaseToken עבור הרכישה הנוכחית לא תואם לאף ערך קודם של purchaseToken. הערך של purchaseToken הוא ייחודי באופן גלובלי, ולכן אפשר להשתמש בו בבטחה כמפתח ראשי במסד הנתונים.
• כדי לוודא עם Google שהרכישה לגיטימית, צריך להשתמש בנקודות הקצה Purchases.products:get או Purchases.subscriptionsv2:get ב-Google Play Developer API.
• אם לדעתכם הרכישה לגיטימית, לא נעשה בה שימוש ולא בוצע עיבוד שלה בעבר, והמשתמש עבר את כל הבדיקות שלכם בנוגע לזכאות ולהונאה, תוכלו להעניק לו בבטחה זכאות לפריט באפליקציה או למינוי.
  • בדיקות של עמידה בדרישות ושימוש לרעה: מוודאים שהמשתמש עדיין עומד בדרישות לשימוש בפריט. אם הגדרתם את רצף פעולות החיוב באמצעות obfuscatedAccountId או obfuscatedProfileId, צריך לוודא שהמיפוי של הרכישה תואם לחשבון המשתמש הצפוי במערכת שלכם. מבצעים בדיקות נוספות של ניצול לרעה, סיכונים או אבטחה שנדרשות על ידי ה-backend.
  • החזרים כספיים מפורשים על רכישות לא לגיטימיות: אם הרכישה לא עוברת את בדיקות האימות או בדיקות השימוש לרעה, אל תעניקו זכאות. במקום לאפשר החזר כספי אוטומטי על הרכישה בגלל חוסר אישור (שלא ברור אם הוא נובע מבעיה או מפסק זמן לעיבוד), צריך להחזיר את התשלום על הרכישה באופן מפורש באמצעות נקודת הקצה Orders:refund (או Play Developer API דומה) עם הפרמטר revoke שמוגדר לערך true. הגדרת הפרמטר revoke מבטיחה שהגישה תבוטל, כך שלמשתמש לא תהיה יותר זכאות לרכישה, ו-Google Play תקבל אות ברור שהרכישה נדחתה על ידי המפתח.
• במקרה של מינויים, אם הערך של linkedPurchaseToken מוגדר ב-Purchases.subscriptionsv2:get, צריך גם להסיר את linkedPurchaseToken ממסד הנתונים ולבטל את ההרשאה שניתנה ל-linkedPurchaseToken כדי לוודא שכמה משתמשים לא מקבלים הרשאה לאותה רכישה.
• צריך להעניק זכאות רק כשמצב הרכישה הוא PURCHASED, ולהקפיד לטפל ברכישות במצב PENDING בצורה נכונה. אם יש עלייה פתאומית במספר הרכישות עם הסטטוס CANCELED, יכול להיות שאתם מעניקים הרשאות כשהרכישה עדיין במצב PENDING. מידע נוסף זמין במאמר טיפול בעסקאות בהמתנה.

• אחרי שהמשתמשים יאשרו את הרכישה, אם רוצים להשלים ולאשר רכישה של מוצר מתכלה, צריך להשתמש ב-Purchases.products:consume Play Developer API בשרת הקצה העורפי המאובטח. כדי לאשר מוצר לא מתכלה או מינוי, צריך להתקשר לנקודת קצה ל-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 זמין במאמרי העזרה של ה-API של Voided Purchases.

עזרה ל-Google בזיהוי הונאות לפני שהן מתרחשות

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

משתמשים בשיטות setObfuscatedAccountId ו-setObfuscatedProfileId בכלי ליצירת BillingFlowParams כדי לעזור ל-Google למפות חשבונות Google לחשבונות באפליקציה.

‫Google משתמשת בנתונים האלה כדי לזהות התנהגות חשודה ולחסום סוגים מסוימים של עסקאות הונאה לפני שהן מושלמות.

פעולות נגד הפרות של סימנים מסחריים והפרת זכויות יוצרים

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