שיטות מומלצות להגנה מפני איומים אוטומטיים

במסמך הזה מתוארות ההטמעות המומלצות של Google Cloud Fraud Defense ואסטרטגיות לצמצום הונאות, כדי להגן מפני איומים אוטומטיים קריטיים (OWASP Automated Threats (OAT) to Web Applications). אדריכלים ארגוניים ובעלי עניין בתחום הטכנולוגיה יכולים לעיין במידע הזה כדי לקבל החלטה מושכלת לגבי הטמעה של הגנה מפני הונאה ואסטרטגיה לצמצום הונאה לתרחיש השימוש שלהם.

במסמך הזה מפורטים הפרטים הבאים לגבי כל סוג של איום:

• הטמעה אופטימלית של Fraud Defense. ההטמעה הזו נועדה להשתמש בתכונות הרלוונטיות של Fraud Defense כדי לספק את ההגנה הטובה ביותר מפני הונאות.

• הטמעה מינימלית של 'הגנה מפני הונאות'. ההטמעה הזו מיועדת להגנה מינימלית מפני הונאות.

• אסטרטגיות מומלצות לצמצום הונאות.

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

• הצרכים והיכולות של הארגון למניעת הונאות.
• הסביבה הקיימת של הארגון.

הערה: מומלץ לבחור בהטמעה אופטימלית או בהטמעה מינימלית, בהתאם לצרכים של הארגון למניעת הונאות.

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

Carding

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

הטמעה מינימלית

1. צריך להתקין מפתחות אתר של תיבת סימון בכל הדפים שבהם משתמשי הקצה צריכים להזין את פרטי כרטיס האשראי שלהם. במאמר התקנת מפתחות אתר של תיבת סימון (אתגר תיבת סימון) באתרים מוסבר איך להתקין מפתחות אתר של תיבת סימון.

   הערה: מפתחות אתר עם תיבת סימון מגבירים את החיכוך עם המשתמשים ועשויים להשפיע על שיעורי ההמרה.

2. יוצרים הערכות לכל הטוקנים. במאמר יצירת כלי הערכה מוסבר איך ליצור כלי הערכה.

הטמעה אופטימלית

1. צריך להתקין מפתחות אתר מבוססי-ניקוד בכל הדפים שבהם משתמשי הקצה צריכים להזין את פרטי כרטיס האשראי שלהם. מציינים פעולה בפרמטר action, כמו card_entry. במאמר התקנת מפתחות אתר מבוססי-ניקוד (ללא אתגר) באתרים מוסבר איך להתקין מפתחות אתר מבוססי-ניקוד.

2. מתקינים את reCAPTCHA בתהליך התשלום באתר. כאן מוסבר איך להגן על תהליך העבודה שקשור לתשלומים.

3. יוצרים הערכות לכל הטוקנים ומגדירים את expectedAction כך שיתאים לערך של action שצוין כשמתקינים את מפתחות האתר שמבוססים על ניקוד. איך יוצרים הערכה

4. שומרים את כל מזהי ההערכה ומסמנים את ההערכות שהופכות לרכישות או להחזרים כספיים הונאה בסימון fraudulent. איך מוסיפים הערות למטלה

אסטרטגיה למניעת הונאות

אחרי שמטמיעים את Fraud Defense, אפשר להשתמש באחת מהאסטרטגיות הבאות לצמצום הונאות כדי להגן על האתר מפני הונאות בכרטיסי אשראי:

• מתקינים את reCAPTCHA בתהליך התשלום באתר. כאן מוסבר איך להגן על תהליך העבודה שקשור לתשלומים.

• כדי לוודא שהטוקנים של reCAPTCHA תקפים והציונים גבוהים מערך הסף שלהם, צריך להגדיר ממשקי API לניהול כרטיסים.

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

• כשיוצרים הערכות, חשוב לוודא שהן עומדות בקריטריונים הבאים כדי שהעסקה תצליח:

  • כל האסימונים שנבדקו תקינים והציון שלהם גבוה מערך סף שצוין.
  • הערך של expectedAction זהה לערך של action שציינתם כש התקנתם את מפתחות האתר שמבוססים על ניקוד בדפי האינטרנט שלכם. במאמר אימות פעולות מוסבר איך לאמת פעולות.

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

פריצה לכרטיסי אשראי

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

הטמעה מינימלית

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

   הערה: מפתחות אתר עם תיבת סימון מגבירים את החיכוך עם המשתמשים ועשויים להשפיע על שיעורי ההמרה.

2. ליצור הערכות לכל הטוקנים. במאמר יצירת מבחן מוסבר איך ליצור מבחנים.

הטמעה אופטימלית

1. צריך להתקין מפתחות אתר מבוססי-ניקוד בכל הדפים שבהם משתמשי הקצה צריכים להזין את פרטי התשלום שלהם. מציינים פעולה בפרמטר action, כמו checkout או add_pmtmethod. במאמר התקנת מפתחות לאתרים שמבוססים על ניקוד (ללא אתגר) מוסבר איך להתקין מפתחות לאתרים שמבוססים על ניקוד.

