Web Bot Auth: jak podpisywane są żądania agentów i czego dowodzi podpis

Zautomatyzowana przeglądarka może wykonywać JavaScript i przez to przypominać w analityce wizytę człowieka. Nie jest to nieuniknione: rejestrowanie zależy od konfiguracji pomiaru, wykrywania botów i wykonywanych działań. Web Bot Auth dodaje do tych sygnałów kryptograficznie weryfikowalny identyfikator podpisanych żądań.

Najważniejsza granica jest prosta: poprawny podpis potwierdza użycie odpowiedniego klucza prywatnego dla określonych składników wiadomości. Nie potwierdza automatycznie tożsamości rzeczywistego operatora, uprawnienia do dostępu ani nieszkodliwego zachowania.

Trzy nagłówki o różnych zadaniach

Podstawą jest RFC 9421, opublikowany standard podpisów wiadomości HTTP. Signature-Agent wskazuje źródło publicznego klucza weryfikacyjnego. Signature-Input określa objęte podpisem składniki i parametry, na przykład czas utworzenia, wygaśnięcia oraz identyfikator klucza. Signature zawiera właściwą wartość podpisu.

Ed25519 jest jednym z używanych algorytmów, a nie ogólnym ograniczeniem RFC 9421. Weryfikacja wymaga algorytmu zgodnego z ustalonym profilem, wiarygodnie powiązanego klucza publicznego i identycznej podstawy podpisu. Nadawca podpisuje tajnym kluczem prywatnym, a odbiorca sprawdza wynik odpowiadającym mu kluczem publicznym. Podstawa podpisu to dokładny tekst złożony z objętych podpisem składników i parametrów. Weryfikacja nie tworzy nowego podpisu kluczem publicznym.

Projekt i profil produktu różnią się

Według stanu na 24 października 2026 r. IETF wykazuje draft-ietf-webbotauth-httpsig-protocol-00 z 1 września 2026 r. jako projekt grupy roboczej. Istnieje więc przyjęty projekt WG, ale profil nie jest jeszcze ukończonym RFC. Starszy projekt architektury został zastąpiony. Projekt WG wymaga słownikowej postaci Signature-Agent, natomiast aktualnie udokumentowana weryfikacja produktu Cloudflare nadal wymaga pojedynczego ciągu strukturalnego i odrzuca postać słownikową.

Poniższe wiersze porównują wyłącznie te formaty. To nie jest kompletne podpisane żądanie: celowo brakuje wartości podpisu, parametrów czasu i materiału kluczowego.

Projekt IETF WG 00 — element słownika:
Signature-Agent: sig="https://agent.example"
Podpisany składnik: "signature-agent";key="sig"

Udokumentowany profil Cloudflare — ciąg strukturalny:
Signature-Agent: "https://agent.example"
Podpisany składnik: "signature-agent"

Tryb katalogowy:
https://agent.example/.well-known/http-message-signatures-directory
Content-Type: application/http-message-signatures-directory+json

Stała ścieżka dotyczy trybu katalogowego. Aktualny projekt WG opisuje również inne mechanizmy odnajdywania kluczy. Integracja zależy od faktycznie obsługiwanego profilu, wersji i zasad rejestracji. Procedura Verified Bot w Cloudflare wymaga rejestracji; publikacja dowolnego klucza nie wystarcza.

Co faktycznie łączy poprawna weryfikacja

Bezpiecznie pobrany katalog HTTPS wiąże adres URL z opublikowanym kluczem. Pasujący podpis wiąże ten klucz z podpisanymi składnikami. Posiadacz klucza podpisującego i administrator domeny nie muszą być tą samą osobą lub organizacją. Powiązanie ze znaną firmą wymaga dodatkowych wiarygodnych informacji.

Sam identyfikator klucza również nie wystarcza: pamięć podręczna musi zachować zweryfikowane powiązanie adresu URL z kluczem. Użycie znanego klucza przy nowo zadeklarowanym adresie nie może tworzyć nowej tożsamości. Pobranie katalogu nie dowodzi zamiaru i nie zastępuje lokalnych zasad dostępu.

Zakres podpisu i ponowne użycie

Podpis obejmujący wyłącznie @authority i odwołanie do agenta nie wiąże metody, ścieżki ani treści wiadomości. Dopóki czas i pozostałe reguły weryfikacji pozwalają, skopiowane nagłówki mogą więc pasować do innych żądań kierowanych do tej samej authority (hosta wraz z ewentualnym portem). Nie dowodzi to wysłania każdego z tych żądań przez pierwotnego podpisującego.

Dodatkowe składniki, takie jak @method i @target-uri, zawężają ten zakres. Podpisany Content-Digest może objąć treść; odbiorca musi dodatkowo porównać skrót z faktycznie otrzymaną treścią. Nie wymaga to koniecznie buforowania całości w pamięci: skrót można obliczać przyrostowo, choć weryfikacja treści kończy się dopiero po ostatnim bajcie.

expires ogranicza czas ponownego użycia, lecz nie blokuje powtórzeń wewnątrz okna. Wartość nonce jest przeznaczona do jednorazowego użycia. Pomaga wykrywać skopiowane żądania tylko przy odpowiedniej strategii sprawdzania po stronie serwera. Cloudflare obecnie dokumentuje brak kontroli wcześniej użytych wartości nonce w bazie i zaleca krótki czas ważności.

Weryfikacja przed decyzją o dostępie

1. Strukturalne parsowanie zgodnie z obsługiwanym profilem oraz kontrola wymaganych składników, parametrów i dozwolonych algorytmów.
2. Bezpieczne pobranie klucza przez HTTPS, z dozwolonymi adresami, limitem rozmiaru odpowiedzi i czasu. Adresy kontrolowane przez klienta nie mogą udostępniać usług wewnętrznych. Aktualny projekt WG zabrania automatycznego podążania za przekierowaniami podczas odnajdywania kluczy.
3. Sprawdzenie powiązania URL–klucz, podstawy podpisu i podpisu kryptograficznego; kontrola czasu utworzenia, wygaśnięcia i dopuszczalnej różnicy zegarów.
4. Kontrola skrótu treści i powtórzeń zgodnie z wybranym profilem, a następnie zastosowanie lokalnych zasad dostępu, limitu żądań i logowania.

Sprawdzona biblioteka ogranicza błędy serializacji, ale nie zastępuje kontroli profilu, rotacji kluczy ani bezpiecznych zasad pamięci podręcznej. Niepoprawny i nieobsługiwany dowód pozostają osobnymi stanami; żaden z tych stanów nie oznacza automatycznie ruchu człowieka.