Politica de securitate a conținutului este antetul prin care site-ul spune browserului din ce surse are voie să încarce scripturi și stiluri. Pentru codul scris direct în pagină, ai două variante: o amprentă calculată din conținutul scriptului sau un nonce, adică un cod unic generat la fiecare cerere. Amprenta se strică la fiecare caracter modificat; nonce-ul nu.
Pe scurt
- Ce face
- Oprește execuția codului străin chiar dacă acesta ajunge în pagină.
- Amprentă
- Se recalculează la orice modificare a scriptului. Uitată, blochează totul, fără mesaj vizibil.
- Nonce
- Cod unic generat pe cerere, pus în antet și pe elementele permise. Nu se strică la editare.
- Cea mai sigură variantă
- Fișier extern, de pe același domeniu: intră sub
script-src 'self', fără nimic de recalculat. - Capcana obișnuită
- Panourile de administrare au nevoie de reguli mai permisive, altfel rămân ecran alb.
De ce amprentele par o idee bună și de ce nu sunt
O amprentă este suma de control a scriptului din pagină. Browserul o compară cu ce primește și, dacă diferă, refuză execuția. Protecția este reală, dar întreținerea e capcana: orice modificare, până și un spațiu, schimbă amprenta. Dacă antetul nu este actualizat în același moment, scriptul e blocat, iar în consola browserului apare o eroare pe care nimeni nu o vede până nu se plânge un vizitator.
Am pățit exact asta pe un site unde textul dintr-un script se genera din conținutul paginii: la fiecare modificare de text se schimba amprenta, iar funcția respectivă rămânea blocată pe tot site-ul, tăcut.
Cum funcționează varianta cu nonce
Serverul generează un cod aleatoriu la fiecare cerere, îl trimite în antetul politicii și îl pune ca atribut pe elementele care au voie să ruleze. Browserul compară cele două valori. Fiindcă se generează la fiecare afișare, conținutul scriptului poate fi modificat oricând, fără să atingi antetul.
Condiția este ca valoarea să fie chiar aleatoare și să nu se repete între cereri. Un nonce fix, pus într-o pagină servită din cache, nu mai protejează nimic.
Varianta și mai simplă: fișierul extern
Un script servit ca fișier de pe același domeniu intră sub regula script-src 'self' și nu are nevoie nici de amprentă, nici de nonce. Dacă puteți scoate codul din pagină, faceți-o: e cea mai puțin fragilă soluție dintre toate.
De ce îmi rămâne panoul de administrare alb după ce activez politica?
Fiindcă multe panouri au nevoie de evaluarea dinamică a codului și de stiluri scrise direct în elemente, iar o politică strictă le interzice pe amândouă. Pagina se încarcă, dar nu se randează nimic, și nu apare niciun mesaj de eroare vizibil. Soluția este să nu aplicați politica strictă pe rutele panoului, sau să îi dați acolo regulile de care are nevoie.
Atenție și la felul în care se aplică regulile: în unele configurații, filtrele adăugate grupului obișnuit de rute nu ajung deloc pe rutele panoului, ceea ce, în cazul de față, este chiar comportamentul dorit.
Cum verific dacă politica mea chiar funcționează?
Deschideți site-ul cu consola browserului activă și căutați mesajele care încep cu „Refused to". Fiecare înseamnă o resursă blocată. Verificați apoi cu o unealtă publică ce reguli conține antetul: prezența lui nu spune nimic despre cât de strict este. O politică ce permite unsafe-inline pentru scripturi oprește puțin din ce ar trebui să oprească.
Politica de conținut este una dintre măsurile pe care le punem la securitate web, alături de înregistrările care împiedică falsificarea adresei de email. Dacă site-ul a fost deja compromis, procedura de curățare este descrisă în articolul despre cum ajung site-urile infectate.