2. מתקינים את reCAPTCHA בתהליך התשלום באתר. כאן מוסבר איך להגן על תהליך העבודה שקשור לתשלומים.

3. יוצרים הערכות לכל הטוקנים ומגדירים את expectedAction כך שיתאים לערך של action שציינתם כשהתקנתם את מפתחות האתר שמבוססים על ניקוד. במאמר יצירת מבחן מוסבר איך ליצור מבחנים.

4. שומרים את כל מזהי ההערכות ומוסיפים הערות להערכות שהופכות לרכישות שמקורן בתרמית או להחזרים כספיים בעקבות ביטול עסקה בתור fraudulent. במאמר הוספת הערות להערכה מוסבר איך להוסיף הערות להערכות.

אסטרטגיה לצמצום הונאות

אחרי שמטמיעים את Fraud Defense, אפשר להשתמש באחת מהאסטרטגיות הבאות לצמצום הונאות כדי להגן על האתר מפני פריצה לכרטיסי אשראי:

• מתקינים את reCAPTCHA בתהליך התשלום באתר. כאן מוסבר איך להגן על תהליך העבודה שקשור לתשלומים.

• הטמעת מודל תגובה ויצירת הערכות:

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

     בדוגמה הבאה מוצג מודל תגובה לדוגמה:

     • לסף ציון נמוך עד בינוני (0.0 עד 0.5), כדאי להשתמש בניהול סיכונים מבוסס-הקשר, כמו הגבלת מספר הניסיונות וחסימת רכישות מעל ערך מסוים.
     • עבור סף הניקוד הגבוה ביותר (> 0.5), מאפשרים למשתמש הקצה להמשיך ללא אתגר.
     הערה: ערכי הסף של הניקוד עשויים להשתנות בהתאם למשתמשים ולתוקפים. מומלץ להשתמש בלוח הבקרה של ניתוח הנתונים של reCAPTCHA כדי לקבוע את הציונים הטובים ביותר שצריך לפעול לגביהם.

  2. כשיוצרים הערכות, צריך לוודא שהערך של expectedAction תואם לערך של action שציינתם כשהתקנתם את מפתחות האתר שמבוססים על ניקוד בדפי האינטרנט. אם הם לא תואמים, אל תפעילו אישור כרטיס ואל תאפשרו למשתמש הקצה להשתמש בכרטיס. אם אפשר, כדאי לאפשר את ביצוע העסקה בזמן הרכישה, אבל לבטל אותה מאוחר יותר כדי לא להזהיר את התוקף.

פיצוח פרטי כניסה

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

הטמעה מינימלית

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

   הערה: מפתחות אתר עם תיבת סימון מגבירים את החיכוך עם המשתמשים ועשויים להשפיע על שיעורי ההמרה.

2. יוצרים הערכות לכל הטוקנים. במאמר יצירת מבחן מוסבר איך ליצור מבחנים.

הטמעה אופטימלית

1. התקינו מפתחות אתר מבוססי-ניקוד בכל הדפים שבהם משתמשי הקצה צריכים להזין את פרטי הכניסה שלהם. מציינים פעולה בפרמטר action, כמו login או authenticate. במאמר התקנת מפתחות אתר מבוססי-ניקוד (ללא אתגר) באתרים מוסבר איך להתקין מפתחות אתר מבוססי-ניקוד.
2. מומלץ: להטמיע את ההגנה על הסיסמה של reCAPTCHA לכל ניסיונות האימות. כדי ללמוד איך להשתמש בהגנה על סיסמאות, אפשר לעיין במאמר זיהוי של דליפות סיסמאות ופרטי כניסה שנפרצו.
3. אופציונלי: כדי להפעיל חסימה של אינטראקציות עם נפח גבוה וציון reCAPTCHA נמוך, משלבים את reCAPTCHA עם חומת אש של אפליקציית אינטרנט (WAF). לדוגמה, אפשר להשתמש בשילוב של reCAPTCHA עם WAF ו-Google Cloud Armor.
4. להטמיע את reCAPTCHA account defender כדי לזהות מגמות בהתנהגות של משתמשי הקצה בכניסות לחשבון, ולקבל אותות נוספים שיכולים להצביע על השתלטות על חשבון. במאמר זיהוי ומניעה של פעילויות שמקורן בתרמית שקשורות לחשבון מוסבר איך משתמשים ב-reCAPTCHA הגנה על החשבון.
5. יוצרים הערכות לכל הטוקנים ומגדירים את expectedAction כך שיתאים לערך של action שציינתם כשהתקנתם את מפתחות האתר שמבוססים על ניקוד. איך יוצרים הערכה
6. שומרים את כל מזהי הבדיקות ומוסיפים הערות לבדיקה שנראית כמו תרמית, כמו השתלטות על חשבונות (ATO) או כל פעילות שמקורה בתרמית. איך מוסיפים הערות למטלה

