Saturs Drošības Politika (CSP) tīmekļa vietņu tērzēšanas robotiem: droša logrīka, API, attēlu un straumēšanas atļaušana

Tīmekļa vietnes tērzēšanas robota darbs pārlūkprogrammā reti sastāv tikai no viena JavaScript faila. Ielādētājs atver logrīku, API pieņem ziņojumus, atbildes tiek saņemtas kā straume, un profila attēli vai mediju faili var atrasties citā domēnā. Saturs Drošības Politika (CSP) padara šos ceļus pārredzamus un ierobežo tos: pārlūkprogramma ielādē vai izveido savienojumu tikai ar to, ko tīmekļa vietne ir skaidri atļāvusi.

Tas ir svarīgs otrais aizsardzības slānis pret starpvietņu skriptēšanu (XSS) un negaidītu trešo pušu saturu. Tomēr CSP nenovērš nedroša API, trūkstošas autentifikācijas, nepilnīgas ievades validācijas vai Prompt Injection radītās problēmas. Tā samazina iesūtītā koda iespējas un ierobežo kļūdas ietekmes rādiusu. Tāpēc izšķiroša nozīme ir iespējami šaurai, pārbaudītai politikai, nevis ilgam vispārīgi atļautu domēnu sarakstam.

Kāpēc tērzēšanas robotu logrīkiem ir nepieciešami īpaši CSP noteikumi

Klasiskai satura lapai bieži vien pietiek ar resursiem no tās pašas izcelsmes (origin). Turpretim tērzēšanas robots pēc ielādes turpina sazināties. connect-src cita starpā pārvalda fetch(), XMLHttpRequest, EventSource, WebSocket un sendBeacon(). Tieši šeit norit ziņojumu apmaiņa, straumēšanas atbildes, atsauksmju notikumi un, ja nepieciešams, telemetrija. Ja trūkst pareizās izcelsmes, logrīks parādīsies, bet nespēs atbildēt.

Citi komponenti ietilpst atsevišķās direktīvās. script-src nosaka logrīka ielādētāju, img-src — avatarus un atbilžu attēlus, style-src — stila lapas un font-src — ārējos fontus. Uz iframe balstītam logrīkam papildus nepieciešams frame-src. default-src kalpo kā rezerves risinājums daudziem skaidri nenorādītiem resursu veidiem, taču neaizstāj apzinātu resursu inventarizāciju.

Svarīgākais priekšdarbs tāpēc notiek nevis CSP ģeneratorā, bet pārlūkprogrammā: atveriet reprezentatīvu lapu, sāciet sarunu, straumējiet garu atbildi, atveriet avotus, nosūtiet atsauksmes un pārbaudiet kļūdu un nodeves (handoff) gadījumus. Tīkla paneļa (Network) sadaļā redzēsiet faktiski uzrunātās izcelsmes. Dokumentējiet katra resursa mērķi, veidu un atbildīgo personu.

Četru būtisko datu ceļu atsevišķa atļaušana

1. Logrīka skripts un inicializācija

Iegūstiet ielādētāju no stabilas adrese ar versijām. Atļauja, piemēram, script-src https:, būtu pārāk plaša, jo tā pieļautu skriptus no jebkura HTTPS domēna. Tā vietā atļaujiet precīzu CDN izcelsmi vai nodrošiniet ielādētāja atrašanos savā serverī. Ja integrācijai nepieciešams iebūvēts (inline) kods, izmantojiet katrā HTTP atbildē no jauna ģenerētu nonce vai atbilstošu jauciņu (hash). 'unsafe-inline' nedrīkst kļūt par ātru ilgtermiņa risinājumu.

Nonce jāpievieno tikai tiem skriptiem, kurus ģenerē pats servera puses veidne. Starpprogrammatūra (middleware), kas aklai katram esošajam skripta tagam pievieno vienu un to pašu nonce, nodrošinātu uzticību arī iesūtītiem tagiem. Statiskam, versiju pārvaldītam trešās puses skriptam papildus var palīdzēt Subresource Integrity; tomēr bieži mainīgu failu gadījumā jauciņš ir regulāri jāatjaunina.

2. API, Server-Sent Events un WebSocket

Parastiem POST pieprasījumiem un atbildei, kas tiek straumēta, izmantojot fetch(), connect-src direktīvā ir nepieciešama HTTPS API izcelsme. Tas attiecas arī uz Server-Sent Events, izmantojot EventSource. WebSocket gadījumā skaidri ierakstiet konkrēto wss:// izcelsmi. MDN norāda, ka 'self' ne visās pārlūkprogrammās automātiski ietver WebSocket shēmas. Atsevišķas direktīvas ar nosaukumu stream-src nav.

