English
Deutsch
PolskiWeb Bot Auth: jak podpisywane są żądania agentów i co dowodzi podpis
Spis treści
Przeglądarka agentowa wygląda w raporcie analitycznym jak człowiek, bo jest prawdziwym silnikiem przeglądarki. Pytanie, kto właściwie pyta, da się z zachowania tylko oszacować – albo odpowiedzieć na nie od strony przeciwnej, przez podpisanie.
Właśnie tym jest Web Bot Auth. Mechanizm jest krótki, kryptografia niespektakularna, a najciekawsze w nim jest to, czego wyraźnie nie dowodzi.
Co leży na łączu
Podstawą jest RFC 9421, podpisy wiadomości HTTP. Operator agenta tworzy parę kluczy Ed25519, publikuje część publiczną jako zestaw kluczy JSON pod ustaloną ścieżką w domenie, którą kontroluje, i podpisuje każde wychodzące żądanie. Wynik niosą trzy nagłówki.
Signature-Agent: "https://przyklad-agent.pl"
Signature-Input: sig=("@authority" "signature-agent");
created=1700000000;
expires=1700011111;
keyid="poqkLGiymh_W0uP6PZFw-dvez3QJT5SolqXBCW38r0U";
tag="web-bot-auth"
Signature: sig=jdq0SqOwHdyHr9+r5jw3iYZH6aNGKijYp/EstF4RQTQdi5N5YYKrD+mCT1HA1nZD…
katalog /.well-known/http-message-signatures-directory
typ treści application/http-message-signatures-directory+json
Nawias po sig= nazywa to, co jest podpisane. Tu są to dwa
składniki: host docelowy i wskazanie katalogu.Weryfikator czyta Signature-Agent, pobiera stamtąd katalog, szuka w nim klucza wskazanego przez keyid, odtwarza podstawę podpisu ze składników nazwanych w Signature-Input i przelicza podpis.
Czego podpis dowodzi
Dwóch rzeczy, i obie są mocne. Po pierwsze: kto go wytworzył, posiada klucz prywatny do publicznego opublikowanego pod określoną domeną. Po drugie: kontroluje tę domenę, bo inaczej nie mógłby tam nic złożyć. Razem daje to sprawdzalne pochodzenie, a to więcej, niż ciąg w user agencie kiedykolwiek stanowił.
Dochodzi do tego zamiennik ochrony przed powtórzeniem: expires ogranicza ważność, a podpis przedstawiony po tej chwili zostaje odrzucony. Przechwycone żądanie nie da się zatem używać dowolnie długo.
Czego nie dowodzi
Podpis obejmuje składniki nazwane, w opublikowanym przykładzie host docelowy i wskazanie katalogu. Treści żądania nie obejmuje, a o zamiarze nie mówi nic. Dowodzi tożsamości, nie zachowania.
Ważny podpis nie jest zatem pozwoleniem. Czysto podpisany agent może zebrać tę samą treść co niepodpisany, tylko dowodliwie. Zysk leży nie w obronie, lecz w przypisywalności: kto wie, który operator pytał, może ustawić regułę na operatora – a w sporze udowodnić, kto tam był.
Jak da się to sprawdzić
Sprawdzenie jest ogarnialne i warte przejścia jako ćwiczenie, bo pokazuje granice metody wprost. Cztery kroki: odczytać Signature-Agent i sprawdzić wobec oczekiwanej domeny; pobrać katalog pod ustaloną ścieżką i wyszukać klucz do keyid; złożyć podstawę podpisu ze składników nazwanych w Signature-Input, w podanej kolejności; przeliczyć weryfikację Ed25519 i zestawić expires z własnym zegarem.
Krok trzeci jest tym, na którym własne wdrożenia się wykładają, bo podstawa podpisu musi zgadzać się bajt w bajt. Kto zbuduje ją raz ręcznie, ten rozumie potem także, dlaczego treść nie jest podpisywana razem z nią: musiałaby zostać w całości zbuforowana, zanim rozpocznie się pierwsze sprawdzenie.
Stan rzeczy, nazwany uczciwie
Obie specyfikacje są projektami internetowymi – architektura i katalog, ten drugi w piątej wersji. Grupa robocza IETF zajmuje się tym od początku 2026, przyjętego dokumentu nie ma, a projekty jak najbardziej zmieniają jeszcze nazwy nagłówków i ścieżki.
Jednocześnie kilku dużych dostawców sieciowych i bezpieczeństwa sprawdza te podpisy już w ruchu produkcyjnym. Dla pojedynczej witryny znaczy to: zrozumieć tak, polegać jeszcze nie. A zdanie, które trzeba dopowiadać sobie przy czytaniu zapowiedzi, stoi na obrazku jako krawędź przerywana – podpis dowodzi, kto pyta, i nigdy tego, co zamierza.
Pytania i odpowiedzi
Czy da się po prostu wpisać w nagłówek Signature-Agent domenę znanego operatora?
Wpisać tak, przejść weryfikację już nie. Sprawdzenie pobiera klucz z katalogu właśnie tej domeny, a bez pasującego klucza prywatnego weryfikacja Ed25519 się nie powiedzie. Ponieważ sam Signature-Agent należy do podpisanych składników, nie da się go też później zamienić na inną domenę.
Czy przechwyconego, ważnego podpisu da się użyć ponownie przed upływem expires?
W tym oknie czasowym co do zasady tak. expires jest tylko zamiennikiem ochrony przed powtórzeniem: ogranicza czas ważności podpisu, ale nie przeszkadza w tym, by ten sam podpis przedstawić w tym czasie kilka razy. W przykładzie created i expires dzieli 11 111 sekund, czyli nieco ponad trzy godziny.
Do tego dochodzi pytanie, co jest podpisane. W przykładzie tylko host docelowy i wskazanie katalogu, a nie ścieżka, metoda ani treść. Kto zna trzy nagłówki takiego żądania, może je więc w tym czasie dołączyć także do innego adresu na tym samym hoście, a sprawdzenie i tak się powiedzie.
W praktyce wymaga to, by nagłówki w ogóle trafiły w obce ręce. Przez HTTPS są na łączu zaszyfrowane, ale widać je wszędzie tam, gdzie kończy się TLS, na przykład w CDN albo w odwrotnym proxy, oraz w logach zapisujących nagłówki. Dla reguły na operatora oznacza to, że ważny podpis dowodzi, iż operator wytworzył te nagłówki, ale niekoniecznie, że wysłał właśnie to żądanie.
Czy Web Bot Auth pomaga odfiltrować agentów z raportu analitycznego?
Tylko tam, dokąd docierają nagłówki żądania. Podpis stoi w nagłówkach żądania HTTP, a te widzi serwer, stojący przed nim CDN albo log serwera. Tag pomiarowy działający w przeglądarce jako JavaScript nie może odczytać nagłówków żądania, którym wczytano jego własną stronę, więc przeglądarka agentowa liczy się tam nadal jak człowiek.
Rozróżnienie w raporcie wymaga więc decyzji na serwerze: przeprowadzenia tam sprawdzenia i przekazania jego wyniku dalej, na przykład jako znacznika, który strona przekazuje tagowi, albo pomiaru bezpośrednio na serwerze. Zakłada to, że agent w ogóle podpisuje; agenci bez podpisu pozostają tak samo niewidoczni jak wcześniej.
Powiązane artykuły