אסטרטגיה לצמצום הונאות

אחרי שמטמיעים את התכונה 'הגנה מפני תרמיות', אפשר להשתמש באסטרטגיה הבאה לצמצום תרמיות כדי להגן על האתר מפני פריצה לפרטי כניסה:

1. ליצור ולהטמיע מודל תגובה שמותאם לסיכון שמבוסס על ניקוד.

   בדוגמה הבאה מוצג מודל תגובה לדוגמה:

   • במקרה של סף ניקוד נמוך עד בינוני (0.0 עד 0.5), צריך לאתגר את משתמש הקצה באמצעות אימות רב-שלבי דרך אימייל או SMS.
   • בסף הניקוד הגבוה ביותר (> 0.5), מאפשרים למשתמש הקצה להמשיך בלי אתגר.
   הערה: ערכי הסף של הניקוד עשויים להשתנות בהתאם למשתמשים ולתוקפים. מומלץ להשתמש בלוח הבקרה של ניתוח הנתונים של reCAPTCHA כדי לקבוע את הציונים הטובים ביותר שצריך לפעול לגביהם.
2. לסיים או להפריע לסשנים של משתמשי קצה שעוברים אימות בהצלחה אבל מקבלים תשובה של credentialsLeaked: true מההגנה על הסיסמה של reCAPTCHA, ולשלוח אימייל למשתמשי הקצה כדי שישנו את הסיסמה שלהם.
3. כשיוצרים הערכות, צריך לוודא שהערך של expectedAction זהה לערך של action שציינתם כש התקנתם את מפתחות האתר שמבוססים על ניקוד בדפי האינטרנט. אם הם לא תואמים, אל תאפשרו את האימות.

דחיסת פרטי כניסה

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

הטמעה מינימלית

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

   הערה: מפתחות אתר עם תיבת סימון מגבירים את החיכוך עם המשתמשים ועשויים להשפיע על שיעורי ההמרה.

2. ליצור הערכות לכל הטוקנים. איך יוצרים הערכה

הטמעה אופטימלית

1. התקינו מפתחות אתר מבוססי-ניקוד בכל הדפים שבהם משתמשי הקצה צריכים להזין את פרטי הכניסה שלהם. צריך לציין פעולה בפרמטר action, למשל login או authenticate. במאמר התקנת מפתחות לאתרים שמבוססים על ניקוד (ללא אתגר) מוסבר איך להתקין מפתחות לאתרים שמבוססים על ניקוד.
2. מומלץ: להטמיע את ההגנה על סיסמאות באמצעות reCAPTCHA בכל ניסיונות האימות. כדי ללמוד איך להשתמש בהגנה על סיסמאות, אפשר לעיין במאמר זיהוי של דליפות סיסמאות ופרטי כניסה שנפרצו.
3. כדאי להטמיע את reCAPTCHA account defender כדי לעקוב אחרי מגמות בהתנהגות של משתמשי קצה במהלך הכניסה לחשבון ולקבל אותות נוספים שיכולים להעיד על השתלטות על חשבון. במאמר זיהוי ומניעה של פעילות שמקורה בתרמית שקשורה לחשבון מוסבר איך משתמשים ב-reCAPTCHA הגנה על החשבון.

4. אופציונלי: כדי להפעיל חסימה של אינטראקציות עם נפח גבוה וציון reCAPTCHA נמוך, משלבים את reCAPTCHA עם חומת אש של אפליקציית אינטרנט (WAF). לדוגמה, אתם יכולים להשתמש ב-reCAPTCHA ל-WAF ובשילוב עם Google Cloud Armor.

5. יוצרים הערכות לכל הטוקנים ומגדירים את expectedAction כך שיתאים לערך של action שציינתם כשהתקנתם את מפתחות האתר שמבוססים על ניקוד. במאמר יצירת מבחן מוסבר איך ליצור מבחנים.

6. שומרים את כל מזהי ההערכות ומוסיפים הערות להערכות שהופכות לרכישות שמקורן בתרמית או להחזרים כספיים בעקבות ביטול עסקה בתור fraudulent. במאמר הוספת הערות להערכה מוסבר איך להוסיף הערות להערכות.

אסטרטגיה לצמצום הונאות

אחרי שמטמיעים את התכונה 'הגנה מפני תרמיות', אפשר להשתמש באסטרטגיה הבאה לצמצום הסיכון להונאות כדי להגן על האתר מפני מילוי פרטי כניסה גנובים:

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

   בדוגמה הבאה מוצג מודל תגובה לדוגמה:

   • במקרה של סף הניקוד הנמוך ביותר ב-reCAPTCHA‏ (0.0), צריך להודיע למשתמש הקצה שהסיסמה שלו שגויה.
   • במקרה של סף ביניים (0.1-0.5), צריך לבקש ממשתמש הקצה לבצע אימות רב-שלבי באמצעות אימייל או SMS.
   • עבור סף הניקוד הגבוה ביותר (> 0.5), מאפשרים למשתמש הקצה להמשיך ללא אתגר.
   הערה: ערכי הסף של הניקוד עשויים להשתנות בהתאם למשתמשים ולתוקפים. מומלץ להשתמש בלוח הבקרה של ניתוח הנתונים של reCAPTCHA כדי לקבוע את הציונים הטובים ביותר שצריך לפעול לגביהם.
