Overview

הערה: המסמך הזה עדיין בתהליך פיתוח. צפויים שיפורים בעתיד הקרוב.

גרסת 5 של 'גלישה בטוחה של Google' היא התפתחות של גרסת 4 של 'גלישה בטוחה של Google'. שני השינויים העיקריים בגרסה 5 הם רענון הנתונים ופרטיות כתובת ה-IP. בנוסף, שיפורים בממשק ה-API הגדילו את הגמישות והיעילות והפחיתו את נפח הקוד. בנוסף, גרסה 5 של הגלישה הבטוחה של Google נועדה להקל על המעבר מגרסה 4.

בשלב זה, Google מציעה גם את הגרסה 4 וגם את הגרסה 5, ושתיהן נחשבות ככשירות לסביבת הייצור. אפשר להשתמש ב-v4 או ב-v5. לא הודענו על תאריך להוצאה משימוש של גרסה 4. אם נודיע על כך, נודיע לפחות שנה מראש. בדף הזה נתאר את הגרסה 5 וגם מדריך להעברה מגרסה 4 לגרסה 5. המסמכים המלאים של גרסה 4 עדיין זמינים.

עדכניות הנתונים

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

פרטיות כתובת ה-IP

במהלך הטיפול בבקשות להצגת תוכן, הגלישה הבטוחה של Google (גרסה 4 או 5) לא מעבדת מידע שמשויך לזהות של משתמש. אם נשלחים קובצי cookie, המערכת מתעלמת מהם. כתובות ה-IP המקוריות של הבקשות ידועות ל-Google, אבל Google משתמשת בכתובות ה-IP רק לצורכי רשת חיוניים (כלומר, לשליחת תשובות) ולמטרות הגנה מפני התקפת מניעת שירות (DoS).

במקביל לגרסה 5, אנחנו משיקים ממשק API נלווה שנקרא Safe Browsing Oblivious HTTP Gateway API. לשם כך, נעשה שימוש ב-Oblivious HTTP כדי להסתיר מ-Google את כתובות ה-IP של משתמשי הקצה. כדי להשתמש ב-SAML, צד שלישי שאינו מעורב בתרמית מטפל בגרסה מוצפנת של בקשת המשתמש, ולאחר מכן מעביר אותה אל Google. לכן לצד השלישי יש גישה רק לכתובות ה-IP, ול-Google יש גישה רק לתוכן הבקשה. הצד השלישי מפעיל ממסר Oblivious HTTP (כמו השירות הזה של Fastly), ו-Google מפעילה את Oblivious HTTP Gateway. זהו ממשק API נלווה אופציונלי. כשמשתמשים בו בשילוב עם 'גלישה בטוחה' של Google, כתובות ה-IP של משתמשי הקצה לא נשלחות יותר אל Google.

מצבי הפעולה

הגרסה החמישית של הגלישה הבטוחה של Google מאפשרת ללקוחות לבחור מתוך שלושה מצבי הפעלה.

מצב 'זמן אמת'

כשלקוחות בוחרים להשתמש בגרסה 5 של 'גלישה בטוחה' של Google במצב 'בזמן אמת', הם שומרים במסד הנתונים המקומי שלהם: (1) מטמון גלובלי של אתרים שסביר להניח שהם לא מזיקים, בפורמט של גיבובי SHA256 של ביטויים של כתובות URL עם סיומת מארח/תחילית נתיב, (2) קבוצה של רשימות איומים, בפורמט של תחיליות גיבוב SHA256 של ביטויים של כתובות URL עם סיומת מארח/תחילית נתיב. הרעיון ברמה גבוהה הוא שבכל פעם שהלקוח רוצה לבדוק כתובת URL מסוימת, מתבצעת בדיקה מקומית באמצעות המטמון הגלובלי. אם הבדיקה הזו עוברת, מתבצעת בדיקה של רשימות איומים מקומיות. אחרת, הלקוח ממשיך לבדיקת הגיבוב בזמן אמת כפי שמתואר בהמשך.

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

בהמשך מופיע מפרט מפורט של התהליך.

מצב רשימה מקומית

כשלקוחות בוחרים להשתמש בגרסה 5 של Google Safe Browsing במצב הזה, התנהגות הלקוח דומה לזו של Update API בגרסה 4, מלבד השימוש בממשק ה-API המשופר של גרסה 5. לקוחות יחזיקו במסד הנתונים המקומי שלהם קבוצה של רשימות איומים בפורמט של קידומות גיבוב SHA256 של ביטויים של כתובות URL עם סיומת מארח/קידומת נתיב. בכל פעם שהלקוח רוצה לבדוק כתובת URL מסוימת, מתבצעת בדיקה באמצעות רשימת האיומים המקומית. אם יש התאמה, הלקוח מתחבר לשרת כדי להמשיך את הבדיקה.

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

מצב זמן אמת ללא אחסון

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

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

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

התהליך של בדיקת כתובות URL בזמן אמת

