Content Security Policy za spletne klepetalnike: Varno odobrite gradnik, API, slike in pretakanje

Spletni klepetalnik v brskalniku redko sestoji le iz ene same datoteke JavaScript. Nalagalnik odpre gradnik (widget), API sprejema sporočila, odgovori se vračajo kot pretočni podatki (stream), profilne slike ali mediji pa morda gostujejo na drugi domeni. Content Security Policy (CSP) te poti naredi vidne in jih omeji: brskalnik naloži ali vzpostavi povezavo le z tistim, kar spletno mesto izrecno dovoljuje.

To je pomembna druga raven zaščite pred napadi Cross-Site Scripting in nepričakovano vsebino tretjih oseb. Vendar pa CSP ne popravi nesvarnega API-ja, manjkajoče avtentikacije, pomanjkljivega preverjanja vnosov ali napadov Prompt Injection. Zmanjšuje le možnosti za vrivanje kode in omejuje doseg napake. Zato je ključna čim manjša, preizkušena politika namesto dolgega seznama splošno odobrenih domen.

Zakaj gradniki klepetalnikov potrebujejo posebna pravila CSP

Pri klasični vsebinski strani pogosto zadostujejo viri z lastnega izvora. Klepetalnik pa po nalaganju komunicira naprej. connect-src med drugim nadzoruje fetch(), XMLHttpRequest, EventSource, WebSocket in sendBeacon(). Prav tu potekajo sporočila, pretočni odgovori, dogodki povratnih informacij in po potrebi telemetrija. Če manjka pravi izvor, se gradnik sicer prikaže, vendar ne more odgovoriti.

Drugi sestavni deli spadajo pod lastne direktive. script-src odloča o nalagalniku gradnika, img-src o avatarjih in slikah odgovorov, style-src o slogovnih predlogah in font-src o zunanjih pisavah. Gradnik, temelječ na iframe, dodatno potrebuje frame-src. default-src služi kot rezervna možnost za številne vrste virov, ki niso izrecno navedeni, vendar ne nadomešča premišljenega pregleda stanja.

Najpomembnejše pripravljalno delo se zato ne zgodi v generatorju CSP, temveč v brskalniku: odprite reprezentativno stran, začnite pogovor, pustite da se pretoči dolg odgovor, odprite vire, pošljite povratne informacije ter preizkusite primere napak in predaje (handoff). V podoknu za omrežje boste videli dejansko uporabljene izvorne domene (origins). Za vsak gostitelj dokumentirajte namen, vrsto vira in odgovorno osebo.

Ločena odobritev štirih pomembnih podatkovnih poti

1. Skripta gradnika in inicializacija

Nalagalnik po možnosti pridobite s stabilnega, verzioniranega naslova. Odobritev, kot je script-src https:, bi bila preširoka, saj bi s tem postala dopustna skripta s katere koli domene HTTPS. Namesto tega dovolite natančen izvor CDN ali pa nalagalnik strežite sami. Če integracija zahteva kodo inline, uporabite kodo nonce, ustvarjeno znova za vsak odgovor HTTP, ali ustrezno zgoščeno vrednost (hash). 'unsafe-inline' ne bi smel postati hitra trajna rešitev.

Koda nonce sodi le na skripte, ki jih ustvari strežniška predloga sama. Posredniška programska oprema (middleware), ki slepo doda isto kodo nonce vsaki obstoječi oznaki script, bi dala zaupanje tudi vrinjenim oznakam. Za statično, verzionirano zunanjo skripto lahko dodatno pomaga Subresource Integrity; pri datotekah, ki se pogosto spreminjajo, pa je treba zgoščeno vrednost nadzorovano posodabljati.

2. API, Server-Sent Events in WebSocket

Običajne zahteve POST in odgovor, pretočen preko fetch(), potrebujejo izvor HTTPS-API v connect-src. Sem spadajo tudi Server-Sent Events preko EventSource. Za WebSocket izrecno vnesite konkreten izvor wss://. MDN opozarja, da 'self' ne zajema samodejno shem WebSocket v vseh brskalnikih. Samostojna direktiva z imenom stream-src ne obstaja.

CSP in CORS rešujeta različne naloge. CSP določa, kam se stran sploh sme povezati; CORS pa na strani strežnika določa, kateri izvori smejo prebrati odgovor v brskalniku. Odobritev CSP zato ne odpravi napake CORS ali poteka veljavnosti dostopnega žetona. Posredniški strežnik z istim izvorom (Same-Origin-Proxy) lahko poenostavi politiko, vendar mora še naprej pravilno obravnavati avtentikacijo, omejitve hitrosti (rate limits), časovne prekoravitve in posredovanje napak.

