Google Safe Browsing
ważność krytycznamierzonysposób safe_browsing
Czy strona jest flagowana przez Google jako phishing lub malware. Użytkownicy widzą czerwony ekran ostrzeżenia.
WIKI
artykuł z 16.09.2026 · źródeł 12Google Safe Browsing to parametr monitoringu stron internetowych, który sprawdza, czy adres strony znajduje się na listach niebezpiecznych zasobów prowadzonych przez Google. Wynikiem jest trafienie z typem zagrożenia albo brak trafienia. Pomiar nie analizuje treści strony, tylko odczytuje werdykt Google. Interfejsy Safe Browsing pozwalają aplikacjom sprawdzać adresy URL na stale aktualizowanych listach, na których są m.in. strony socjotechniczne (phishing i strony wprowadzające w błąd) oraz strony z malware lub oprogramowaniem niechcianym [1].
Jak działa
Wpis na listę. Przy malware Google skanuje fragmenty swojego indeksu w poszukiwaniu przejętych witryn i uruchamia je w maszynie wirtualnej, sprawdzając, czy ulegnie ona infekcji. Strony phishingowe rozpoznają modele statystyczne [7]. Indeks jest skanowany codziennie. Niebezpieczna strona trafia na listę w ciągu kilku minut od wykrycia, a na zewnątrz staje się widoczna średnio po pół godzinie [7].
Dwa sposoby sprawdzenia w wersji 4. Lookup API przyjmuje żądanie z adresami i odpowiada stanem każdego z nich. Adresy nie są haszowane, więc serwer wie, o co pytano [1]. Update API pobiera zaszyfrowane kopie list do lokalnej bazy klienta i jest przeznaczone dla zastosowań wymagających częstych werdyktów z małym opóźnieniem. Korzysta z niego kilka przeglądarek i platform programowych [1].
Przed sprawdzeniem klient normalizuje adres (kanonizacja) i tworzy z niego wyrażenia: do 5 wariantów hosta i do 6 wariantów ścieżki, łącznie do 30 kombinacji. Dla każdego wyrażenia liczy skrót SHA-256, a prefiks skrótu to jego pierwsze 4–32 bajty [2]. Brak prefiksu w lokalnej bazie oznacza, że adres jest bezpieczny. Kolizja prefiksu wymaga wysłania go do serwerów Google, które zwracają wszystkie pełne skróty o tym prefiksie. Adres jest niebezpieczny tylko wtedy, gdy jeden z nich zgadza się z pełnym skrótem adresu [3]. Google poznaje prefiksy skrótów, ale nie same adresy [3].
Wersja 5 zmienia ten model. Google zauważa, że wraz ze wzrostem liczby i tempa zagrożeń lokalne listy tracą skuteczność [4]. Dlatego klient pobiera Global Cache, czyli listę stron prawdopodobnie bezpiecznych, a adres spoza niej sprawdza w API. W zapytaniu hashes.search wysyła tylko 4-bajtowy prefiks skrótu [4].
Standardy i specyfikacje
- Safe Browsing API v4 udostępnia Lookup API i Update API. Wersja 4 jest oznaczona jako wycofywana (deprecated). API służy wyłącznie do użytku niekomercyjnego. Do celów komercyjnych, rozumianych jako sprzedaż lub generowanie przychodu, Google wskazuje Web Risk API [1].
- Kanonizacja i skróty adresów są opisane w osobnym dokumencie: usuwanie fragmentu po
#, wielokrotne dekodowanie procentowe, normalizacja hosta i ścieżki, wyrażenia przyrostków hosta i przedrostków ścieżki [2]. - Typy zagrożeń (
ThreatType):MALWARE,SOCIAL_ENGINEERING,UNWANTED_SOFTWAREiPOTENTIALLY_HARMFUL_APPLICATION[5]. - Web Risk Google opisuje jako produkt bezpieczeństwa dla przedsiębiorstw, który sprawdza adresy na stale aktualizowanych listach niebezpiecznych zasobów Google. Ma własne Lookup API i Update API. Informacji zwróconych przez Web Risk nie wolno redystrybuować [6].
- Site Status Tool w raporcie przejrzystości Google przyjmuje adres, witrynę albo domenę i zwraca najnowszy wynik analizy Safe Browsing, bez odwiedzania strony [8].
- Raport „Problemy dotyczące bezpieczeństwa” w Search Console jest miejscem złożenia wniosku o przegląd po oczyszczeniu witryny. Przed wnioskiem właściciel potwierdza własność witryny, usuwa skutki włamania, łata lukę i przywraca stronę do sieci [9].
Zagrożenia i skutki
Ostrzeżenie w przeglądarce. Chrome przy stronach z phishingiem, malware, oprogramowaniem niechcianym lub socjotechniką może wyświetlić czerwone ostrzeżenie „Dangerous site” i zaleca, by strony nie odwiedzać [10]. Firefox korzysta z protokołu v4 od wersji 56 (koniec 2017 roku). Wyświetla strony ostrzeżeń dla kategorii malware, phishing, unwanted i harmful, z przyciskami „Ignore this warning” i „Get me out of here” [11]. Safari z włączoną funkcją Fraudulent Website Warning ostrzega przed podejrzewanym phishingiem lub malware. Wysyła do Google Safe Browsing i Apple informacje wyliczone z adresu, a w Chinach kontynentalnych i Hongkongu może użyć także Tencent Safe Browsing. Pełny adres nie trafia do dostawcy [12].
Opóźnienie w obie strony. Między wykryciem a widocznością na zewnątrz mija średnio pół godziny [7]. Klient Update API trzyma werdykt przez czas podany w cacheDuration, a brak zagrożenia przez negativeCacheDuration [3]. Po naprawie przegląd phishingu trwa około doby, malware kilka dni, a spamu po włamaniu do kilku tygodni [9]. Po pozytywnym przeglądzie ostrzeżenia w przeglądarkach i wynikach wyszukiwania znikają w ciągu 72 godzin [9]. W odpowiedziach na najczęstsze pytania Google podaje, że oczyszczona strona po ponownym skanie schodzi z listy zwykle w ciągu 24 godzin [7]. Wniosek złożony, zanim problem naprawdę zniknie, wydłuża okres oznaczenia [9].
Fałszywe pozytywy. Google deklaruje bardzo niewiele fałszywych pozytywów [7]. Właściciel strony błędnie oznaczonej jako phishing może zgłosić to formularzem report_error, który uruchamia też przegląd oczyszczonych stron [9]. Firefox po pominięciu ostrzeżenia oferuje przyciski „This isn't an attack site” i „This isn't a web forgery” [11].
Granice odczytu. Brak trafienia nie dowodzi, że strona jest czysta. Google przyznaje, że malware może się ukrywać w wielu miejscach [7]. Zapytanie o sam adres główny tworzy wyłącznie wyrażenia hosta z pustą ścieżką, więc wpis dotyczący jednej podstrony nie zostanie do niego dopasowany [2]. Wersja 4 jest wycofywana i niekomercyjna [1], a dane Web Risk nie mogą być dalej rozpowszechniane [6].
Przykłady
| Sytuacja w Update API | Wynik |
|---|---|
| prefiks adresu nie występuje w lokalnej bazie | adres bezpieczny, bez zapytania do serwera [3] |
| kolizja prefiksu, żaden pełny skrót z serwera nie pasuje | adres bezpieczny [3] |
| kolizja prefiksu i zgodny pełny skrót | adres niebezpieczny, klient pokazuje ostrzeżenie [3] [11] |
| Typ zagrożenia | Czym jest | Przegląd po naprawie |
|---|---|---|
SOCIAL_ENGINEERING | phishing i strony wprowadzające w błąd [1] | około doby [9] |
MALWARE | strony z malware [1] [5] | kilka dni [9] |
UNWANTED_SOFTWARE | strony z oprogramowaniem niechcianym [1] [5] | wniosek w tej samej kategorii co malware [9] |
POTENTIALLY_HARMFUL_APPLICATION | potencjalnie szkodliwa aplikacja [5] | brak danych |
Dla adresu http://a.b.c/1/2.html?param=1 specyfikacja wymienia m.in. wyrażenia a.b.c/1/2.html?param=1, a.b.c/1/, a.b.c/ i b.c/ [2]. Zapytanie o https://a.b.c/ daje tylko a.b.c/ i b.c/, więc nie obejmuje wpisu dla a.b.c/1/2.html [2].
- [1] Safe Browsing APIs (v4) — Overview · Google for Developers
- [2] URLs and Hashing — Safe Browsing APIs (v4) · Google for Developers
- [3] Safe Browsing Update API (v4) · Google for Developers
- [4] Google Safe Browsing v5 — Overview · Google for Developers
- [5] ThreatType — Safe Browsing API (v4) reference · Google for Developers
- [6] Web Risk — Overview · Google Cloud
- [7] Safe Browsing FAQs · Google Transparency Report Help Center
- [8] Updates to the Google Safe Browsing's Site Status Tool · Google Search Central Blog
- [9] Request a review · Google (web.dev)
- [10] Manage warnings about unsafe sites · Google Chrome Help
- [11] Security/Safe Browsing · MozillaWiki
- [12] Safari & Privacy · Apple
STATS
wyniki z systemu · tylko liczby zbiorczeTen parametr nie zapisuje odczytu per strona — przebieg zostawia tylko ustalenia, więc liczby sprawdzonych stron i wyników „ok” system nie ma. Pojawią się po wdrożeniu zapisu przebiegów per strona per parametr.
Ten parametr nie otworzył jeszcze żadnego ustalenia w bazie LAB247. Pusto nie znaczy „czysto” — znaczy, że nic nie przekroczyło reguły.
- Przebiegów
- 65sposób safe_browsing
- W 30 dni
- 65przebiegów
- Ostatni
- 19.09.2026start przebiegu
- Stron w przebiegach
- —65 przebiegów bez liczby stron
CARD
karta z kodu CREATO_PING, odczyt 16.09.2026| Obszar i ważność | Bezpieczeństwo · krytyczna (B04) |
|---|---|
| Workflow i częstotliwość | creato_ping_security_v2 · P4 działa na LAB247cron co 24 h, T1–T3 · Szybki skan: tylko ewidentne przejęcie widoczne z zewnątrz.creato_ping_security_v2 · P3 działa na LAB247cron co 24 h, T1–T3; T4 raz po anomalii · Dokładny skan. dns_integrity porównuje NS, MX, SPF i DMARC z wzorcem z poprzedniego przebiegu. |
| Sonda i helper | sposób safe_browsing · CREATO_PING/helpers/safebrowsing.py |
| Testy |
|
| Typ wyniku | 0–2 ustalenia na stronę: safebrowsing_flagged (odczyt zbiorczy) i infection_safe_browsing (kanał w skanie infekcji); w szczegółach typy zagrożeń |
| Jednostka | brak — wynik jakościowy (trafienie na liście Google albo brak) |
| Próg i reguła | Reguła: dowolne trafienie na liście = ustalenie. Timeout 8,0 s dla odczytu zbiorczego i 5,0 s w skanie infekcji — stałe w helperach. Błąd sieci, kod inny niż 200 albo zły JSON = brak ustalenia. |
| Gdzie leżą pokrętła | CREATO_PING/helpers/safebrowsing.py → _TIMEOUT, _THREAT_TYPES, _WEBRISK_THREAT_TYPES, _WEBRISK_CONCURRENCYCREATO_PING/.env → GOOGLE_WEBRISK_API_KEY, GOOGLE_SAFE_BROWSING_API_KEY (wybór dostawcy)CREATO_PING/helpers/html_fetch.py → _CDN_HEADERS, _CDN_SERVER_TOKENSCREATO_PING/config/incident_policy.toml → [finding] infection_safe_browsing, safebrowsing_flagged |
| Retencja odczytów | Odczytu per strona nie zapisujemy — zostaje tylko ustalenie w tabeli findings (otwarcie, zamknięcie, dowód). Replay po surowych odczytach dziś niemożliwy. |
| Znane rozbieżności |
|
| Karta przepisana z | CREATO_PING/helpers/safebrowsing.py · CREATO_PING/helpers/infection_check.py · CREATO_PING/helpers/security_runner.py · CREATO_PING/helpers/html_fetch.py · CREATO_PING/config/incident_policy.toml · CREATO_PING/helpers/clickup_writer_v2.py · odczyt 16.09.2026 |
Oba ustalenia: powaga pilna, pewność ewidentna, skutek ZAINFEKOWANA, alarm i termin „teraz”; kolejny skan z trafieniem aktualizuje ten sam subtask. Żaden kanał nie wysyła sygnału zamknięcia: zdjęcie strony z listy Google nie zamyka subtaska, zamknięcie jest ręczne.
| Ustalenie | Powaga | Pewność | Skutek | Subtask / alarm | Co zrobić |
|---|---|---|---|---|---|
| Google Safe Browsinginfection_safe_browsing | Pilne | Ewidentne | INFEKCJA | tak / tak | Natychmiastowe czyszczenie strony i wniosek o ponowną weryfikację w Search Console. |
| Flaga Safe Browsingsafebrowsing_flagged | Pilne | Ewidentne | INFEKCJA | tak / tak | Jak przy infekcji: czyszczenie i ponowna weryfikacja. |
LOOP
pętli: 1Trafności jeszcze nie liczymy: zamknięcie subtaska nie niesie dziś werdyktu (prawdziwy / fałszywy / nie dało się sprawdzić). Cztery liczby pojawią się, gdy każde zamknięcie dostanie werdykt — to warunek startu pętli 1.
Sygnał: Research kampanii: DollyWay, SocGholish i EtherHiding ładują kod z domeny ofiary albo z blockchaina, więc filtr „obcy host” ich nie widzi. Przypadek źródłowy: wielomiesięczna niewykryta infekcja typu DollyWay. · dotyczy też: Malware / infekcja
- 1. Zbiórkaręcznieodczyt z nocnego skanu, bez zapisu per strona
- 2. Werdyktręcznieluka reguły potwierdzona na znanym przypadku
- 3. Miarabrakliczników trafności wtedy nie było
- 4. Kartabrakkarta parametru powstała 2026-09-16
- 5. Zmianazrobionetrzy sygnatury, ustalenie „nie sprawdzono”, Web Risk
- 6. Replaybrakbrak zapisanych odczytów do replayu
| Data | Zmiana | Powód | Wpływ na system | Commit · replay |
|---|---|---|---|---|
| 2026-09-05 | Trzy sygnatury kampanii jako sygnały pewne: loader z własnej domeny pod /?<hash>, bramka REST SocGholish, payload z blockchaina.helpers/infection_check.py · config/incident_policy.toml | Kampanie omijają logikę obcego hosta; WordPress nigdy nie podłącza skryptu pod /?<hash>. | tylko ten parametr | b0fc77cbez replayubez zapisu zatwierdzenia |
| 2026-09-05 | Nieudane pobranie strony głównej daje infection_scan_unknown (tylko statystyka) zamiast pustej listy.helpers/infection_check.py · config/incident_policy.toml | Pusta lista ustaleń po 403 z WAF-a czytała się jak „czysto”, choć heurystyki w ogóle się nie wykonały. | cały system Zasada „nie dało się sprawdzić” jako trzeci stan weszła do polityki i do cotygodniowego zestawienia; ten sam podział obowiązuje dziś w statystykach wszystkich parametrów. | b0fc77cbez replayubez zapisu zatwierdzenia |
| 2026-09-05 | Zbiorczy odczyt reputacji używa Web Risk, gdy na serwerze jest klucz; bez klucza zostaje Safe Browsing v4 (klucz Web Risk w runbooku: do zrobienia).helpers/safebrowsing.py | Safe Browsing v4 jest wycofywany i licencyjnie niekomercyjny. | cały system Dotyczy też parametru Google Safe Browsing — to ten sam kanał reputacji. | b0fc77cbez replayubez zapisu zatwierdzenia |