Overview

API функции «Безопасный просмотр» позволяют вашим клиентским приложениям выполнять проверку URL-адресов в режиме реального времени или по списку, используя постоянно обновляемые списки небезопасных веб-ресурсов Google. Примерами небезопасных веб-ресурсов являются сайты, использующие методы социальной инженерии (фишинговые и мошеннические сайты), а также сайты, на которых размещено вредоносное или нежелательное программное обеспечение. Любой URL-адрес, найденный в списке «Безопасный просмотр», считается небезопасным.

Чтобы определить, находится ли URL-адрес в каком-либо из списков безопасного просмотра, клиенты могут использовать либо urls.search , либо hashes.search .

Что нового?

Актуальность данных

Традиционно клиенты Safe Browsing периодически загружают списки угроз, используемые для сопоставления с потенциальными угрозами. Однако, поскольку объемы и скорость распространения угроз со временем возросли, эти локальные списки угроз стали менее эффективны против современных угроз.

Чтобы устранить этот пробел, мы вводим возможность переключения протоколов с протокола «разрешение по умолчанию», доступного ранее в версии 4, на протокол «проверка по умолчанию ». Это достигается за счет возможности загрузки списка потенциально безопасных сайтов, называемого «глобальным кэшем». Если URL-адрес не найден в глобальном кэше, клиент должен выполнить проверку с помощью API, чтобы определить, представляет ли этот URL-адрес угрозу.

Возможность выполнения проверок по умолчанию, а также улучшение актуальности данных в сервисе обеспечат более быструю защиту от новых угроз практически в режиме реального времени.

Конфиденциальность IP-адресов

API безопасного просмотра использует IP-адреса только для необходимых сетевых задач и в целях защиты от DoS-атак.

Мы представили дополнительный API, известный как Safe Browsing Oblivious HTTP Gateway API, для обеспечения дополнительных гарантий конфиденциальности. Он использует Oblivious HTTP для скрытия IP-адресов конечных пользователей от Google. Принцип работы заключается в том, что не участвующая в сговоре третья сторона обрабатывает зашифрованную версию запроса пользователя и затем пересылает её в Google. Таким образом, третья сторона имеет доступ только к IP-адресам, а Google — только к содержимому запроса. Третья сторона управляет Oblivious HTTP Relay (например, сервисом Fastly ), а Google управляет Oblivious HTTP Gateway. Это необязательный дополнительный API. При использовании его совместно с Google Safe Browsing IP-адреса конечных пользователей больше не отправляются в Google.

Дополнительные сведения см. в документации по API шлюза HTTP Safe Browsing Oblivious .

Методы поиска

Рассмотрим различные методы, доступные для выполнения проверки URL-адресов в режиме реального времени.

urls.search

Позволяет клиентским приложениям отправлять URL-адреса в службу безопасного просмотра для проверки наличия угроз, связанных с этими URL-адресами.

Преимущества
  • Простая проверка URL-адресов : вы отправляете запрос с фактическими URL-адресами, а сервер отвечает URL-адресами и связанными с ними угрозами (если таковые имеются).
Недостатки
  • Конфиденциальность URL-адресов отсутствует : запрос содержит проверяемые исходные URL-адреса.

Если преимущества/недостатки соответствуют вашим требованиям, рассмотрите возможность использования urls.search поскольку он прост в использовании.

Ознакомьтесь с условиями использования метода, поскольку они отличаются от условий использования hashes.search .

hashes.search

Это позволяет клиентским приложениям проверять наличие известных угроз в наборе URL-адресов, не раскрывая сами URL-адреса сервису. Для этого достаточно указать только префикс хеша URL-адреса. В ответе будут содержаться полные хеши известных угроз с префиксом хеша сегмента.

Преимущества
  • Конфиденциальность URL : В запросе содержится только 4-байтовый префикс хеша хешированного URL.
  • Совместимость : Поскольку клиент обрабатывает канонизацию и хеширование URL-адресов, этот метод легко интегрируется с режимами, использующими локальную базу данных, такими как режим реального времени и режим локального списка.
Недостатки
  • Сложные проверки URL-адресов : Вам необходимо знать, как канонизировать URL-адреса, создавать выражения суффиксов/префиксов и вычислять хеши SHA256 для выполнения запросов к этому методу, а также сравнивать их с локальными копиями списков небезопасных адресов или глобальным кэшем .

Если вам необходимо обеспечить конфиденциальность URL-адресов и вы заинтересованы в использовании режима реального времени или режима локального списка , то рекомендуется использовать hashes.search .

Методы HashList

Эти методы позволяют клиентам загружать и сохранять хешированные версии списков небезопасных адресов и глобального кэша . Клиенты могут использовать эту информацию, чтобы определить, следует ли им выполнять поиск по рассматриваемым URL-адресам в режиме реального времени.

Эти методы необходимы для работы в режиме реального времени и в режиме локального списка .

Дополнительную информацию об использовании этих методов см. на странице «Локальная база данных» .

Примеры запросов

В этом разделе приведены примеры прямого использования HTTP API для доступа к Safe Browsing. Как правило, рекомендуется использовать сгенерированную языковую привязку, поскольку она автоматически и удобно обрабатывает кодирование и декодирование. Пожалуйста, обратитесь к документации по этой привязке.

Пример HTTP-запроса с использованием urls.search :

GET https://safebrowsing.googleapis.com/v5alpha1/urls:search?key=INSERT_YOUR_API_KEY_HERE&urls=testsafebrowsing.appspot.com/

Пример 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/v5/hashLists:batchGet?key=INSERT_YOUR_API_KEY_HERE&names=se&names=mw-4b

Все ответы представляют собой полезную нагрузку в формате Protocol Buffer, которую вы можете декодировать.