2. לסיים או להפריע לסשנים של משתמשי קצה שעוברים אימות בהצלחה אבל מקבלים תשובה של credentialsLeaked: true מההגנה על הסיסמה של reCAPTCHA, ולשלוח אימייל למשתמשי הקצה כדי שישנו את הסיסמה שלהם.
3. כשיוצרים הערכות, צריך לוודא שהערך של expectedAction תואם לערך של action שציינתם כשהתקנתם את מפתחות האתר שמבוססים על ניקוד בדפי האינטרנט. אם הם לא זהים, לא מאשרים את האימות.
4. בבדיקה, אם accountDefenderAssessment=PROFILE_MATCH, מאפשרים למשתמש הקצה להמשיך בלי אתגר.

משיכת כסף

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

הטמעה מינימלית

1. מטמיעים מפתחות אתר מבוססי-ניקוד בכל הדפים שבהם אפשר לבצע תשלום. במאמר התקנת מפתחות אתר מבוססי-ניקוד (ללא אתגר) באתרים מוסבר איך להתקין מפתחות אתר מבוססי-ניקוד.
2. ליצור הערכות לכל הטוקנים. במאמר יצירת מבחן מוסבר איך ליצור מבחנים.

הטמעה אופטימלית

1. מטמיעים מפתחות אתר מבוססי-ניקוד בכל הדפים שבהם משתמשי הקצה מזינים את פרטי כרטיסי המתנה שלהם. מציינים פעולה כמו add_gift_card. במאמר התקנת מפתחות לאתרים שמבוססים על ניקוד (ללא אתגר) מוסבר איך להתקין מפתחות לאתרים שמבוססים על ניקוד.

2. יוצרים הערכות לכל הטוקנים ומגדירים את expectedAction כך שיתאים לערך של action שצוין כשמתקינים את מפתחות האתר שמבוססים על ניקוד. במאמר יצירת כלי הערכה מוסבר איך ליצור כלי הערכה.

3. שומרים את כל מזהי ההערכה ומסמנים את העסקאות שהיו הונאה.

אסטרטגיה לצמצום הונאות

אחרי שמטמיעים את Fraud Defense, אפשר להשתמש באסטרטגיית צמצום ההונאות הבאה כדי להגן על האתר מפני משיכת כספים:

• מתקינים את reCAPTCHA בתהליך התשלום באתר. במאמר הגנה על תהליכי עבודה של תשלומים מוסבר איך להגן על תהליך העבודה של התשלומים.

• הטמעה של מודל תגובה ויצירת מבחנים:

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

     בדוגמה הבאה מוצג מודל תגובה לדוגמה:

     • לסף ציון נמוך עד בינוני (0.0 עד 0.5), כדאי להשתמש בניהול סיכונים מבוסס-הקשר, כמו הגבלת מספר הניסיונות וחסימת רכישות מעל ערך מסוים.
     • עבור סף הניקוד הגבוה ביותר (> 0.5), מאפשרים למשתמש הקצה להמשיך ללא אתגר.
     הערה: ערכי הסף של הניקוד עשויים להשתנות בהתאם למשתמשים ולתוקפים. מומלץ להשתמש בלוח הבקרה של ניתוח הנתונים של reCAPTCHA כדי לקבוע את הציונים הטובים ביותר שצריך לפעול לגביהם.
  2. כשיוצרים הערכות, צריך לוודא שהערך של expectedAction זהה לערך של action שציינתם כש התקנתם את מפתחות האתר שמבוססים על ניקוד בדפי האינטרנט. אם הם לא זהים, לא מאשרים את האימות. אם אפשר, כדאי לאפשר את ביצוע העסקה בזמן הרכישה, אבל לבטל אותה מאוחר יותר כדי לא להזהיר את התוקף.

יצירת חשבון

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

הטמעה מינימלית

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

   הערה: מפתחות אתר עם תיבת סימון מגבירים את החיכוך עם המשתמשים ועשויים להשפיע על שיעורי ההמרה.

2. ליצור הערכות לכל הטוקנים. איך יוצרים הערכות

הטמעה אופטימלית

