Overview

מבוא

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

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

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

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

אחד השיפורים המשמעותיים בגרסה 5 של הגלישה הבטוחה של Google בהשוואה לגרסה 4 (ספציפית, ה-v4 Update API) הוא עדכניות הנתונים והכיסוי שלהם. ההגנה תלויה מאוד במסד הנתונים המקומי המתחזק על ידי הלקוח, ולכן העיכוב והגודל של עדכון מסד הנתונים המקומי הם הגורם העיקרי להחמצת ההגנה. בגרסה 4, ללקוח הטיפוסי נדרשות 20 עד 50 דקות כדי להשיג את הגרסה העדכנית ביותר של רשימות האיומים. לצערנו, התקפות הפישינג מתפשטות במהירות: נכון לשנת 2021, 60% מהאתרים שמעבירים התקפות פועלים רק במשך פחות מ-10 דקות. לפי הניתוח שלנו, כ-25-30% מההגנה מפני פישינג נובעת מחוסר פעילות של הנתונים. בנוסף, מכשירים מסוימים לא מכילים את כל רשימות האיומים של הגלישה הבטוחה של Google, והן מתרחבות עם הזמן.

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

פרטיות IP

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

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

שימוש הולם

שימוש מותר

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

תמחור

כל ממשקי ה-API לגלישה בטוחה של Google מוצעים בחינם.

מכסות

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

כתובות URL מתאימות

הגלישה הבטוחה של Google נועדה לפעול בכתובות URL שיוצגו בסרגל הכתובות של הדפדפן. הוא לא מיועד לבדיקה מול משאבי משנה (כמו JavaScript או תמונה שקובץ HTML מפנה אליו או כתובת URL של WebSocket ביוזמת JavaScript). אין לבדוק כתובות URL כאלה של משאבי משנה מול הגלישה הבטוחה של Google.

אם כניסה לכתובת URL מובילה להפניה אוטומטית (למשל HTTP 301), מתאים לבדוק את כתובת ה-URL שמפנה לכתובת אחרת מול הגלישה הבטוחה של Google. מניפולציה של כתובות URL בצד הלקוח, כמו History.pushState, לא מובילה לבדיקת כתובות URL חדשות מול הגלישה הבטוחה של Google.

אזהרות משתמשים

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

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

• באזהרה המוצגת למשתמשים, אסור לגרום למשתמשים לחשוב שהדף המדובר הוא, ללא ספק, משאב אינטרנט לא בטוח. כשאתם מתייחסים לדף שזוהה או לסיכונים הפוטנציאליים שהוא עלול להוות עבור המשתמשים, עליכם לסווג את האזהרה באמצעות מונחים כמו: חשד, פוטנציאלי, אפשרי, עשוי להיות.
• האזהרה צריכה לאפשר למשתמש לקבל מידע נוסף דרך ההגדרה של Google לאיומים שונים. מוצעים הקישורים הבאים:
  • הנדסה חברתית: https://developers.google.com/search/docs/monitor-debug/security/social-engineering
  • תוכנות זדוניות ותוכנות לא רצויות: https://developers.google.com/search/docs/monitor-debug/security/malware
  • אפליקציות שעלולות להזיק (ל-Android בלבד): https://developers.google.com/android/play-protect/potentially-harmful-applications
• כשמציגים אזהרות לגבי דפים שזוהו על ידי שירות הגלישה הבטוחה כמסוכנים, צריך לשייך את Google ל-Google. לשם כך, צריך לכלול את השורה "האזהרה שסופקה על ידי Google" וקישור לאזהרה לגבי הגלישה הבטוחה. אם במוצר שלכם מוצגות גם אזהרות על סמך מקורות אחרים, אסור לכלול את השיוך של Google באזהרות שנגזרות מנתונים שאינם של Google.

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

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

דרכי הפעולה

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

מצב 'זמן אמת'

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

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

בהמשך תוכלו למצוא תיאור מפורט של ההליך.

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

