Skryté riziko důvěry mezi uživatelským agentem
Mnoho webových aplikací, API a CI/CD Systémy stále důvěřují hlavičce User-Agent k identifikaci odesílatele požadavku, což je pozůstatek předpokladu z raných dob webu. Ale v Svět DevSecOps, tento předpoklad je nebezpečný. Bezpečnostní riziko pro agenta prohlížeče se objeví vždy, když kód, pipelineRozhraní API používají řetězce User-Agent k aplikaci logiky nebo vynucení bezpečnostních zásad. Například:
- Vytváření API může umožňovat požadavky pouze od „důvěryhodných agentů“.
- Repozitáře artefaktů mohou přidat na bílou listinu konkrétní uživatelské agenty.
- Bezpečnostní filtry mohou blokovat nebo omezovat počet požadavků na základě záhlaví.
Záhlaví User-Agent je ale jen řetězec, který může upravit jakýkoli útočník.
⚠️ Nezabezpečený příklad, pouze pro vzdělávací účely. Nepoužívejte v produkčním prostředí.
# Legitimate request curl -A "GitHubActions/1.0" https://internal-api.company.dev/build # Spoofed request curl -A "GitHubActions/1.0" https://internal-api.company.dev/build --data "inject=malicious"Pokud váš backend nebo pipeline Logika předpokládá, že řetězec User-Agent identifikuje důvěryhodný zdroj, a proto jste již vytvořili bezpečnostní riziko pro agenta prohlížeče, které může vést k narušení dodavatelského řetězce.
Jak funguje User-Agent Spoofing v praxi
Spoofer uživatelského agenta může být něco tak jednoduchého jako rozšíření prohlížeče, upravený HTTP klient nebo automatizovaný bot nakonfigurovaný tak, aby napodoboval legitimní provoz sestavení.
Útočníci používají falšování uživatelských agentů k:
- Obejít filtry přístupu v API, která důvěřují konkrétním hlavičkám
- Zosobnění systémů sestavení (např. Jenkins, GitHub Actions nebo GitLab Runners)
- Obcházení limitů rychlosti nebo nástrojů pro analýzu zabezpečení
- Spouštět akce backendu vyhrazené pro „autorizované“ agenty.
Příklad zneužití:
# ❌ Insecure filter logic if request.headers["User-Agent"] == "Jenkins/2.0": allow_build_upload() Bezpečná verze:
# Secure approach if verify_api_token(request.headers["Authorization"]) and verify_signature(request.body): allow_build_upload() # Authenticated and verified source only Falšování uživatelského agenta je triviální; ověření skutečné identity nikoli.
Skutečná bezpečnostní rizika pro prohlížečové agenty v CI/CD a dodavatelské řetězce
Bezpečnostní riziko pro agenta prohlížeče se stává kritickým, když ovlivňuje infrastrukturu sestavení nebo doručování artefaktů. pipelines. v CI/CD V různých prostředích požadavky často přicházejí od automatizovaných agentů a útočníci tuto hranici důvěryhodnosti zneužívají. Mezi skutečné příklady patří:
- Falešné požadavky na sestavení do registrů artefaktů
- Zneužívání zrcadla závislosti
- Pipeline zosobnění
⚠️ Následující úryvek je pouze pro vzdělávací účely. Nekopírujte jej v produkčním prostředí.
# ❌ Insecure dependency proxy trusting user-agent if: contains(github.event.request.headers.user-agent, 'GitHubActions') run: npm publish --registry=https://internal.artifacts.local Bezpečná verze:
# Secure: verify request signature and runner identity if: xygeni verify --source trusted-runner --signature artifact.sig run: npm publish --registry=https://internal.artifacts.local Jeden falešný požadavek by mohl vnést škodlivou závislost přímo do produkčního prostředí. pipelines – ukázkový příklad bezpečnostního rizika pro prohlížečové agenty, které vede k narušení dodavatelského řetězce.
Proč základní ověření hlaviček jako bezpečnostní kontrola selhává
Vývojáři se někdy spoléhají na filtry regulárních výrazů založené na hlavičkách nebo statické seznamy povolených položek k ověřování požadavků agentů. To bohužel nenabízí žádnou ochranu před falšováním uživatelských agentů. Statické kontroly, jako například:
if (/GitHubActions/i.test(req.headers['user-agent'])) { allowAccess(); } ⚠️ Ověřování založené na regulárních výrazech není ověřování. Kterýkoli útočník může napodobit očekávaný vzorec pomocí falešného řetězce User-Agent.
Lze triviálně obejít pomocí:
curl -A "Fake-GitHubActions" https://target-api.dev Tento druh logiky vede k falešné důvěře a vysokému bezpečnostnímu riziku pro prohlížečové agenty, protože nic nedokazuje, že odesílatel je tím, za koho se vydává.
Posílení validace pomocí podepsaných požadavků a integrity artefaktů – vyhněte se bezpečnostnímu riziku pro prohlížečové agenty
Místo důvěřování hodnotám User-Agent by vývojáři měli ověřovat zdroj každého požadavku pomocí kryptografického a kontextového ověření. Mezi klíčové strategie pro zmírnění bezpečnostních rizik pro prohlížečové agenty patří:
- Vzájemné TLS (mTLS)
- Podepsaná metadata nebo požadavky (AWS SigV4, HMAC, JWT)
- Podepisování a ověřování artefaktů
- Tokeny API s omezeným rozsahem
- Ověřování mimo pásmo
⚠️ Níže uvedený příklad slouží pouze pro vzdělávací účely. Zajistěte bezpečné zacházení s klíči a jejich ověřování.
# ✅ Secure artifact upload with signature validation upload: script: - gpg --verify artifact.sig artifact.tar.gz - xygeni verify --artifact artifact.tar.gz --source trusted-runner Tyto kroky zajišťují, že i když spoofer uživatelského agenta napodobuje důvěryhodnou hlavičku, systém odmítne neověřený nebo nepodepsaný provoz.
Integrace detekce a prevence do DevSecOps Pipelines
Detekce falšování uživatelských agentů by měla být součástí vašeho CI/CD telemetrie a průběžné ověřování.
Týmy DevSecOps lze vkládat ovládací prvky, jako například:
- Automatické ověření požadavku
- Korelace telemetrie
- Detekce anomálií
- Vymáhání kontextových zásad
validate_request: script: - xygeni scan --detect-user-agent-spoofing - xygeni enforce --trusted-sources policy.yaml Praktické zábradlí CI:
# CI guardrail: reject unsigned or unverified requests if ! xygeni verify --request-signature; then echo "Unverified request — potential user-agent spoofing detected" && exit 1 fi Kombinace detekce a vynucování zásad zajišťuje, že bezpečnostní rizika agentů prohlížeče neohrozí vaše pipelinenebo distribuce artefaktů.
Nevěřte záhlaví, ověřte zdroj
Každý User-Agent Záhlaví může lhát. Každý falšovatel uživatelského agenta může předstírat legitimitu. A každé bezpečnostní riziko pro prohlížečového agenta pramení z důvěry v něco, co nebylo ověřeno. Oprava nespočívá v odstranění hlavičky, ale v tom, že jí nebudete důvěřovat pro ověřování nebo vynucování zásad. Místo toho implementujte podepsané požadavky, vynuťte ověřování identity a sledovat svůj CI/CD provoz pro falšování vzorů.
Nástroje jako Xygeni pomáhat týmům DevSecOps odhalovat falešné požadavky na sestavení, ověřovat důvěryhodné zdroje a chránit CI/CD dodavatelského řetězce před falšováním uživatelských agentů a souvisejícími hrozbami pro integritu. Nespoléhejte se na domněnky, ověřte si každý zdroj.
