ARK. B04Parametr monitoringuBezpieczeństwo · lista 50 parametrów

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.

ARK. 1

WIKI

artykuł z 16.09.2026 · źródeł 12

Google 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].

RYS. 1.1Update API: prefiks lokalnie, pełny skrót z serwera

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_SOFTWARE i POTENTIALLY_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].

RYS. 1.2Od oznaczenia do zdjęcia ostrzeżenia

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 APIWynik
prefiks adresu nie występuje w lokalnej bazieadres bezpieczny, bez zapytania do serwera [3]
kolizja prefiksu, żaden pełny skrót z serwera nie pasujeadres bezpieczny [3]
kolizja prefiksu i zgodny pełny skrótadres niebezpieczny, klient pokazuje ostrzeżenie [3] [11]
Typ zagrożeniaCzym jestPrzegląd po naprawie
SOCIAL_ENGINEERINGphishing i strony wprowadzające w błąd [1]około doby [9]
MALWAREstrony z malware [1] [5]kilka dni [9]
UNWANTED_SOFTWAREstrony z oprogramowaniem niechcianym [1] [5]wniosek w tej samej kategorii co malware [9]
POTENTIALLY_HARMFUL_APPLICATIONpotencjalnie 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].

TAB. 1.1Przypisy12
  1. [1] Safe Browsing APIs (v4) — Overview · Google for Developers
  2. [2] URLs and Hashing — Safe Browsing APIs (v4) · Google for Developers
  3. [3] Safe Browsing Update API (v4) · Google for Developers
  4. [4] Google Safe Browsing v5 — Overview · Google for Developers
  5. [5] ThreatType — Safe Browsing API (v4) reference · Google for Developers
  6. [6] Web Risk — Overview · Google Cloud
  7. [7] Safe Browsing FAQs · Google Transparency Report Help Center
  8. [8] Updates to the Google Safe Browsing's Site Status Tool · Google Search Central Blog
  9. [9] Request a review · Google (web.dev)
  10. [10] Manage warnings about unsafe sites · Google Chrome Help
  11. [11] Security/Safe Browsing · MozillaWiki
  12. [12] Safari & Privacy · Apple
ARK. 2

STATS

wyniki z systemu · tylko liczby zbiorcze
TAB. 2.1Odczyty per strona

Ten 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.

TAB. 2.3Ustalenia

Ten parametr nie otworzył jeszcze żadnego ustalenia w bazie LAB247. Pusto nie znaczy „czysto” — znaczy, że nic nie przekroczyło reguły.

TAB. 2.4Przebiegi z tym sposobem sprawdzeniaod 09.09.2026
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
ARK. 3

CARD

karta z kodu CREATO_PING, odczyt 16.09.2026
RYS. 3.1Droga parametru przez system: Google Safe Browsing
TAB. 3.1Pomiarpliki: 6
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 helpersposób safe_browsing · CREATO_PING/helpers/safebrowsing.py
Testy
  1. Odczyt zbiorczy w przebiegach P3 i P4 dla wszystkich stron z rekordem A, paczki po 16 stron.
  2. Z kluczem Web Risk: zapytanie o https://domena/ (do 10 równolegle), typy MALWARE, SOCIAL_ENGINEERING, UNWANTED_SOFTWARE. Bez niego, z kluczem Safe Browsing v4: jedno zapytanie dla całej paczki, cztery typy (także POTENTIALLY_HARMFUL_APPLICATION). Brak obu kluczy = pominięcie z wpisem w logu.
  3. Kanał w skanie infekcji: tylko z kluczem Safe Browsing v4, po udanym pobraniu strony głównej i gdy strona nie stoi za CDN (Cloudflare, Sucuri, Akamai, Imperva, Fastly); zapytanie o http:// i https:// domeny.
  4. Sprawdzany jest wyłącznie adres główny domeny, podstrony nie.
