Interfejsy Safe Browsing API umożliwiają aplikacjom klienckim przeprowadzanie w czasie rzeczywistym lub na podstawie list sprawdzania adresów URL na stale aktualizowanych przez Google listach niebezpiecznych zasobów internetowych. Przykładami niebezpiecznych zasobów internetowych są witryny stosujące inżynierię społeczną (wyłudzające informacje i wprowadzające w błąd) oraz witryny hostujące złośliwe lub niechciane oprogramowanie. Każdy adres URL znajdujący się na liście Bezpiecznego przeglądania jest uznawany za niebezpieczny.
Aby sprawdzić, czy adres URL znajduje się na którejś z list Bezpiecznego przeglądania, klienci mogą użyć urls.search lub hashes.search.
Co nowego?
Aktualność danych
Klienci Bezpiecznego przeglądania tradycyjnie okresowo pobierają listy zagrożeń, które są używane do porównywania z potencjalnymi zagrożeniami. W miarę upływu czasu i wzrostu liczby oraz szybkości rozprzestrzeniania się zagrożeń lokalne listy zagrożeń stają się coraz mniej skuteczne w walce z nowoczesnymi zagrożeniami.
Aby to zmienić, wprowadzamy możliwość przełączania protokołów na domyślne sprawdzanie zamiast domyślnego zezwalania, które było wcześniej dostępne w interfejsie v4. Wprowadziliśmy możliwość pobierania listy prawdopodobnie bezpiecznych witryn, zwanej „pamięcią podręczną globalną”. Jeśli adresu URL nie ma w pamięci podręcznej Global Cache, klient powinien sprawdzić za pomocą interfejsu API, czy adres URL stanowi zagrożenie.
Możliwość domyślnego przeprowadzania kontroli w połączeniu z poprawą aktualności danych w usłudze zapewni szybszą ochronę przed nowymi zagrożeniami w czasie zbliżonym do rzeczywistego.
Prywatność IP
Interfejs Safe Browsing API używa adresów IP tylko do podstawowych potrzeb sieciowych i do celów związanych z ochroną przed atakami typu DoS.
Wprowadziliśmy powiązany interfejs API o nazwie Safe Browsing Oblivious HTTP Gateway API, aby zapewnić dodatkowe gwarancje prywatności. W tym celu używamy Oblivious HTTP, aby ukrywać adresy IP użytkowników przed Google. Działa to w ten sposób, że niezależna osoba trzecia, która nie wchodzi w zmowę z Google, obsługuje zaszyfrowaną wersję żądania użytkownika, a następnie przekazuje ją do Google. Dzięki temu firma zewnętrzna ma dostęp tylko do adresów IP, a Google – tylko do treści żądania. Inna firma obsługuje przekaźnik Oblivious HTTP (np. tę usługę Fastly), a Google obsługuje bramę Oblivious HTTP. Jest to opcjonalny interfejs API towarzyszący. Gdy jest używana w połączeniu z Bezpiecznym przeglądaniem Google, adresy IP użytkowników nie są już wysyłane do Google.
Więcej informacji znajdziesz w dokumentacji interfejsu Safe Browsing Oblivious HTTP Gateway API.
Metody wyszukiwania
Przyjrzyjmy się różnym metodom sprawdzania adresów URL w czasie rzeczywistym.
urls.search
Umożliwia aplikacjom klienckim wysyłanie adresów URL do usługi Bezpieczne przeglądanie w celu sprawdzenia, czy są z nimi powiązane jakiekolwiek zagrożenia.
Zalety
- Proste sprawdzanie adresów URL: wysyłasz żądanie z rzeczywistymi adresami URL, a serwer odpowiada adresami URL z powiązanymi z nimi zagrożeniami (jeśli takie istnieją).
Wady
- Brak poufności adresu URL: żądanie zawiera nieprzetworzone adresy URL, które są sprawdzane.
Jeśli zalety i wady odpowiadają Twoim wymaganiom, rozważ użycie urls.search, ponieważ jest to proste rozwiązanie.
Zapoznaj się z Warunkami korzystania z usługi, ponieważ różnią się one od hashes.search.
hashes.search
Umożliwia aplikacjom klienckim sprawdzanie, czy w zbiorze adresów URL występują znane zagrożenia, bez ujawniania tych adresów usłudze. W tym celu podawany jest tylko prefiks skrótu adresu URL. Odpowiedź będzie zawierać pełne hasze znanych zagrożeń z prefiksem hasza fragmentu.
Zalety
- Poufność adresu URL: w żądaniu znajduje się tylko 4-bajtowy prefiks adresu URL zaszyfrowany za pomocą funkcji skrótu haszowego.
- Zgodność: ponieważ klient obsługuje kanonizację i haszowanie adresów URL, ta metoda bezproblemowo integruje się z trybami, które korzystają z lokalnej bazy danych, takimi jak tryb czasu rzeczywistego i tryb listy lokalnej.
Wady
- Złożone sprawdzanie adresów URL: aby wysyłać żądania do tej metody i porównywać je z lokalnymi kopiami list niebezpiecznych lub globalnej pamięci podręcznej, musisz wiedzieć, jak kanonizować adresy URL, tworzyć wyrażenia przyrostków i prefiksów oraz obliczać hasze SHA256.
Jeśli chcesz zachować poufność adresów URL i interesuje Cię korzystanie z trybu czasu rzeczywistego lub trybu listy lokalnej, zalecamy użycie hashes.search.
HashList Metody
Te metody umożliwiają klientom pobieranie i przechowywanie zaszyfrowanych wersji list niebezpiecznych i pamięci podręcznej globalnej. Klienci mogą wykorzystać te informacje, aby określić, czy powinni przeprowadzić wyszukiwanie w czasie rzeczywistym w przypadku danych adresów URL.
Te metody są niezbędne do działania trybu czasu rzeczywistego i trybu listy lokalnej.
Więcej informacji o tym, jak korzystać z tych metod, znajdziesz na stronie Baza danych lokalnych.
Przykładowe żądania
W tej sekcji znajdziesz przykłady bezpośredniego używania interfejsu HTTP API do uzyskiwania dostępu do Bezpiecznego przeglądania. Zwykle zalecamy używanie wygenerowanego powiązania językowego, ponieważ automatycznie obsługuje ono kodowanie i dekodowanie w wygodny sposób. Informacje o tym powiązaniu znajdziesz w dokumentacji.
Przykładowe żądanie HTTP z użyciem urls.search:
GET https://safebrowsing.googleapis.com/v5alpha1/urls:search?key=INSERT_YOUR_API_KEY_HERE&urls=testsafebrowsing.appspot.com/
Przykładowe żądanie HTTP z użyciem hashes.search:
GET https://safebrowsing.googleapis.com/v5/hashes:search?key=INSERT_YOUR_API_KEY_HERE&hashPrefixes=WwuJdQ
Przykładowe żądanie HTTP z użyciem hashLists.batchGet:
GET https://safebrowsing.googleapis.com/v5/hashLists:batchGet?key=INSERT_YOUR_API_KEY_HERE&names=se&names=mw-4b
Wszystkie treści odpowiedzi są ładunkami sformatowanymi jako bufory protokołu, które możesz dekodować.