הערה: המסמך הזה עדיין בתהליך פיתוח. צפויים שיפורים בעתיד הקרוב.
גרסת 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
, צריך להשתמש לאחר מכן בתהליך הבדיקה המקומי הבא.
- נניח ש-
expressions
היא רשימה של ביטויים של סיומת/תחילית שנוצרו על ידי כתובת ה-URLu
. - נניח ש-
expressionHashes
היא רשימה, שבה הרכיבים הם גיבובים (hashes) של SHA256 של כל ביטוי ב-expressions
. - לכל
hash
שלexpressionHashes
:- אם אפשר למצוא את
hash
במטמון הגלובלי, מחזירים את הערךUNSURE
.
- אם אפשר למצוא את
- נניח ש-
expressionHashPrefixes
היא רשימה, שבה הרכיבים הם 4 הבייטים הראשונים של כל גיבוב ב-expressionHashes
. - לכל
expressionHashPrefix
שלexpressionHashPrefixes
:- מחפשים את
expressionHashPrefix
במטמון המקומי. - אם המערכת מוצאת את הרשומה ששמורה במטמון:
- בודקים אם השעה הנוכחית גדולה משעת התפוגה.
- אם הוא גדול יותר:
- הסרת הרשומה שנמצאה במטמון מהמטמון המקומי.
- ממשיכים את הלולאה.
- אם הוא לא גדול יותר:
- מסירים את
expressionHashPrefix
הספציפי הזה מ-expressionHashPrefixes
. - בודקים אם הגיבוב המלא התואם ב-
expressionHashes
נמצא ברשומה ששמורה במטמון. - אם הוא נמצא, מחזירים את הערך
UNSAFE
. - אם לא נמצא, ממשיכים בלולאה.
- מסירים את
- אם הרשומה ששמורה במטמון לא נמצאה, ממשיכים בלולאה.
- מחפשים את
- שולחים את
expressionHashPrefixes
לשרת של הגלישה הבטוחה של Google בגרסה 5 באמצעות RPC SearchHashes או את שיטת ה-REST hashes.search. אם אירעה שגיאה (כולל שגיאות רשת, שגיאות HTTP וכו'), מחזירים את הערךUNSURE
. אחרת, התגובה היאresponse
שהתקבלה משרת SB, שהיא רשימה של גיבובי hash מלאים יחד עם מידע משני שמזהה את אופי האיום (הנדסה חברתית, תוכנה זדונית וכו'), וגם את זמן התפוגה של המטמוןexpiration
. - לכל
fullHash
שלresponse
:- הוספת
fullHash
למטמון המקומי, יחד עםexpiration
.
- הוספת
- לכל
fullHash
שלresponse
:- נניח ש-
isFound
היא התוצאה של מציאתfullHash
ב-expressionHashes
. - אם הערך של
isFound
הוא False, ממשיכים בלולאה. - אם הערך של
isFound
הוא True, מחזירים את הערךUNSAFE
.
- נניח ש-
- חזרה ב-
SAFE
.
הפרוטוקול הזה מציין מתי הלקוח שולח את expressionHashPrefixes
לשרת, אבל הוא לא מציין במדויק איך לשלוח אותם. לדוגמה, מותר לשולח לשלוח את כל הערכים של expressionHashPrefixes
בבקשה אחת, וגם מותר לשולח לשלוח כל קידומת בנפרד ב-expressionHashPrefixes
לשרת בבקשות נפרדות (אולי במקביל). מותר גם ללקוח לשלוח קידומות גיבוב לא קשורות או שנוצרו באופן אקראי יחד עם קידומות הגיבוב ב-expressionHashPrefixes
, כל עוד מספר קידומות הגיבוב שנשלחות בבקשה אחת לא חורג מ-30.
ההליך לבדיקת כתובות URL ברשימת LocalThreat
ההליך הזה משמש כשהלקוח בוחר במצב הפעולה של רשימה מקומית. הוא משמש גם כשהלקוח מקבל את הערך UNSURE
מהפרוצדורה RealTimeCheck שמפורטת למעלה.
התהליך הזה מקבל כתובת URL אחת u
ומחזיר את הערך SAFE
או UNSAFE
.
- נניח ש-
expressions
היא רשימה של ביטויים של סיומת/תחילית שנוצרו על ידי כתובת ה-URLu
. - נניח ש-
expressionHashes
היא רשימה, שבה הרכיבים הם גיבובים (hashes) של SHA256 של כל ביטוי ב-expressions
. - נניח ש-
expressionHashPrefixes
היא רשימה, שבה הרכיבים הם 4 הבייטים הראשונים של כל גיבוב ב-expressionHashes
. - לכל
expressionHashPrefix
שלexpressionHashPrefixes
:- מחפשים את
expressionHashPrefix
במטמון המקומי. - אם המערכת מוצאת את הרשומה ששמורה במטמון:
- בודקים אם השעה הנוכחית גדולה משעת התפוגה.
- אם הוא גדול יותר:
- הסרת הרשומה שנמצאה במטמון מהמטמון המקומי.
- ממשיכים את הלולאה.
- אם הוא לא גדול יותר:
- מסירים את
expressionHashPrefix
הספציפי הזה מ-expressionHashPrefixes
. - בודקים אם הגיבוב המלא התואם ב-
expressionHashes
נמצא ברשומה ששמורה במטמון. - אם הוא נמצא, מחזירים את הערך
UNSAFE
. - אם לא נמצא, ממשיכים בלולאה.
- מסירים את
- אם הרשומה ששמורה במטמון לא נמצאה, ממשיכים בלולאה.
- מחפשים את
- לכל
expressionHashPrefix
שלexpressionHashPrefixes
:- מחפשים את
expressionHashPrefix
במסד הנתונים המקומי של רשימת האיומים. - אם לא ניתן למצוא את
expressionHashPrefix
במסד הנתונים של רשימת האיומים המקומית, מסירים אותו מ-expressionHashPrefixes
.
- מחפשים את
- שולחים את
expressionHashPrefixes
לשרת של הגלישה הבטוחה של Google בגרסה 5 באמצעות RPC SearchHashes או את שיטת ה-REST hashes.search. אם אירעה שגיאה (כולל שגיאות רשת, שגיאות HTTP וכו'), מחזירים את הערךSAFE
. אחרת, התגובה היאresponse
שהתקבלה משרת SB, שהיא רשימה של גיבובי hash מלאים יחד עם מידע משני שמזהה את אופי האיום (הנדסה חברתית, תוכנה זדונית וכו'), וגם את זמן התפוגה של המטמוןexpiration
. - לכל
fullHash
שלresponse
:- הוספת
fullHash
למטמון המקומי, יחד עםexpiration
.
- הוספת
- לכל
fullHash
שלresponse
:- נניח ש-
isFound
היא התוצאה של מציאתfullHash
ב-expressionHashes
. - אם הערך של
isFound
הוא False, ממשיכים בלולאה. - אם הערך של
isFound
הוא True, מחזירים את הערךUNSAFE
.
- נניח ש-
- חזרה ב-
SAFE
.
התהליך של בדיקת כתובות URL בזמן אמת ללא מסד נתונים מקומי
ההליך הזה משמש כשהלקוח בוחר במצב הפעולה 'פעולה בזמן אמת ללא אחסון'.
התהליך הזה מקבל כתובת URL אחת u
ומחזיר את הערך SAFE
או UNSAFE
.
- נניח ש-
expressions
היא רשימה של ביטויים של סיומת/תחילית שנוצרו על ידי כתובת ה-URLu
. - נניח ש-
expressionHashes
היא רשימה, שבה הרכיבים הם גיבובים (hashes) של SHA256 של כל ביטוי ב-expressions
. - נניח ש-
expressionHashPrefixes
היא רשימה, שבה הרכיבים הם 4 הבייטים הראשונים של כל גיבוב ב-expressionHashes
. - לכל
expressionHashPrefix
שלexpressionHashPrefixes
:- מחפשים את
expressionHashPrefix
במטמון המקומי. - אם המערכת מוצאת את הרשומה ששמורה במטמון:
- בודקים אם השעה הנוכחית גדולה משעת התפוגה.
- אם הוא גדול יותר:
- הסרת הרשומה שנמצאה במטמון מהמטמון המקומי.
- ממשיכים את הלולאה.
- אם הוא לא גדול יותר:
- מסירים את
expressionHashPrefix
הספציפי הזה מ-expressionHashPrefixes
. - בודקים אם הגיבוב המלא התואם ב-
expressionHashes
נמצא ברשומה ששמורה במטמון. - אם הוא נמצא, מחזירים את הערך
UNSAFE
. - אם לא נמצא, ממשיכים בלולאה.
- מסירים את
- אם הרשומה ששמורה במטמון לא נמצאה, ממשיכים בלולאה.
- מחפשים את
- שולחים את
expressionHashPrefixes
לשרת של הגלישה הבטוחה של Google בגרסה 5 באמצעות RPC SearchHashes או באמצעות שיטת ה-REST hashes.search. אם אירעה שגיאה (כולל שגיאות רשת, שגיאות HTTP וכו'), מחזירים את הערךSAFE
. אחרת, התגובה היאresponse
שהתקבלה משרת SB, שהיא רשימה של גיבובי hash מלאים יחד עם מידע משני שמזהה את אופי האיום (הנדסה חברתית, תוכנה זדונית וכו'), וגם את זמן התפוגה של המטמוןexpiration
. - לכל
fullHash
שלresponse
:- הוספת
fullHash
למטמון המקומי, יחד עםexpiration
.
- הוספת
- לכל
fullHash
שלresponse
:- נניח ש-
isFound
היא התוצאה של מציאתfullHash
ב-expressionHashes
. - אם הערך של
isFound
הוא False, ממשיכים בלולאה. - אם הערך של
isFound
הוא True, מחזירים את הערךUNSAFE
.
- נניח ש-
- חזרה ב-
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
גוף התשובה הוא שוב עומס שימושי בפורמט של מאגר פרוטוקול, שאפשר לפענח לאחר מכן.