3. Slike, avatarji in ustvarjeni mediji

V img-src dovolite le lasten izvor in dejansko uporabljen izvor medijev. data: je potreben le, če gradnik uporablja majhne vgrajene slike; blob: pa le, če brskalnik slike dejansko ustvari kot URL vrste Blob. Vsak dodatni vir poveča površino za napade. Če se slika najprej naloži s fetch() in nato pretvori v URL vrste Blob, sta lahko prizadeta tako connect-src kot img-src.

Ne preizkušajte le privzetega avatarja. Preverite predogledne slike, posnetke zaslona virov, priponke datotek, temni način (Dark Mode) in prikaz napak za nedostopne medije. Parametri URL lahko v poročila CSP vnesejo zaupne informacije; končne točke za poročanje morajo zato poročila obdelovati podatkovno varčno in jih ne smejo hraniti za nedoločen čas.

4. iframe, slogi, pisave in izbirni delavci (workers)

Gradnik, ki je vgrajen neposredno v DOM, običajno ne potrebuje zunanjega okvira. V tem primeru lahko ostane frame-src 'none'. Če pa klepet poteka v iframe, dovolite izključno njegov natančen izvor. Od tega je treba ločiti frame-ancestors: ta direktiva na posredovanem viru določa, katere strani ga smejo vgraditi. Ponudnik gradnika jo mora zato ustrezno nastaviti na svojem odgovoru iframe.

Pri slogih in pisavah velja enako načelo. Dovolite konkretne gostitelje in se izogibajte 'unsafe-inline', kolikor to dopušča integracija. Delavci (workers) ali zvočne funkcije se dodajo le, če jih izdelek resnično uporablja. Preventivna odobritev blob:, celotnih domen s wildcard znaki ali poljubnih medijskih virov otežuje kasnejše revizije.

Realističen primer CSP za gradnik klepetalnika

Naslednje domene so namerno rezervirane primerne domene. Zamenjajte jih z izvori iz vaše lastne analize omrežja. Primer predvideva zunanji nalagalnik, HTTPS-API, ločen WebSocket za pretakanje in medijskega gostitelja. Ne uporablja pa splošnih wildcard znakov:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://cdn.chat.example 'nonce-{RANDOM}';
  connect-src 'self' https://api.chat.example wss://stream.chat.example;
  img-src 'self' data: https://media.chat.example;
  style-src 'self' 'nonce-{RANDOM}';
  font-src 'self';
  frame-src 'none';
  worker-src 'self';
  object-src 'none';
  base-uri 'self';
  frame-ancestors 'self';
  form-action 'self';
  upgrade-insecure-requests;

{RANDOM} predstavlja močno vrednost, ustvarjeno znova za vsak odgovor, ki je enaka v glavi ter v dovoljenih elementih script oziroma style. Če vaš gradnik uporablja iframe, zamenjajte frame-src 'none' z natančnim izvorom gradnika. Če uporablja izključno pretakanje HTTPS preko fetch() ali EventSource, izvor WebSocket odpade. Odstranite vsak vir, ki po popolnem testu delovanja ni potreben.

Politika je praktična izhodiščna točka in ne univerzalna predloga. Sodobna stroga CSP lahko skripte še močneje nadzoruje preko vrednosti nonce ali hash in 'strict-dynamic'. Ali je to mogoče brez težav z združljivostjo, je odvisno od tega, kako nalagalnik ustvarja nadaljnje skripte. Ta potek razčistite s ponudnikom in preizkusite brskalnike, način privolitve (consent mode) ter različice namestitve.

Od načina le za poročanje (Report-Only) do uveljavljene politike

Nove politike ne vklopite nepreverjeno v produkciji. Mehanizem W3C Content-Security-Policy-Report-Only sporoča kršitve, ne da bi blokiral vire. Tako boste prepoznali pozabljene gostitelje slik, odstopajoč izvor pretakanja ali kodo inline, preden to vpliva na uporabnike. OWASP priporoča glavo HTTP kot prednostno pot dostave; v nasprotju z elementom meta podpira tudi celoten nabor funkcij.

