Migration From V4

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

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

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

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

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

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

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

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

1. ה-enum ResponseType בגרסה 4 פשוט מוחלף בשדה בוליאני בשם partial_update.
2. השדה minimum_wait_duration יכול להיות עכשיו אפס או מושמט. אם כן, הלקוח מתבקש לשלוח בקשה נוספת באופן מיידי. זה קורה רק כשהלקוח מציין ב-SizeConstraints מגבלה קטנה יותר על גודל העדכון המקסימלי מאשר גודל מסד הנתונים המקסימלי.
3. הלוגיקה לפענוח של גיבובים מקודדים בשיטת Rice-Golomb דורשת שני שינויים עיקריים:
   • סדר בתים (Endianness) ומיון: בגרסה 4, הגיבובים שהוחזרו מוינו כערכים מסוג little-endian. בגרסה 5, הערכים האלה מטופלים כערכי big-endian. מיון לקסיקוגרפי של מחרוזות בייטים שווה למיון מספרי של ערכי big-endian, ולכן הלקוחות לא צריכים יותר לבצע שלב מיון מיוחד. אם הטמעתם בעבר מיון מותאם אישית של little-endian, כמו זה שבהטמעה ב-Chromium v4, אתם יכולים להסיר אותו.
   • אורכי גיבוב משתנים: צריך לעדכן את אלגוריתם הפענוח כדי לתמוך באורכי גיבוב שונים שיכולים להיות מוחזרים בשדה HashList.compressed_additions, ולא רק באורך הגיבוב של ארבעה בייטים שמשמש בגרסה 4. אורך הגיבובים שמוחזרים בתשובה יכול להיקבע על סמך HashList.metadata.hash_length שמוחזר מ-hashLists.list. לחלופין, השם של רשימת הגיבוב המבוקשת מציין גם את הגדלים הצפויים של הגיבוב שיוחזרו מהרשימה. פרטים נוספים על רשימות הגיבוב זמינים בדף מסד נתונים מקומי.

המרת חיפושי גיבוב (Hash)

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

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

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

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

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