Эта страница переведена с помощью Cloud Translation API.

Migration From V4

Одним из существенных улучшений Google Safe Browsing версии 5 по сравнению с версией 4 (в частности, API обновления версии 4 ) является актуальность и охват данных. Поскольку защита в значительной степени зависит от локальной базы данных, поддерживаемой клиентом, задержка и размер обновления локальной базы данных являются основной причиной отсутствия защиты. В версии 4 типичному клиенту требуется от 20 до 50 минут, чтобы получить самую актуальную версию списков угроз. К сожалению, фишинговые атаки распространяются быстро: по состоянию на 2021 год 60% сайтов, осуществляющих атаки, работают менее 10 минут. Наш анализ показывает, что около 25-30% случаев отсутствия защиты от фишинга связаны с такой устаревшей информацией. Кроме того, некоторые устройства не оснащены для обработки всех списков угроз Google Safe Browsing, которые со временем продолжают расти.

Если вы в настоящее время используете API обновления версии 4 , существует возможность беспрепятственной миграции с версии 4 на версию 5 без необходимости сброса или удаления локальной базы данных. В этом разделе описано, как это сделать.

Преобразование обновлений списка

В отличие от версии 4, где списки идентифицировались кортежем, состоящим из типа угрозы, типа платформы и типа записи угрозы, в версии 5 списки идентифицируются просто по имени. Это обеспечивает гибкость, когда несколько списков версии 5 могут использовать один и тот же тип угрозы. Типы платформ и типы записей угроз удалены в версии 5.

В версии 4 для загрузки списков использовался метод threatListUpdates.fetch . В версии 5 переключились на метод hashLists.batchGet .

В запрос следует внести следующие изменения:

Объект ClientInfo версии 4 следует полностью удалить. Вместо указания идентификатора клиента с помощью отдельного поля, просто используйте хорошо известный заголовок User-Agent . Хотя для указания идентификатора клиента в этом заголовке нет установленного формата, мы рекомендуем просто указать исходный идентификатор клиента и версию клиента, разделенные пробелом или косой чертой.
Для каждого объекта ListUpdateRequest версии 4 : * Найдите соответствующее имя списка версии 5 в списке доступных списков и укажите это имя в запросе версии 5.
- Удалите ненужные поля, такие как threat_entry_type или platform_type .
- Поле state в версии 4 напрямую совместимо с полем versions в версии 5. Та же самая байтовая строка, которая отправлялась бы на сервер с помощью поля state в версии 4, может быть просто отправлена в версии 5 с помощью поля versions .
- В версии 4 для ограничений используется упрощенная версия под названием SizeConstraints . Дополнительные поля, такие как region , следует удалить.

В ответ следует внести следующие изменения:

ResponseType в версии 4 просто заменено логическим полем с именем partial_update .
Поле minimum_wait_duration теперь может принимать значение ноль или быть опущено. В этом случае клиенту будет предложено немедленно отправить еще один запрос. Это происходит только в том случае, если клиент указывает в SizeConstraints ограничение на максимальный размер обновления меньше, чем максимальный размер базы данных.
Для декодирования хешей, закодированных по алгоритму Райса-Голомба, требуется две основные корректировки:
- Порядок байтов и сортировка: В версии 4 возвращаемые хеши сортировались как значения с порядком байтов little-endian. В версии 5 они обрабатываются как значения с порядком байтов big-endian. Поскольку лексикографическая сортировка байтовых строк эквивалентна числовой сортировке значений big-endian, клиентам больше не нужно выполнять специальный этап сортировки. Пользовательская сортировка с порядком байтов little-endian, подобная той, что реализована в Chromium v4 , может быть удалена, если она была реализована ранее.
- Переменные длины хешей: Алгоритм декодирования необходимо обновить для поддержки различных длин хешей, которые могут быть возвращены в поле HashList.compressed_additions , а не только четырехбайтовой длины хеша, используемой в версии 4. Длина хешей, возвращаемых в ответе, может быть определена на основе HashList.metadata.hash_length , возвращаемого функцией hashLists.list . В качестве альтернативы, имя запрошенного списка хешей также указывает на ожидаемые размеры хешей, возвращаемых из списка. Дополнительные сведения о списках хешей см. на странице «Локальная база данных» .

Преобразование хэш-поиска

В версии 4 для получения полных хешей использовался метод fullHashes.find . Эквивалентным методом в версии 5 является метод hashes.search .