כשלקוחות בוחרים להשתמש בגלישה הבטוחה של Google בגרסה 5 במצב הזה, התנהגות הלקוח דומה ל-v4 Update API, למעט שימוש ב-API משופר בגרסה 5. הלקוחות יתחזקו במסד הנתונים המקומי קבוצה של רשימות איומים בפורמט של קידומות גיבוב (hash) מסוג SHA256 של ביטויי כתובת URL מסוג host-suffix/path-prefix. בכל פעם שהלקוח רוצה לבדוק כתובת URL מסוימת, הבדיקה מתבצעת באמצעות רשימת האיומים המקומיים. אם ורק אם יש התאמה, הלקוח מתחבר לשרת כדי להמשיך בבדיקה.

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

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

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

כתובות ה-URL בבדיקה

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

קנוניזציה של כתובות URL

לפני הבדיקה של כתובות URL, הלקוח מצופה לבצע קנוניזציה בכתובת ה-URL הזו.

ראשית, נניח שהלקוח ניתח את כתובת ה-URL והפך אותה לחוקית בהתאם לתקן RFC 2396. אם בכתובת ה-URL נעשה שימוש בשם דומיין בינלאומי (IDN), הלקוח צריך להמיר את כתובת ה-URL לייצוג ASCII Tunycode. כתובת ה-URL חייבת לכלול רכיב נתיב. כלומר, חייב להיות לה לפחות לוכסן אחד אחרי הדומיין (http://google.com/ במקום http://google.com).

תחילה, מסירים מכתובת ה-URL את תווי Tab (0x09), CR (0x0d) ו-LF (0x0a). אין להסיר רצפי escape לתווים האלה (למשל %0a).

שנית, אם כתובת ה-URL מסתיימת במקטע, מסירים את המקטע. לדוגמה, יש לקצר את http://google.com/#frag ל-http://google.com/.

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

כדי להגדיר את שם המארח כקנוני:

מחלצים את שם המארח מכתובת ה-URL ואז:

1. מסירים את כל הנקודות בהתחלה ובסוף.
2. מחליפים נקודות עוקבות בנקודה אחת.
3. אם ניתן לנתח את שם המארח ככתובת IPv4, צריך לנרמל אותו ל-4 ערכים עשרוניים שמופרדים באמצעות נקודות. הלקוח צריך לטפל בכל קידוד חוקי של כתובת IP, כולל קידוד אוקטלי, הקסדצימלי ופחות מארבעה רכיבים.
4. אם אפשר לנתח את שם המארח ככתובת IPv6 בסוגריים, צריך לנרמל אותו על ידי הסרת אפסים מובילים מיותרים מהרכיבים וכיווץ רכיבי אפס באמצעות תחביר של נקודתיים כפולות. לדוגמה, צריך להמיר את [2001:0db8:0000::1] ל-[2001:db8::1]. אם שם המארח הוא אחד משני הסוגים המיוחדים הבאים של כתובות IPv6, ממירים אותם ל-IPv4:
   • כתובת IPv6 שממופה באמצעות IPv4, כמו [::ffff:1.2.3.4], וצריך להמיר אותה ל-1.2.3.4.
   • כתובת NAT64 עם הקידומת הידועה 64:ff9b::/96, לדוגמה: [64:ff9b::1.2.3.4], שיש להמיר אותה ל-1.2.3.4.
5. יש להקטין את כל המחרוזת באותיות קטנות.

כדי לקבוע כתובת URL כגרסה הרשמית (הקנונית):

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

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

בכתובת ה-URL, צריך לסמן את כל התווים <= ASCII 32 , >= 127 , # או %. תווי המילוט צריכים להיות באותיות הקסדצימליות רישיות.

ביטויים של קידומת נתיב של מארח וסיומת

לאחר שכתובת ה-URL הופכת לקנונית, השלב הבא הוא יצירת ביטויי הסיומת/קידומת. כל ביטוי סיומת/קידומת מורכב מסיומת מארח (או מארח מלא) ומקידומת נתיב (או נתיב מלא).

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

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

• אם שם המארח הוא לא ליטרל של IPv4 או IPv6, יש עד ארבעה שמות מארחים שנוצרו על ידי התחלה של הדומיין eTLD+1 והוספת רכיבים מובילים עוקבים. הקביעה של eTLD+1 צריכה להתבסס על רשימת הסיומות הציבוריות. למשל, a.b.example.com יוביל לדומיין eTLD+1 של example.com, וגם למארח עם רכיב מארח אחד נוסף, b.example.com.
• שם המארח המדויק בכתובת ה-URL. בהמשך לדוגמה הקודמת, המערכת תסמן את a.b.example.com.

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

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

הדוגמאות הבאות ממחישות את התנהגות הבדיקה:

עבור כתובת ה-URL http://a.b.com/1/2.html?param=1, הלקוח ינסה את המחרוזות האפשריות הבאות:

a.b.com/1/2.html?param=1
a.b.com/1/2.html
a.b.com/
a.b.com/1/
b.com/1/2.html?param=1
b.com/1/2.html
b.com/
b.com/1/

עבור כתובת ה-URL http://a.b.c.d.e.f.com/1.html, הלקוח ינסה את המחרוזות האפשריות הבאות:

a.b.c.d.e.f.com/1.html
a.b.c.d.e.f.com/
c.d.e.f.com/1.html
c.d.e.f.com/
d.e.f.com/1.html
d.e.f.com/
e.f.com/1.html
e.f.com/
f.com/1.html
f.com/

(הערה: אפשר לדלג על b.c.d.e.f.com, כי אנחנו נביא רק את חמשת הרכיבים האחרונים של שם המארח ואת שם המארח המלא).

עבור כתובת ה-URL http://1.2.3.4/1/, הלקוח ינסה את המחרוזות האפשריות הבאות:

1.2.3.4/1/
1.2.3.4/

עבור כתובת ה-URL http://example.co.uk/1, הלקוח ינסה את המחרוזות האפשריות הבאות:

example.co.uk/1
example.co.uk/

גיבוב

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

בהתאם לנסיבות, הגיבוב המלא בגודל 32 בייטים ייחתך ל-4 בייטים, ל-8 בייטים או ל-16 בייטים:

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

• כשמורידים את הרשימות למסד הנתונים המקומי באמצעות השיטה hashList.get או באמצעות hashLists.batchGet, אורך הגיבובים שנשלחים על ידי השרת מושפע מאופי הרשימה וגם מההעדפה של הלקוח לגבי אורך הגיבוב, כפי שמפורט בפרמטר desired_hash_length.

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

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

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

1. אפשר להגדיר את expressions כרשימה של ביטויי סיומת/קידומת שנוצרה על ידי כתובת ה-URL u.
2. מגדירים את expressionHashes כרשימה, שבה הרכיבים הם גיבובי 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, שהיא רשימה של גיבובים מלאים יחד עם מידע עזר שמזהה את אופי האיום (הנדסה חברתית, תוכנות זדוניות וכו'), וגם את זמן התפוגה של המטמון expiration.
7. לכל fullHash של response:
   1. מוסיפים את fullHash למטמון המקומי, יחד עם expiration.
8. לכל fullHash של response:
   1. הפונקציה isFound תהיה התוצאה של מציאת fullHash בexpressionHashes.
   2. אם isFound מוגדר כ-False, ממשיכים עם הלולאה.
   3. אם isFound הוא True, יש להחזיר UNSAFE.
9. חזרה ב-SAFE.

ההליך של בדיקת כתובת ה-URL של רשימת איומים מקומיים

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

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

1. אפשר להגדיר את expressions כרשימה של ביטויי סיומת/קידומת שנוצרה על ידי כתובת ה-URL u.
2. מגדירים את expressionHashes כרשימה, שבה הרכיבים הם גיבובי 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, שהיא רשימה של גיבובים מלאים יחד עם מידע עזר שמזהה את אופי האיום (הנדסה חברתית, תוכנות זדוניות וכו'), וגם את זמן התפוגה של המטמון 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 כרשימה, שבה הרכיבים הם גיבובי 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, שהיא רשימה של גיבובים מלאים יחד עם מידע עזר שמזהה את אופי האיום (הנדסה חברתית, תוכנות זדוניות וכו'), וגם את זמן התפוגה של המטמון expiration.
6. לכל fullHash של response:
   1. מוסיפים את fullHash למטמון המקומי, יחד עם expiration.
7. לכל fullHash של response:
   1. הפונקציה isFound תהיה התוצאה של מציאת fullHash בexpressionHashes.
   2. אם isFound מוגדר כ-False, ממשיכים עם הלולאה.
   3. אם isFound הוא True, יש להחזיר UNSAFE.
8. חזרה ב-SAFE.

תחזוקה מקומית של מסדי נתונים

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

עדכונים לגבי מסד הנתונים

הלקוח יקרא באופן קבוע ל-method hashList.get או ל-hashLists.batchGet את פעולת העדכון של מסד הנתונים. מאחר שהלקוח הטיפוסי ירצה לעדכן מספר רשימות בו-זמנית, מומלץ להשתמש בשיטת hashLists.batchGet.

הרשימות מזוהות לפי השמות הייחודיים שלהן. השמות הם מחרוזות ASCII קצרות שאורכן כמה תווים.

בשונה מ-V4, שבו רשימות מזוהות לפי הצירוף של סוגי האיום, סוג הפלטפורמה וסוג הרשומה של האיום, ברשימות של v5 פשוט מזוהות לפי השם. התכונה הזו מספקת גמישות במקרים שבהם אפשר לשייך את אותו סוג של איומים למספר רשימות ב-V5. סוגי הפלטפורמות וסוגי ההזנה של האיומים יוסרו בגרסה 5.

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

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

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

פענוח תוכן הרשימה

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

הגרסה 5 של הגלישה הבטוחה של Google כוללת ארבעה סוגים שונים לטיפול בנתונים בגודל 4 בייטים, נתונים בגודל 8 בייטים, נתונים של 16 בייטים ו-32 בייטים. נבחן דוגמה שבה מקודדים שלושה מספרים שלמים עוקבים של 4 בייט. לפרמטר Rice, המצוין ב-k, להיות 3. החלק המנה של הקידוד הוא פשוט ערך ההבדל הצמוד שמזיז ימינה ב-k ביטים. מכיוון שמספרים שלמים נתונים עוקבים, ההפרש הקרוב שלהם הוא 1, ולאחר החלפה ב-3 ביטים, החלק המנה הוא אפס. ה-K ביטים הכי פחות משמעותיים הם 001. המנה של אפס מקודדת כביט יחיד של 0. השארית היא 1 ומקודדת כ-100. הפעולה הזו חוזרת על עצמה שוב כדי ליצור את ערך ה-bitstream 01000100. ה-bitstream שמתקבל מקודד באמצעות סיומת אנדית קטנה כ-00100010. לכן היא תואמת לנתונים הבאים:

rice_parameter: 3
entries_count: 2
encoded_data: "\x22"

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

רשימות זמינות

בגרסה v5alpha1 מומלץ להשתמש ברשימות הבאות:

שם הרשימה	ערכים תואמים v4 ThreatType	תיאור
gc	אין	הרשימה הזו היא רשימה של מטמון גלובלי. זוהי רשימה מיוחדת שנעשה בה שימוש רק במצב פעילות בזמן אמת.
se	SOCIAL_ENGINEERING	רשימה זו מכילה איומים מסוג SOCIAL_IMPORTERING.
mw	MALWARE	רשימה זו כוללת איומים מסוג MALWARE לפלטפורמות של מחשבים.
uws	UNWANTED_SOFTWARE	רשימה זו מכילה איומים מסוג UNWANTED_SOFTWARE עבור פלטפורמות למחשבים שולחניים.
uwsa	UNWANTED_SOFTWARE	רשימה זו מכילה איומים מסוג UNWANTED_SOFTWARE עבור פלטפורמות Android.
pha	POTENTIALLY_HARMFUL_APPLICATION	רשימה זו כוללת איומים מסוג POTENTIALLY_HARMFUL_APPLICATION עבור פלטפורמות Android.

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

תדירות עדכון

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

בקשות לדוגמה

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

הנה דוגמה לבקשת HTTP באמצעות hashes.search:

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

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

זוהי דוגמה לבקשת HTTP באמצעות hashLists.batchGet:

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

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

מדריך להעברת נתונים (מיגרציה)

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

מתבצעת המרה של עדכוני הרשימה

בגרסה 4, יש להשתמש בשיטת threatListUpdates.fetch כדי להוריד רשימות. בגרסה 5, אחד מהם יעבור לשיטה hashLists.batchGet.

יש לבצע בבקשה את השינויים הבאים:

1. מסירים לגמרי את האובייקט v4 ClientInfo. במקום לספק זיהוי של לקוח באמצעות שדה ייעודי, פשוט משתמשים בכותרת סוכן המשתמש המוכרת. אמנם אין פורמט מוגדר מראש לציון זיהוי הלקוח בכותרת זו, אך מומלץ פשוט לכלול את מזהה הלקוח המקורי ואת גרסת הלקוח ולהפריד ביניהם באמצעות תו רווח או תו לוכסן.
2. לכל אובייקט ListUpdateRequest בגרסה 4:
   • יש לחפש את השם של רשימת גרסה 5 המתאימה בטבלה שלמעלה ולציין את השם הזה בבקשה של גרסה 5.
   • מסירים שדות לא נחוצים כמו threat_entry_type או platform_type.
   • השדה state בגרסה 4 תואם ישירות לשדה versions בגרסה 5. ניתן פשוט לשלוח את אותה מחרוזת בייטים שתישלח לשרת באמצעות השדה state בגרסה 4 באמצעות השדה versions.
   • עבור האילוצים של v4, v5 משתמשת בגרסה פשוטה יותר שנקראת SizeConstraints. צריך להסיר שדות נוספים כמו region.

יש לבצע את השינויים הבאים בתגובה:

1. הערך enum ResponseType של גרסה 4 מוחלף בשדה בוליאני בשם partial_update.
2. עכשיו אפשר להשאיר את השדה minimum_wait_duration אפס או להשמיט אותו. במקרה כזה, הלקוח יתבקש להגיש בקשה נוספת באופן מיידי. זה קורה רק כאשר הלקוח מציין ב-SizeConstraints מגבלה קטנה יותר על גודל העדכון המקסימלי מהגודל המקסימלי של מסד הנתונים.
3. תצטרכו להתאים את אלגוריתם פענוח הקוד של אורז למספרים שלמים ב-32-ביט. ההבדל הוא שהנתונים המקודדים מקודדים עם סיומת שונה. בגרסאות v4 וגם v5, קידומות גיבוב של 32 ביט ממוינות באופן מבחינה לקסיקוגרפית. לעומת זאת, ב-v4 הקידומות האלה נחשבות לסיומות אנדיות קטנות כשהן ממוינות, ואילו ב-v5 הקידומות האלה נחשבות לסיומות גדולות כשממוינות להן. כלומר, הלקוח לא צריך לבצע מיון כלשהו, מכיוון שמיון מילולי זהה למיון מספרי עם אותיות גדולות של קצה. כאן אפשר למצוא דוגמה מהסוג הזה בהטמעת Chromium בגרסה 4. אפשר להסיר מיון כזה.
4. צריך להטמיע את אלגוריתם פענוח הקוד של Rice באורכי גיבוב אחרים.

המרה של חיפושי גיבוב (hash)

בגרסה 4, צריך להשתמש בשיטה fullHashes.find כדי לקבל גיבובים מלאים. השיטה המקבילה בגרסה 5 היא השיטה hashes.search.

יש לבצע בבקשה את השינויים הבאים:

1. מומלץ לבנות את הקוד כך שישלח רק קידומות גיבוב באורך של 4 בייטים בדיוק.
2. מסירים לגמרי את האובייקטים של ClientInfo בגרסה 4. במקום לספק זיהוי של לקוח באמצעות שדה ייעודי, פשוט משתמשים בכותרת סוכן המשתמש המוכרת. אמנם אין פורמט מוגדר מראש לציון זיהוי הלקוח בכותרת זו, אך מומלץ פשוט לכלול את מזהה הלקוח המקורי ואת גרסת הלקוח ולהפריד ביניהם באמצעות תו רווח או תו לוכסן.
3. צריך להסיר את השדה client_states. הוא לא נחוץ יותר.
4. כבר אין צורך לכלול בו threat_types ושדות דומים.

יש לבצע את השינויים הבאים בתגובה:

1. השדה minimum_wait_duration הוסר. הלקוח תמיד יכול לשלוח בקשה חדשה לפי הצורך.
2. האובייקט v4 ThreatMatch הופשט לאובייקט FullHash.
3. השמירה במטמון פושטה למשך זמן מטמון אחד. עיין בתהליכים שלמעלה לגבי אינטראקציה עם המטמון.