ההליך הזה משמש כשהלקוח בוחר במצב הפעולה 'זמן אמת'.

התהליך הזה מקבל כתובת URL אחת u ומחזיר את הערכים SAFE, ‏ UNSAFE או UNSURE. אם הפונקציה מחזירה את הערך SAFE, כתובת ה-URL נחשבת בטוחה על ידי הגלישה הבטוחה של Google. אם הפונקציה מחזירה את הערך UNSAFE, מערכת הגלישה הבטוחה של Google מתייחסת לכתובת ה-URL כאל כתובת שעשויה להיות לא בטוחה, וצריך לנקוט פעולה מתאימה: למשל, להציג אזהרה למשתמש הקצה, להעביר הודעה שהתקבלה לתיקיית הספאם או לדרוש מהמשתמש אישור נוסף לפני שהוא ממשיך. אם הפונקציה מחזירה את הערך UNSURE, צריך להשתמש לאחר מכן בתהליך הבדיקה המקומי הבא.

  1. נניח ש-expressions היא רשימה של ביטויים של סיומת/תחילית שנוצרו על ידי כתובת ה-URL u.
  2. נניח ש-expressionHashes היא רשימה, שבה הרכיבים הם גיבובים (hashes) של SHA256 של כל ביטוי ב-expressions.
  3. לכל hash של expressionHashes:
    1. אם אפשר למצוא את hash במטמון הגלובלי, מחזירים את הערך UNSURE.
  4. נניח ש-expressionHashPrefixes היא רשימה, שבה הרכיבים הם 4 הבייטים הראשונים של כל גיבוב ב-expressionHashes.
  5. לכל expressionHashPrefix של expressionHashPrefixes:
    1. מחפשים את expressionHashPrefix במטמון המקומי.
    2. אם המערכת מוצאת את הרשומה ששמורה במטמון:
      1. בודקים אם השעה הנוכחית גדולה משעת התפוגה.
      2. אם הוא גדול יותר:
        1. הסרת הרשומה שנמצאה במטמון מהמטמון המקומי.
        2. ממשיכים את הלולאה.
      3. אם הוא לא גדול יותר:
        1. מסירים את expressionHashPrefix הספציפי הזה מ-expressionHashPrefixes.
        2. בודקים אם הגיבוב המלא התואם ב-expressionHashes נמצא ברשומה ששמורה במטמון.
        3. אם הוא נמצא, מחזירים את הערך UNSAFE.
        4. אם לא נמצא, ממשיכים בלולאה.
    3. אם הרשומה ששמורה במטמון לא נמצאה, ממשיכים בלולאה.
  6. שולחים את expressionHashPrefixes לשרת של הגלישה הבטוחה של Google בגרסה 5 באמצעות RPC SearchHashes או את שיטת ה-REST‏ hashes.search. אם אירעה שגיאה (כולל שגיאות רשת, שגיאות HTTP וכו'), מחזירים את הערך UNSURE. אחרת, התגובה היא response שהתקבלה משרת SB, שהיא רשימה של גיבובי hash מלאים יחד עם מידע משני שמזהה את אופי האיום (הנדסה חברתית, תוכנה זדונית וכו'), וגם את זמן התפוגה של המטמון expiration.
  7. לכל fullHash של response:
    1. הוספת fullHash למטמון המקומי, יחד עם expiration.
  8. לכל fullHash של response:
    1. נניח ש-isFound היא התוצאה של מציאת fullHash ב-expressionHashes.
    2. אם הערך של isFound הוא False, ממשיכים בלולאה.
    3. אם הערך של isFound הוא True, מחזירים את הערך UNSAFE.
  9. חזרה ב-SAFE.

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

ההליך לבדיקת כתובות URL ברשימת LocalThreat

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