Typ wyniku0–2 ustalenia na stronę: safebrowsing_flagged (odczyt zbiorczy) i infection_safe_browsing (kanał w skanie infekcji); w szczegółach typy zagrożeń
Jednostkabrak — wynik jakościowy (trafienie na liście Google albo brak)
Próg i regułaReguł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łaCREATO_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ówOdczytu 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
  1. Jedno oznaczenie w Google może dać dwa ustalenia i dwa subtaski na tej samej stronie — to dwa różne typy, a zapis scala tylko w obrębie typu.
  2. Brak trzeciego stanu: brak klucza, błąd sieci albo zły kod dają pustą listę, nieodróżnialną od „nie ma na liście”.
  3. Skan infekcji pomija strony za CDN, choć zapytanie dotyczy adresu URL, a nie odpowiedzi serwera; odczyt zbiorczy tych stron nie pomija.
  4. Pytanie tylko o adres główny: wpis Google dla pojedynczej podstrony (np. wstrzykniętej strony phishingowej) zostaje przeoczony.
  5. Typy zagrożeń zależą od dostawcy: ścieżka Web Risk nie pyta o POTENTIALLY_HARMFUL_APPLICATION.
  6. Brak sygnału zamknięcia: po zdjęciu strony z listy subtask ZAINFEKOWANA zostaje otwarty.
  7. Klucz Web Risk na serwerze ma w runbooku stan „do zrobienia” — produkcja prawdopodobnie działa na wycofywanym, niekomercyjnym v4. Do 2026-09-05 odczyt zbiorczy nie widział klucza (inna pisownia nazwy), więc brak dawnych ustaleń nie znaczy „czysto”.
kandydaci do pętli: kod a opis parametru albo specyfikacja
Karta przepisana zCREATO_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
TAB. 3.2Co oznacza failtypów ustaleń: 2

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.

UstaleniePowagaPewnośćSkutekSubtask / alarmCo zrobić
Google Safe Browsinginfection_safe_browsingPilneEwidentneINFEKCJAtak / takNatychmiastowe czyszczenie strony i wniosek o ponowną weryfikację w Search Console.
Flaga Safe Browsingsafebrowsing_flaggedPilneEwidentneINFEKCJAtak / takJak przy infekcji: czyszczenie i ponowna weryfikacja.
ARK. 4

LOOP

pętli: 1
RYS. 4.1Pętla parametru — sześć etapów
TAB. 4.1Trafność, 30 dnialarmy · prawdziwe · fałszywe · bez rozstrzygnięcia

Trafnoś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.

TAB. 4.2Pętle1 · zmian: 3 · wpływających na cały system: 2
Kampanie 2025–26 i „nie sprawdzono ≠ czysto”zamknięta historyczna 2026-09-05

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. 1. Zbiórkaręcznieodczyt z nocnego skanu, bez zapisu per strona
  2. 2. Werdyktręcznieluka reguły potwierdzona na znanym przypadku
  3. 3. Miarabrakliczników trafności wtedy nie było
  4. 4. Kartabrakkarta parametru powstała 2026-09-16
  5. 5. Zmianazrobionetrzy sygnatury, ustalenie „nie sprawdzono”, Web Risk
  6. 6. Replaybrakbrak zapisanych odczytów do replayu
DataZmianaPowódWpływ na systemCommit · replay
2026-09-05Trzy 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.tomlKampanie omijają logikę obcego hosta; WordPress nigdy nie podłącza skryptu pod /?<hash>.tylko ten parametrb0fc77cbez replayubez zapisu zatwierdzenia
2026-09-05Nieudane pobranie strony głównej daje infection_scan_unknown (tylko statystyka) zamiast pustej listy.helpers/infection_check.py · config/incident_policy.tomlPusta 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-05Zbiorczy 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.pySafe 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
Blog 24/7
20.09Zastrzeżony PESEL: zmiana raz na 30 minut, blokada przy wypłaciedobreprogramy.pl20.09Fałszywe SMS-y od GITD o mandacie za autostradę wyłudzają dane kartyinstalki.pl20.09Pakiet npm indexed-btree omija blokadę skryptów instalacyjnychbleepingcomputer.com19.09SolarWinds łata CVE-2026-28326 w Access Rights Manager, zdalny kod bez logowaniathehackernews.com19.09Orkes Conductor: luka CVE-2026-58138 atakowana w sieci, poprawka w wersji 3.30.2thehackernews.com19.09Trzy luki jądra Linux w katalogu CISA KEV, Red Hat potwierdza aktywne atakithehackernews.com18.09Publiczne exploity na cztery luki jądra Linux dają lokalnie uprawnienia rootthehackernews.com18.09Brevo: skradziony klucz API Cloudflare i skrypty ClickFix na stronach klientówbleepingcomputer.com18.09WaterPlum z Korei Północnej zainfekowała 30 000 urządzeń w 100 krajachtherecord.media18.09Jedna zgoda OAuth daje napastnikowi dostęp do poczty i plików mimo MFAdarkreading.com