1. מטמיעים מפתחות אתר מבוססי-ניקוד בכל הדפים שבהם נוצרים חשבונות. מציינים פעולה בפרמטר action, כמו register. במאמר התקנת מפתחות לאתרים שמבוססים על ניקוד (ללא אתגר) מוסבר איך להתקין מפתחות לאתרים שמבוססים על ניקוד.
2. מומלץ: להטמיע את ההגנה על סיסמאות באמצעות reCAPTCHA בכל ניסיונות האימות. כדי ללמוד איך להשתמש בהגנה על סיסמאות, אפשר לעיין במאמר זיהוי של דליפות סיסמאות ופרטי כניסה שנפרצו.
3. כדי לקבל אותות נוספים שמצביעים על יצירת חשבונות מזויפים, אתם יכולים להטמיע את Fraud Defense הגנה על החשבון. במאמר זיהוי ומניעה של פעילויות שמקורן בתרמית שקשורות לחשבון מוסבר איך משתמשים ב-reCAPTCHA הגנה על החשבון.

4. אופציונלי: כדי להפעיל חסימה של אינטראקציות עם נפח גבוה וציון reCAPTCHA נמוך, משלבים את reCAPTCHA עם חומת אש של אפליקציית אינטרנט (WAF). לדוגמה, אתם יכולים להשתמש ב-reCAPTCHA לשילוב עם WAF ו-Google Cloud Armor.

5. יוצרים הערכות לכל הטוקנים ומגדירים את expectedAction כך שיתאים לערך של action שצוין כשמתקינים את מפתחות האתר שמבוססים על ניקוד. איך יוצרים הערכה

6. שומרים את כל מזהי ההערכות ומוסיפים הערות לעסקאות שמקורן בתרמית.

אסטרטגיה לצמצום הונאות

אחרי שמטמיעים את Fraud Defense, משתמשים באסטרטגיה הבאה כדי להגן על האתר מפני יצירת חשבונות:

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

   בדוגמה הבאה מוצג מודל תגובה לדוגמה:

   • בסף הניקוד הנמוך ביותר של reCAPTCHA‏ (0.0), הגבילו את הפעולות של החשבון עד שהוא יעבור בדיקות נוספות למניעת הונאות.
   • במקרה של סף ביניים (0.1-0.5), המערכת תבקש ממשתמש הקצה לבצע אימות רב-שלבי באמצעות אימייל או SMS.
   • עבור סף הניקוד הגבוה ביותר (> 0.5), מאפשרים למשתמש הקצה להמשיך ללא אתגר.
   הערה: ערכי הסף של הניקוד עשויים להשתנות בהתאם למשתמשים ולתוקפים. מומלץ להשתמש בלוח הבקרה של ניתוח הנתונים של reCAPTCHA כדי לקבוע את הציונים הטובים ביותר שצריך לפעול לגביהם.
2. סיום או הפרעה של סשנים של משתמשי קצה שעברו אימות בהצלחה אבל קיבלו תגובה credentialsLeaked: true מ-Fraud Defense ומ'הגנה על הסיסמה', ומוצגת למשתמש בקשה לבחור סיסמה חדשה.
3. כשיוצרים הערכות, צריך לוודא שהערך של expectedAction תואם לערך של action שציינתם כשהתקנתם את מפתחות האתר שמבוססים על ניקוד בדפי האינטרנט. אם הם לא זהים, לא מאשרים את ההרשמה לחשבון או את יצירת החשבון.
4. אם בבדיקה שלכם מתקבל הערך accountDefenderAssessment=SUSPICIOUS_ACCOUNT_CREATION, צריך להגביל את הגישה לחשבון עד שניתן יהיה לבצע אימות נוסף.

שינויים בחשבון ובכתובת שמקורם בתרמית

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

הטמעה מינימלית

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

   הערה: מפתחות אתר עם תיבת סימון מגבירים את החיכוך עם המשתמשים ועשויים להשפיע על שיעורי ההמרה.

2. ליצור הערכות לכל הטוקנים. איך יוצרים הערכה

הטמעה אופטימלית

1. מטמיעים מפתחות אתר מבוססי-ניקוד בכל הדפים שבהם נוצרים חשבונות. מציינים פעולה בפרמטר action, למשל change_telephone או change_physicalmail. במאמר התקנת מפתחות לאתרים שמבוססים על ניקוד (ללא אתגר) מוסבר איך להתקין מפתחות לאתרים שמבוססים על ניקוד.

2. יוצרים הערכות לכל הטוקנים ומגדירים את expectedAction כך שיתאים לערך של action שציינתם כשהתקנתם את מפתחות האתר שמבוססים על ניקוד. במאמר יצירת מבחן מוסבר איך ליצור מבחנים.

3. כדאי להטמיע את reCAPTCHA account defender כדי לעקוב אחרי מגמות בהתנהגות של משתמשי קצה במהלך הכניסה לחשבון ולקבל אותות נוספים שיכולים להעיד על השתלטות על חשבון. במאמר זיהוי ומניעה של פעילות שמקורה בתרמית שקשורה לחשבון מוסבר איך משתמשים ב-reCAPTCHA הגנה על החשבון.

4. שומרים את כל מזהי ההערכות ומוסיפים הערות לעסקאות שמקורן בתרמית.

אסטרטגיה למניעת הונאות

אחרי שמטמיעים את Fraud Defense, משתמשים באסטרטגיה הבאה לצמצום הונאות כדי להגן על האתר מפני שינויים בהונאה בחשבונות ובכתובות:

1. ליצור ולהטמיע מודל תגובה שמותאם לסיכון שמבוסס על ניקוד.

   בדוגמה הבאה מוצג מודל תגובה לדוגמה:

   • במקרה של סף ניקוד נמוך עד בינוני (0.0 עד 0.5), צריך לאתגר את משתמש הקצה באמצעות אימות רב-שלבי דרך אימייל או SMS.
   • בסף הניקוד הגבוה ביותר (> 0.5), מאפשרים למשתמש הקצה להמשיך בלי אתגר.
   הערה: ערכי הסף של הניקוד עשויים להשתנות בהתאם למשתמשים ולתוקפים. מומלץ להשתמש בלוח הבקרה של ניתוח הנתונים של reCAPTCHA כדי לקבוע את הציונים הטובים ביותר שצריך לפעול לגביהם.

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

3. אם בבדיקה שלכם ל-accountDefenderAssessment לא מופיעה התווית PROFILE_MATCH, צריך לאתגר את משתמש הקצה באמצעות אימות רב-שלבי (MFA) דרך אימייל או SMS.

פיצוח טוקנים

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

הטמעה מינימלית

1. מתקינים מפתחות אתר של תיבת סימון בכל הדפים שבהם משתמשי הקצה צריכים להזין את פרטי כרטיס המתנה שלהם. במאמר התקנת מפתחות אתר של תיבת סימון (אתגר תיבת סימון) באתרים מוסבר איך להתקין מפתחות אתר של תיבת סימון.

   הערה: מפתחות אתר עם תיבת סימון מגבירים את החיכוך עם המשתמשים ועשויים להשפיע על שיעורי ההמרה.

2. יוצרים הערכות לכל הטוקנים. איך יוצרים הערכה

הטמעה אופטימלית

1. מתקינים מפתחות אתר שמבוססים על ניקוד בכל הדפים שבהם משתמשי הקצה צריכים להזין את פרטי כרטיס המתנה. מציינים פעולה כמו gift_card_entry. במאמר התקנת מפתחות אתר מבוססי-ניקוד (ללא אתגר) באתרים מוסבר איך להתקין מפתחות אתר מבוססי-ניקוד.

2. אופציונלי: כדי לחסום אינטראקציות בנפח גבוה עם ציון reCAPTCHA נמוך, משלבים את reCAPTCHA עם חומת אש ליישומי אינטרנט (WAF). לדוגמה, אתם יכולים להשתמש ב-reCAPTCHA ל-WAF ובשילוב עם Google Cloud Armor.

3. יוצרים הערכות לכל הטוקנים ומגדירים את expectedAction כך שיתאים לערך של action שציינתם כשהתקנתם את מפתחות האתר שמבוססים על ניקוד. איך יוצרים הערכות

4. שומרים את כל מזהי ההערכות ומוסיפים הערות להערכות שהופכות לכרטיסי מתנה או לשוברים שמקורם בתרמית.

אסטרטגיה לצמצום הונאות

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

• כדי לוודא שהטוקנים של reCAPTCHA תקפים והציונים גבוהים מערך הסף שלהם, צריך להגדיר ממשקי API לניהול כרטיסים.

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

• כשיוצרים הערכות, חשוב לוודא שהן עומדות בקריטריונים הבאים כדי שהעסקה תצליח:

  • כל האסימונים שנבדקו תקינים והציון שלהם גבוה מערך סף שצוין.
  • הערך של expectedAction זהה לערך של action שציינתם כש התקנתם את מפתחות האתר שמבוססים על ניקוד בדפי האינטרנט שלכם. במאמר אימות פעולות מוסבר איך לאמת פעולות.

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

סקלפינג

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

הטמעה מינימלית

1. התקינו מפתחות אתר מבוססי-ניקוד בכל הדפים שבהם משתמשי הקצה צריכים להזין את פרטי כרטיס המתנה. מציינים פעולה בפרמטר action, כמו add_to_cart. במאמר התקנת מפתחות אתר מבוססי-ניקוד (ללא אתגר) באתרים מוסבר איך להתקין מפתחות אתר מבוססי-ניקוד.
2. יוצרים הערכות לכל הטוקנים ומגדירים את expectedAction כך שיתאים לערך של action שצוין כשמתקינים את מפתחות האתר שמבוססים על ניקוד. במאמר יצירת כלי הערכה מוסבר איך ליצור כלי הערכה.

הטמעה אופטימלית

1. צריך להתקין מפתחות אתר מבוססי-ניקוד בכל הדפים שבהם משתמשי הקצה צריכים להזין את פרטי כרטיס המתנה שלהם. מציינים פעולה בפרמטר action, כמו add_to_cart. במאמר התקנת מפתחות לאתרים שמבוססים על ניקוד (ללא אתגר) מוסבר איך להתקין מפתחות לאתרים שמבוססים על ניקוד.