התהליך הזה מקבל כתובת URL אחת u ומחזיר את הערך SAFE או UNSAFE.

  1. נניח ש-expressions היא רשימה של ביטויים של סיומת/תחילית שנוצרו על ידי כתובת ה-URL u.
  2. נניח ש-expressionHashes היא רשימה, שבה הרכיבים הם גיבובים (hashes) של SHA256 של כל ביטוי ב-expressions.
  3. נניח ש-expressionHashPrefixes היא רשימה, שבה הרכיבים הם 4 הבייטים הראשונים של כל גיבוב ב-expressionHashes.
  4. לכל expressionHashPrefix של expressionHashPrefixes:
    1. מחפשים את expressionHashPrefix במטמון המקומי.
    2. אם המערכת מוצאת את הרשומה ששמורה במטמון:
      1. בודקים אם השעה הנוכחית גדולה משעת התפוגה.
      2. אם הוא גדול יותר:
        1. הסרת הרשומה שנמצאה במטמון מהמטמון המקומי.
        2. ממשיכים את הלולאה.
      3. אם הוא לא גדול יותר:
        1. מסירים את expressionHashPrefix הספציפי הזה מ-expressionHashPrefixes.
        2. בודקים אם הגיבוב המלא התואם ב-expressionHashes נמצא ברשומה ששמורה במטמון.
        3. אם הוא נמצא, מחזירים את הערך UNSAFE.
        4. אם לא נמצא, ממשיכים בלולאה.
    3. אם הרשומה ששמורה במטמון לא נמצאה, ממשיכים בלולאה.
  5. לכל expressionHashPrefix של expressionHashPrefixes:
    1. מחפשים את expressionHashPrefix במסד הנתונים המקומי של רשימת האיומים.
    2. אם לא ניתן למצוא את expressionHashPrefix במסד הנתונים של רשימת האיומים המקומית, מסירים אותו מ-expressionHashPrefixes.
  6. שולחים את expressionHashPrefixes לשרת של הגלישה הבטוחה של Google בגרסה 5 באמצעות RPC SearchHashes או את שיטת ה-REST‏ hashes.search. אם אירעה שגיאה (כולל שגיאות רשת, שגיאות HTTP וכו'), מחזירים את הערך SAFE. אחרת, התגובה היא response שהתקבלה משרת SB, שהיא רשימה של גיבובי hash מלאים יחד עם מידע משני שמזהה את אופי האיום (הנדסה חברתית, תוכנה זדונית וכו'), וגם את זמן התפוגה של המטמון expiration.
  7. לכל fullHash של response:
    1. הוספת fullHash למטמון המקומי, יחד עם expiration.
  8. לכל fullHash של response:
    1. נניח ש-isFound היא התוצאה של מציאת fullHash ב-expressionHashes.
    2. אם הערך של isFound הוא False, ממשיכים בלולאה.
    3. אם הערך של isFound הוא True, מחזירים את הערך UNSAFE.
  9. חזרה ב-SAFE.

התהליך של בדיקת כתובות URL בזמן אמת ללא מסד נתונים מקומי

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

התהליך הזה מקבל כתובת URL אחת u ומחזיר את הערך SAFE או UNSAFE.

  1. נניח ש-expressions היא רשימה של ביטויים של סיומת/תחילית שנוצרו על ידי כתובת ה-URL u.
  2. נניח ש-expressionHashes היא רשימה, שבה הרכיבים הם גיבובים (hashes) של SHA256 של כל ביטוי ב-expressions.
  3. נניח ש-expressionHashPrefixes היא רשימה, שבה הרכיבים הם 4 הבייטים הראשונים של כל גיבוב ב-expressionHashes.
  4. לכל expressionHashPrefix של expressionHashPrefixes:
    1. מחפשים את expressionHashPrefix במטמון המקומי.
    2. אם המערכת מוצאת את הרשומה ששמורה במטמון:
      1. בודקים אם השעה הנוכחית גדולה משעת התפוגה.
      2. אם הוא גדול יותר:
        1. הסרת הרשומה שנמצאה במטמון מהמטמון המקומי.
        2. ממשיכים את הלולאה.
      3. אם הוא לא גדול יותר:
        1. מסירים את expressionHashPrefix הספציפי הזה מ-expressionHashPrefixes.
        2. בודקים אם הגיבוב המלא התואם ב-expressionHashes נמצא ברשומה ששמורה במטמון.
        3. אם הוא נמצא, מחזירים את הערך UNSAFE.
        4. אם לא נמצא, ממשיכים בלולאה.
    3. אם הרשומה ששמורה במטמון לא נמצאה, ממשיכים בלולאה.
  5. שולחים את expressionHashPrefixes לשרת של הגלישה הבטוחה של Google בגרסה 5 באמצעות RPC SearchHashes או באמצעות שיטת ה-REST‏ hashes.search. אם אירעה שגיאה (כולל שגיאות רשת, שגיאות HTTP וכו'), מחזירים את הערך SAFE. אחרת, התגובה היא response שהתקבלה משרת SB, שהיא רשימה של גיבובי hash מלאים יחד עם מידע משני שמזהה את אופי האיום (הנדסה חברתית, תוכנה זדונית וכו'), וגם את זמן התפוגה של המטמון expiration.
  6. לכל fullHash של response:
    1. הוספת fullHash למטמון המקומי, יחד עם expiration.
  7. לכל fullHash של response:
    1. נניח ש-isFound היא התוצאה של מציאת fullHash ב-expressionHashes.
    2. אם הערך של isFound הוא False, ממשיכים בלולאה.
    3. אם הערך של isFound הוא True, מחזירים את הערך UNSAFE.
  8. חזרה ב-SAFE.

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

בקשות לדוגמה

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

לפניכם דוגמה לבקשת HTTP באמצעות השיטה hashes.search:

GET https://safebrowsing.googleapis.com/v5/hashes:search?key=INSERT_YOUR_API_KEY_HERE&hashPrefixes=WwuJdQ

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

לפניכם דוגמה לבקשת HTTP באמצעות השיטה hashLists.batchGet:

GET https://safebrowsing.googleapis.com/v5alpha1/hashLists:batchGet?key=INSERT_YOUR_API_KEY_HERE&names=se&names=mw-4b

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