Divi drošības slāņi, kuriem jāsaskan

Content Security Policy (CSP) pārlūkam norāda, no kādiem avotiem lapa drīkst ielādēt skriptus, stilus, attēlus, kadrus un tīkla pieprasījumus. Piekrišanas pārvaldības platforma dara pretējo: tā, balstoties uz lietotāja izvēli, nosaka, kuriem no šiem skriptiem atļauts darboties. Ja abas tiek konfigurētas atsevišķi, tās saduras. CMP neielādējas, jo CSP to bloķē, vai arī CSP tiek tik ļoti atslābināta, lai pielāgotos CMP un reklāmu tagiem, ka tā vairs neko neaizsargā.

Šajā ceļvedī paskaidrots, kādas CSP direktīvas CMP parasti nepieciešamas, kā nonce mijiedarbojas ar skriptu ievietošanu un kā ieviest izmaiņas, nesalaužot baneri.

Ko CMP parasti vajag no CSP

Precīzas prasības ir atkarīgas no pārdevēja, tāpēc vienmēr sāciet ar sava CMP dokumentāciju. Vispārīgi pārbaudiet šīs direktīvas:

• script-src — domēns, no kura ielādējas CMP skripts, kā arī visi papildu skriptu faili, ko tas ielādē.
• connect-src — galapunkti, kurus CMP izsauc ar fetch vai XHR, piemēram, konfigurācijas, pārdevēju saraksta, ģeolokācijas un piekrišanas reģistrēšanas galapunkti.
• style-src — stilu lapu domēns un, iespējams, inline stili, ja CMP ievieto <style> elementu vai iestata stila atribūtus.
• img-src — logotipi, ikonas un visi izsekošanas brīvie pikseļi, ko izmanto CMP.
• font-src — ja baneris ielādē savus fontus.
• frame-src — ja CMP izmanto iframe, piemēram, piekrišanas koplietošanai starp domēniem.

TCF vietnēs atcerieties, ka CMP lapā izveido arī lokatora kadru ar nosaukumu __tcfapiLocator. Šis kadrs tiek izveidots bez attāla avota, tāpēc tam parasti nevajag frame-src ieraksta, taču to ir vērts apstiprināt testēšanā.

Inline stub problēma

Lielākā daļa CMP lūdz lapas head ievietot nelielu inline skriptu — stub —, lai citi skripti varētu ievietot izsaukumus rindā, pirms ielādējas galvenais CMP. Stingra CSP bloķē inline skriptus, ja tos skaidri neatļaujat. Jums ir trīs iespējas:

1. Nonce. Ģenerējiet nejaušu vērtību katrai atbildei, pievienojiet to CSP galvenei kā 'nonce-...' un stub <script> tagam. Tā ir elastīgākā iespēja dinamiskām lapām.
2. Hash. Pievienojiet stub precīza satura SHA-256 jaucējkodu direktīvai script-src. Tas labi darbojas statiskām vietnēm, taču jebkura stub izmaiņa, pat atstarpe, to salauž.
3. Stub pašmitināšana kā ārējs fails jūsu pašu domēnā, ko aptver 'self'. Tas prasa uzmanību, lai tas joprojām ielādētos pietiekami agri.

Izvairieties no 'unsafe-inline' kā īsceļa. Tas atļauj katru inline skriptu, kas novērš lielu daļu aizsardzības, ko sniedz CSP.

Nonce un skripti, ko ievieto CMP

CMP, kas bloķē skriptus līdz piekrišanai, bieži darbojas, tos aizturot un vēlāk ievietojot. Uz nonce balstītā CSP arī šiem ievietotajiem skriptiem jābūt atļautiem. Ir divas izplatītas pieejas:

• Nonce pārnese. CMP nolasa nonce no sava skripta taga un pievieno to katram ievietotajam skriptam. Pārbaudiet, vai jūsu CMP to atbalsta.
• 'strict-dynamic'. Šis atslēgvārds norāda atbalstošiem pārlūkiem uzticēties skriptiem, ko ielādējis jau uzticams skripts. Tas atvieglo dzīvi ar tagu pārvaldniekiem un CMP, kas ievieto skriptus, taču tas arī nozīmē, ka jebkurš skripts, kuram uzticaties, var ielādēt citus, tāpēc uzticieties piesardzīgi.

Tagu pārvaldnieki rada to pašu jautājumu. Ja reklāmu un analītikas tagus ielādējat caur tagu pārvaldnieku, sekojiet tā dokumentācijai par nonce un pārliecinieties, ka CMP un tagu pārvaldnieks izmanto konsekventu pieeju.

Reklāmu tagi sarežģī CSP

Programmatiskā reklāma ielādē skriptus un kadrus no daudziem domēniem, un saraksts mainās līdz ar pieprasījuma partneriem. Izdevēji parasti izdara vienu no divām izvēlēm:

• Stingra CSP lapās bez programmatiskajām reklāmām un plašāka politika tur, kur reklāmas darbojas.
• Politika, kas vērsta uz direktīvām, kuras joprojām ir pārvaldāmas, piemēram, frame-ancestors, object-src 'none' un base-uri, kamēr skriptu avoti paliek plašāki.

Jebkurā gadījumā CMP jābūt skaidri atļauto sarakstā, nevis tikai aptvertam ar aizstājējzīmi, lai CSP izmaiņas nekad klusām neatspējotu baneri.

Ieviešana ar report-only režīmu

Vispirms izmantojiet galveni Content-Security-Policy-Report-Only. Pārlūks ziņo par pārkāpumiem, neko nebloķējot, tāpēc varat redzēt, ko jaunā politika salauztu.

1. Izvietojiet politiku report-only režīmā ar atskaišu galapunktu.
2. Ielādējiet lapas tīros pārlūka profilos un izejiet cauri visai piekrišanas plūsmai: pirmais apmeklējums, pieņemt visu, noraidīt visu, pielāgota izvēle, atsaukšana.
3. Pārskatiet pārkāpumu atskaites un pārlūka konsoli, meklējot bloķētus CMP resursus.
4. Pielāgojiet politiku, pēc tam pārslēdzieties uz izpildi.
5. Atstājiet atskaites ieslēgtas arī pēc izpildes, lai pamanītu regresijas.

CSP konflikta simptomi

• Baneris nekad neparādās, un konsolē ir CSP pārkāpums CMP skriptam.
• Baneris parādās, bet bez stiliem, jo style-src bloķē tā CSS.
• Izvēles netiek saglabātas, jo connect-src bloķē piekrišanas reģistrēšanas izsaukumu.
• Reklāmas vai analītika pēc piekrišanas nekad neielādējas, jo ievietotajiem skriptiem trūkst nonce.
• __tcfapi nav definēts, jo inline stub tika bloķēts.

Galvenie secinājumi

• Savam CMP pārbaudiet script-src, connect-src, style-src, img-src un frame-src.
• Inline stub atļaujiet ar nonce vai hash, nevis ar 'unsafe-inline'.
• Nodrošiniet, lai skripti, kas ievietoti pēc piekrišanas, saņem nonce vai tos aptver 'strict-dynamic'.
• Pirms izpildes ieviešanas pārbaudiet katru piekrišanas ceļu report-only režīmā.
• Turiet CMP skaidri atļauto sarakstā, lai CSP izmaiņas to nevarētu atspējot.