2. אופציונלי: כדי להפעיל חסימה של אינטראקציות עם נפח גבוה וציון reCAPTCHA נמוך, משלבים את reCAPTCHA עם חומת אש של אפליקציית אינטרנט (WAF). לדוגמה, אפשר להשתמש בשילוב של reCAPTCHA עם WAF ו-Google Cloud Armor.

3. יוצרים הערכות לכל הטוקנים ומגדירים את expectedAction כך שיתאים לערך של action שצוין כשמתקינים את מפתחות האתר שמבוססים על ניקוד. במאמר יצירת מבחן מוסבר איך ליצור מבחנים.

4. שומרים את כל מזהי ההערכה ומסמנים את העסקאות שהיו הונאה.

אסטרטגיה לצמצום הונאות

אחרי שמטמיעים את Fraud Defense, אפשר להשתמש באסטרטגיה הבאה כדי להגן על האתר מפני ספסרות:

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

   בדוגמה הבאה מוצג מודל תגובה לדוגמה:

   • לסף ציון נמוך עד בינוני (0.0 עד 0.5), כדאי להשתמש בניהול סיכונים מבוסס-הקשר, כמו הגבלת מספר הניסיונות וחסימת רכישות מעל ערך מסוים.
   • עבור סף הניקוד הגבוה ביותר (> 0.5), מאפשרים למשתמש הקצה להמשיך ללא אתגר.
   הערה: ערכי הסף של הניקוד עשויים להשתנות בהתאם למשתמשים ולתוקפים. מומלץ להשתמש בלוח הבקרה של ניתוח הנתונים של reCAPTCHA כדי לקבוע את הציונים הטובים ביותר שצריך לפעול לגביהם.

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

הטיה

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

הטמעה מינימלית

1. הטמיעו מפתחות אתר מבוססי-ניקוד בכל הדפים שבהם יכולה להיות הטיה של המדדים. במאמר התקנת מפתחות אתר מבוססי-ניקוד (ללא אתגר) באתרים מוסבר איך להתקין מפתחות אתר מבוססי-ניקוד.
2. יוצרים הערכות לכל הטוקנים. איך יוצרים הערכה

הטמעה אופטימלית

1. הטמיעו מפתחות אתר מבוססי-ניקוד בכל הדפים שבהם יכולה להיות הטיה של המדדים. במאמר התקנת מפתחות אתר מבוססי-ניקוד (ללא אתגר) באתרים מוסבר איך להתקין מפתחות אתר מבוססי-ניקוד.

2. אופציונלי: כדי להפעיל חסימה של אינטראקציות עם נפח גבוה וציון reCAPTCHA נמוך, משלבים את reCAPTCHA עם חומת אש של אפליקציית אינטרנט (WAF). לדוגמה, אפשר להשתמש בשילוב של reCAPTCHA עם WAF ו-Google Cloud Armor.

3. יוצרים הערכות לכל הטוקנים ומגדירים את expectedAction כך שיתאים לערך של action שצוין כשמתקינים את מפתחות האתר שמבוססים על ניקוד. במאמר יצירת מבחן מוסבר איך ליצור מבחנים.

4. שומרים את כל מזהי ההערכה ומסמנים את העסקאות שהיו הונאה.

אסטרטגיה לצמצום הונאות

אחרי שמטמיעים את Fraud Defense, כדאי להשתמש באסטרטגיה הבאה כדי להגן על האתר מפני הטיה:

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

בדוגמה הבאה מוצג מודל תגובה לדוגמה:

• אם סף הניקוד נמוך עד בינוני (0.0-0.5), כדאי להשתמש בניהול סיכונים מבוסס-הקשר, כמו מעקב אחרי מספר הפעמים שמשתמש לחץ על מודעה או מספר הפעמים שמשתמש טען מחדש את הדף. השתמשו בנתונים האלה כדי לקבוע אם לספור את המדד.
• עבור סף הניקוד הגבוה ביותר (> 0.5), מאפשרים למשתמש הקצה להמשיך ללא אתגר.

הערה: ערכי הסף של הניקוד עשויים להשתנות בהתאם למשתמשים ולתוקפים. מומלץ להשתמש בלוח הבקרה של ניתוח הנתונים ב-reCAPTCHA כדי לקבוע מהם הציונים הטובים ביותר שצריך לפעול לפיהם.

גירוד

גירוד מידע הוא איום אוטומטי שבו תוקפים אוספים נתונים או פריטי מידע מאתרים באופן אוטומטי.

הטמעה מינימלית

1. כדאי להתקין מפתחות אתר מבוססי-ניקוד בכל הדפים שבהם מופיע מידע חשוב ובדפים נפוצים שבהם מתרחשת אינטראקציה עם משתמשי הקצה. במאמר התקנת מפתחות אתר מבוססי-ניקוד (ללא אתגר) באתרים מוסבר איך להתקין מפתחות אתר מבוססי-ניקוד.
2. ליצור הערכות לכל הטוקנים. במאמר יצירת מבחן מוסבר איך ליצור מבחנים.

