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

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

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

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

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

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

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

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

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

Carding

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

פריצה לפרטי כניסה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

משיכת כסף

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

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

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

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

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

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

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

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

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

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

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

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

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

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

יצירת חשבון

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  3. כדאי להטמיע את reCAPTCHA Account Defender כדי לעקוב אחרי מגמות בהתנהגות של משתמשי קצה במהלך הכניסה לחשבון ולקבל אותות נוספים שיכולים להעיד על השתלטות על חשבון (ATO). מידע נוסף על השימוש ב-reCAPTCHA Account Defender זמין במאמר בנושא זיהוי ומניעה של פעילויות תרמיתיות שקשורות לחשבון.

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

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

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

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

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

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

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

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

פריצה לטוקן

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

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

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

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

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

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

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

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

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

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

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

  • כדי לוודא שטוקני 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. שומרים את כל מזהי ההערכה ומסמנים את העסקאות שהיו הונאה.

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

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

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

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

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

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

הטיה

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

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

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

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

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

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

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

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

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

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

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

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

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

גירוד

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

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

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

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

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

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

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

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

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

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

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

התגברות על CAPTCHA

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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