CSP un CORS risina dažādus uzdevumus. CSP nosaka, kurp lapa vispār drīkst izveidot savienojumu; CORS servera pusē nosaka, kuras izcelsmes drīkst lasīt atbildi pārlūkprogrammā. Tāpēc CSP atļauja nenovērš CORS kļūdu vai beigušos piekļuves žetonu (access token). Tās pašas izcelsmes starpniekserveris (Same-Origin proxy) var vienkāršot politiku, taču tam joprojām pareizi jāapstrādā autentifikācija, ātruma ierobežojumi (rate limits), noildzes un kļūdu tālāka nodošana.

3. Attēli, avatari un ģenerētie mediji

Iekš img-src atļaujiet tikai savu izcelsmi un faktiski izmantoto mediju izcelsmi. data: ir nepieciešams tikai tad, ja logrīks izmanto mazus iebūvētus attēlus; blob: tikai tad, ja pārlūkprogramma faktiski ģenerē attēlus kā Blob URL. Katrs papildu avots palielina uzbrukuma virsmu. Ja attēls vispirms tiek ielādēts, izmantojot fetch(), un pēc tam pārvērsts par Blob URL, tas var ietekmēt gan connect-src, gan img-src.

Pārbaudiet ne tikai standarta avataru. Pārbaudiet priekšskatījuma attēlus, avotu ekrānuzņēmumus, failu pielikumus, tumšo režīmu un kļūdu attēlojumu pieejamiem medijiem. URL parametri CSP ziņojumos var nodot konfidenciālu informāciju; tāpēc ziņošanas galapunktiem ziņojumi jāapstrādā, ievērojot datu minimizēšanu, un tie nedrīkst tikt uzglabāti bezgalīgi.

4. iframe, stili, fonti un izvēles Worker skripti

Tieši DOM iebūvētam logrīkam visbiežāk nav nepieciešams ārējs rāmis. Tādā gadījumā var palikt frame-src 'none'. Ja tērzēšanas robots darbojas iframe ietvaros, atļaujiet tikai tā precīzo izcelsmi. No tā jānošķir frame-ancestors: šī direktīva piegādātajā resursā nosaka, kuras lapas drīkst to ietvert. Tāpēc logrīka pakalpojumu sniedzējam tā atbilstoši jāiestata savā iframe atbildē.

Stiliem un fontiem galds tas pats princips. Atļaujiet konkrētus resursdatorus un izvairieties no 'unsafe-inline', ciktāl integrācija to pieļauj. Worker vai audio funkcijas tiek pievienotas tikai tad, ja produkts tās patiešām izmanto. Piesardzīga blob:, pilnu aizstājējzīmju domēnu vai jebkuru mediju avotu atļaušana apgrūtina turpmākos auditus.

Reālistisks CSP piemērs tērzēšanas robota logrīkam

Tālāk norādītie domēni ir apzināti rezervēti paraugdomēni. Aizstājiet tos ar izcelsmes adresēm no savas tīkla analīzes. Piemērā pieņemts, ka tiek izmantots ārējs ielādētājs, HTTPS API, atsevišķs WebSocket straumēšanai un mediju resursdators. Tālāk nav izmantotas vispārīgas aizstājējzīmes:

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} apzīmē spēcīgu, katrā atbildē no jauna ģenerētu vērtību, kas ir identiska glvenes (header) daļā un atļautajos skriptu vai stilu elementos. Ja jūsu logrīks izmanto iframe, aizstājiet frame-src 'none' ar precīzu logrīka izcelsmi. Ja tas izmanto tikai HTTPS straumēšanu caur fetch() vai EventSource, WebSocket izcelsme nav nepieciešama. Noņemiet katru avotu, kas pēc pilnīgas funkcionālās pārbaudes izrādās nevajadzīgs.

Šī politika ir praktisks sākumpunkts, nevis universāla veidne. Mūsdienīga stingra CSP var vēl vairāk kontrolēt skriptus, izmantojot nonces vai jauciņus un 'strict-dynamic'. Vai tas ir iespējams bez saderības problēmām, ir atkarīgs no tā, kā ielādētājs ģenerē turpmākos skriptus. Noskaidrojiet šo procesu ar pakalpojuma sniedzēju un pārbaudiet pārlūkprogrammas, piekrišanas režīmu (Consent Mode) un izvietošanas variantus.

Pāreja no Report-Only uz piespiedu politiku

Neieviesiet jaunu politiku darbībā nepārbaudītu. W3C mehānisms Content-Security-Policy-Report-Only ziņo par pārkāpumiem, nebloķējot resursus. Šādi varat pamanīt aizmirstus attēlu resursdatorus, atšķirīgu straumēšanas izcelsmi vai iebūvēto kodu, pirms tas ietekmē lietotājus. OWASP iesaka HTTP galveni kā vēlamo piegādes veidu; atšķirībā no meta elementa tā atbalsta arī pilnu funkciju klāstu.