הטמעה אופטימלית

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

2. אופציונלי: כדי לחסום אינטראקציות בנפח גבוה עם ציון reCAPTCHA נמוך, משלבים את reCAPTCHA עם חומת אש ליישומי אינטרנט (WAF). לדוגמה, אתם יכולים להשתמש ב-reCAPTCHA לשילוב עם WAF ו-Google Cloud Armor.

3. יוצרים הערכות לכל הטוקנים. איך יוצרים הערכה

4. שומרים את כל מזהי ההערכה ומסמנים את העסקאות שהיו הונאה.

אסטרטגיה לצמצום הונאות

אחרי שמטמיעים את Fraud Defense, אפשר להשתמש באסטרטגיות הבאות כדי להגן על האתר מפני גירוד נתונים:

• כדי לחסום אינטראקציות בהיקף גדול עם ציון נמוך ב-reCAPTCHA, אפשר לשלב את Fraud Defense עם חומת אש לאפליקציות אינטרנט (WAF). לדוגמה, אפשר להשתמש בFraud Defense לשילוב עם WAF ו-Google Cloud Armor
• אם גירוד המידע כולל ממשקי API, השתמשו ב-Apigee Management API כדי להפחית את הסיכון.

התגברות על CAPTCHA

התקפת CAPTCHA היא איום אוטומטי שבו התוקפים משתמשים באוטומציה בניסיון לנתח ולקבוע את התשובה למבחני CAPTCHA חזותיים או קוליים ולחידות קשורות.

הטמעה מינימלית

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

2. יוצרים הערכות לכל הטוקנים ומגדירים את expectedAction כך שיתאים לערך של action שצוין כשמתקינים את מפתחות האתר שמבוססים על ניקוד. איך יוצרים הערכה

הטמעה אופטימלית

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

2. אופציונלי: כדי להפעיל חסימה של אינטראקציות עם נפח גבוה וציון reCAPTCHA נמוך, משלבים את reCAPTCHA עם חומת אש של אפליקציית אינטרנט (WAF). לדוגמה, אתם יכולים להשתמש ב-reCAPTCHA לשילוב עם WAF ו-Google Cloud Armor.

3. יוצרים הערכות לכל הטוקנים ומגדירים את expectedAction כך שיתאים לערך של action שצוין כשמתקינים את מפתחות האתר שמבוססים על ניקוד. במאמר יצירת כלי הערכה מוסבר איך ליצור כלי הערכה.

4. שומרים את כל מזהי ההערכות ומוסיפים הערות להערכות שהופכות לרכישות שמקורן בתרמית או להחזרים כספיים בעקבות ביטול עסקה בתור fraudulent. במאמר הוספת הערות להערכה מוסבר איך להוסיף הערות להערכות.

אסטרטגיה לצמצום הונאות

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

• הטמעה של מודל תגובה ויצירת מבחנים:

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

     בדוגמה הבאה מוצג מודל תגובה לדוגמה:

     • במקרה של סף ניקוד נמוך עד בינוני (0.0 עד 0.5), צריך לאתגר את משתמש הקצה באמצעות אימות רב-שלבי דרך אימייל או SMS.
     • בסף הניקוד הגבוה ביותר (> 0.5), מאפשרים למשתמש הקצה להמשיך בלי אתגר.
     הערה: ערכי הסף של הניקוד עשויים להשתנות בהתאם למשתמשים ולתוקפים. מומלץ להשתמש בלוח הבקרה של ניתוח הנתונים של reCAPTCHA כדי לקבוע את הציונים הטובים ביותר שצריך לפעול לגביהם.
  2. כשיוצרים הערכות, צריך לוודא שהערך של expectedAction זהה לערך של action שציינתם כש התקנתם את מפתחות האתר שמבוססים על ניקוד בדפי האינטרנט. אם הם לא זהים, לא מאשרים את האימות.

• אם משתמשי הקצה משתמשים בדפדפני אינטרנט שבהם JavaScript מושבת, צריך לבצע את הפעולות הבאות:

  1. לחסום את משתמשי הקצה האלה.
  2. מודיעים למשתמשי הקצה שהאתר שלכם דורש JavaScript כדי להמשיך.

• כדי למנוע טעינה של סקריפט Google בדפדפנים של משתמשי קצה שחוסמים אותו, חשוב לוודא שההבטחה של grecaptcha.enterprise.ready מתקיימת. המשמעות היא ש-reCAPTCHA Javascript API נטען באופן מלא ולא נתקל בשגיאה.

• בממשקי API שפועלים רק באינטרנט, מומלץ להעביר את טוקן reCAPTCHA או את תוצאת ההערכה של Fraud Defense אל ה-API של השרת העורפי, ולאחר מכן לאפשר את פעולת ה-API רק אם טוקן reCAPTCHA תקף ועומד בערך סף של ציון. כך מוודאים שהמשתמש לא משתמש ב-API בלי להיכנס לאתר.

המאמרים הבאים

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