1. Ustvarite popis: Preizkusite zagon gradnika, prvo sporočilo, dolg pretočni odgovor, vire, slike, povratne informacije, predajo (handoff) in spremembo privolitve na več vrstah strani.
2. Uvedite način Report-Only: Začnite s načrtovano strogo politiko in v omejenem obdobju zbirajte kršitve. Filtrirajte razširitve brskalnika in druge nemogoče ponovljive motilne signale.
3. Utemeljite vsakega gostitelja: Politiko razširite le, če konkretna funkcija izdelka potrebuje ta izvor. Izogibajte se znakom wildcard kot odzivu na posamezna sporočila.
4. Avtomatizirajte preizkušanje: Dodajte teste od konca do konca (End-to-End), ki pošljejo sporočilo, počakajo na pretakanje in naložijo sliko. Hkrati preverite konzolo brskalnika glede kršitev CSP.
5. Uveljavite in spremljajte: Aktivirajte glavo Content-Security-Policy, vzporedno spremljajte še strožjo različico Report-Only in primerjajte stopnje napak.

Postopna uvedba se dobro ujema s klepetalnikom v senčnem načinu (Shadow Mode). Za meritve, specifične za pretakanje, pomaga prispevek o okvirjih zakasnitev in časovnih prekoravitvah. Kršitve CSP morajo pri tem veljati kot samostojen signal: časovna prekoračitev in blokirana povezava zahtevata različni analizi vzrokov.

Tipične napake pri konfiguraciji

• Preširoki seznami virov: *, https: ali velika območja domen z znaki wildcard naredijo politiko udobno, vendar šibko in težko preverljivo.
• Testira se le vidni zagon: Gradnik se odpre, vendar pretakanje, povratne informacije, slike ali predaja spodletijo šele kasneje.
• 'unsafe-inline' ostane trajno: Kratkoročne pomoči za združljivost ne nadomestijo kode nonce, zgoščene vrednosti ali zunanja koda.
• Zamenjava CSP z nadzorom dostopa: Politika ne nadomešča pravic na strani strežnika, preverjanja seje in zaščite pred zlorabo klica orodij.
• Poročila vsebujejo preveč podatkov: Celotni URL-ji, parametri poizvedbe ali uporabniški kontekst po nepotrebnem dolgo ostajajo v sistemu za spremljanje.
• Razhajanje med razvojnim (staging) in produkcijskim okoljem: Različni gostitelji CDN, API ali WebSocket postanejo vidni šele po zagonu.

Tudi strog script-src ne naredi odobrenega zunanjega ponudnika samodejno varnega: njegov JavaScript deluje z zmožnostmi, ki mu jih daje vaša stran. Zato preverite spremembe ponudnikov, nove poddomene in posodobitve nalagalnikov enako kot druge varnostno pomembne odvisnosti. Prispevek o zaščiti pred napadi Prompt Injection dopolnjuje to mejo brskalnika s pravili za RAG, orodja in podatke.

Seznam za preverjanje pred zagonom

• Ali so vsi potrebni izvori dokumentirani iz resničnih sej brskalnika in strokovno utemeljeni?
• Ali script-src dovoljuje le nalagalnik in nadzorovane skripte brez splošnega 'unsafe-inline'?
• Ali connect-src vsebuje natančne izvirne domene HTTPS, EventSource in po potrebi WSS?
• Ali so viri slik, slogov, pisav, okvirov in delavcev ločeni ter definirani čim bolj strogo?
• Ali se kode nonce ustvarijo znova za vsak odgovor in se nastavijo le na zaupanja vredne elemente?
• Ali so bile preizkušene spremembe privolitve, dolgi stream-i, slike, napake, predaja ter namizne in mobilne naprave?
• Ali je bila politika najprej opazovana v načinu Report-Only in nato uveljavljena kot glava (header)?
• Ali se poročila CSP obdelujejo brez nepotrebnih osebnih ali zaupnih podatkov URL?
• Ali po posodobitvah gradnika ali infrastrukture obstaja avtomatiziran regresijski test?

Zaključek

Dobra CSP za spletne klepetalnike ni zbirka izjem, temveč tehnični zemljevid dovoljenih poti v brskalniku. Ločite nalagalnik, API, pretakanje, slike in vire iframe, dovolite natančne izvornih domene ter politiko najprej uvedite v načinu Report-Only. Tako gradnik ostane delujoč, medtem ko nepričakovane skripte in povezave dobijo občutno manj prostora.

Viri

• MDN: Content Security Policy (CSP)
• MDN: CSP direktiva connect-src
• W3C: Content Security Policy Level 3
• OWASP Cheat Sheet Series: Content Security Policy