1. Izveidojiet inventāru: Pārbaudiet logrīka palaišanu, pirmo ziņojumu, garu straumēšanas atbildi, avotus, attēlus, atsauksmes, nodevi (handoff) un piekrišanas maiņu vairākos lapu veidos.
2. Ieviesiet Report-Only: Sāciet ar plānoto šauro politiku un apkopojiet pārkāpumus noteiktā laika periodā. Filtrējiet pārlūkprogrammas paplašinājumus un citus nenovēršamus traucējumu signālus.
3. Pamatojiet katru resursdatoru: Paplašiniet politiku tikai tad, ja konkrēta produkta funkcija pieprasa šo izcelsmi. Izvairieties no aizstājējzīmēm kā reakcijas uz atsevišķiem ziņojumiem.
4. Pārbaudiet automatizēti: Pievienojiet gala-līdz-galam (End-to-End) testus, kas nosūta ziņojumu, sagaida straumēšanu un ielādē attēlu. Vienlaikus pārbaudiet pārlūkprogrammas konsoli, vai tajā nav CSP pārkāpumu.
5. Pieprasiet izpildi un novērojiet: Aktivizējiet Content-Security-Policy galveni, paralēli sekojiet līdzi vēl stingrākam Report-Only variantam un salīdziniet kļūdu biežumu.

Pakāpeniska ieviešana labi sader ar tērzēšanas robotu ēnas režīmā (Shadow Mode). Straumēšanai specifiskiem mērījumiem noderēs raksts par latences budžetiem un noildzēm. CSP pārkāpumus vajadzētu uzskatīt par atsevišķu signālu: noildzei un bloķētam savienojumam ir nepieciešama atšķirīga cēloņu analīze.

Tipiskas kļūdainas konfigurācijas

• Pārāk plaši avotu saraksti: *, https: vai lieli aizstājējzīmju domēni padara politiku ērtu, bet vāju un grūti pārbaudāmu.
• Tiek pārbaudīts tikai redzamais sākums: Logrīks atveras, bet straumēšana, atsauksmes, attēli vai nodeve vēlāk neizdodas.
• 'unsafe-inline' paliek uz visiem laikiem: Īstermiņa saderības palīglīdzeklis netiek aizstāts ar nonces, jauciņiem vai ārējo kodu.
• CSP tiek jaukta ar piekļuves kontroli: Politika neaizstāj servera puses tiesības, sesiju pārbaudi un aizsardzību pret ļaunprātīgiem rīku izsaukumiem.
• Ziņojumos ir pārāk daudz datu: Pilni URL, vaicājuma parametri vai lietotāja konteksts nevajadzīgi ilgi paliek pārraudzībā.
• Testēšanas (staging) un produkcijas vide atšķiras: Dažādi CDN, API vai WebSocket resursdatori kļūst redzami tikai pēc palaišanas darbībā (Go-live).

Arī šaurs script-src automātiski nepadara atļauto trešo pusi drošu: tās JavaScript darbojas ar iespējām, ko sniedz jūsu lapa. Tāpēc pārbaudiet pakalpojumu sniedzēju maiņu, jaunus apakšdomēnus un ielādētāja atjauninājumus kā citas drošībai svarīgas atkarības. Raksts par Prompt Injection aizsardzību papildina šo pārlūkprogrammas robežu ar noteikumiem RAG, rīkiem un datiem.

Pārbaudes saraksts pirms palaišanas darbībā

• Vai visas nepieciešamās izcelsmes no reālām pārlūkprogrammas sesijām ir dokumentētas un nozares ziņā pamatotas?
• Vai script-src atļauj tikai ielādētāju un kontrolētus skriptus, bez vispārēja 'unsafe-inline'?
• Vai connect-src satur precīzas HTTPS, EventSource un, ja nepieciešams, WSS izcelsmes?
• Vai attēlu, stilu, fontu, rāmju un Worker avoti ir nošķirti un definēti pēc iespējas šaurāk?
• Vai nonces tiek ģenerēti no jauna katrai atbildei un pievienoti tikai uzticamiem elementiem?
• Vai ir pārbaudītas piekrišanas izmaiņas, garas straumes, attēli, kļūdas, nodeve, kā arī darbvirsmas un mobilās ierīces?
• Vai politika vispirms tika novērota Report-Only režīmā un pēc tam piemērota kā obligāta galvene?
• Vai CSP ziņojumi tiek apstrādāti bez nevajadzīgiem personas datiem vai konfidenciāliem URL datiem?
• Vai pēc logrīka vai infrastruktūras atjauninājumiem ir paredzēts automatizēts regresijas tests?

Secinājums

Laba CSP tīmekļa vietņu tērzēšanas robotiem nav izņēmumu krājums, bet gan atļauto pārlūkprogrammas ceļu tehniskā karte. Nošķiriet ielādētāja, API, straumēšanas, attēlu un iframe resursus, atļaujiet precīzas izcelsmes un vispirms ieviesiet politiku Report-Only režīmā. Tādējādi logrīks saglabās funkcionalitāti, savukārt negaidītiem skriptiem un savienojumiem būs būtiski mazāk darbības iespēju.

Avoti

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