Implementacija sigurnosnih zaglavlja za web: JavaScript Content Security Policy (CSP)

U današnjem digitalnom okruženju, web sigurnost je od presudne važnosti. Zaštita vaše web stranice i njenih korisnika od zlonamjernih napada više nije opcija, već nužnost. Cross-Site Scripting (XSS) i dalje je raširena prijetnja, a jedna od najučinkovitijih obrana je implementacija snažne politike sigurnosti sadržaja (Content Security Policy - CSP). Ovaj vodič fokusira se na korištenje JavaScripta za upravljanje i implementaciju CSP-a, pružajući dinamičan i fleksibilan pristup osiguravanju vaših web aplikacija na globalnoj razini.

Što je Content Security Policy (CSP)?

Content Security Policy (CSP) je zaglavlje HTTP odgovora koje vam omogućuje kontrolu nad resursima koje korisnički agent (preglednik) smije učitati za određenu stranicu. U suštini, djeluje kao bijela lista (whitelist), definirajući izvore s kojih se mogu učitavati skripte, stilovi, slike, fontovi i drugi resursi. Eksplicitnim definiranjem tih izvora možete značajno smanjiti površinu napada vaše web stranice, čineći napadačima puno težim ubacivanje zlonamjernog koda i izvršavanje XSS napada. To je važan sloj dubinske obrane.

Zašto koristiti JavaScript za implementaciju CSP-a?

Iako se CSP može konfigurirati izravno u konfiguraciji vašeg web poslužitelja (npr. Apacheov .htaccess ili Nginxova konfiguracijska datoteka), korištenje JavaScripta nudi nekoliko prednosti, posebno u složenim ili dinamičkim aplikacijama:

• Dinamičko generiranje politike: JavaScript vam omogućuje dinamičko generiranje CSP politika na temelju korisničkih uloga, stanja aplikacije ili drugih uvjeta tijekom izvođenja. To je posebno korisno u jednostraničnim aplikacijama (SPA) ili aplikacijama koje se uvelike oslanjaju na renderiranje na strani klijenta.
• CSP temeljen na "nonce": Korištenje "nonce" vrijednosti (kriptografski nasumičnih, jednokratnih tokena) vrlo je učinkovit način za osiguravanje inline skripti i stilova. JavaScript može generirati te "nonce" vrijednosti i dodati ih i u CSP zaglavlje i u inline oznake skripti/stilova.
• CSP temeljen na "hashu": Za statične inline skripte ili stilove možete koristiti "hasheve" kako biste na bijelu listu stavili određene isječke koda. JavaScript može izračunati te "hasheve" i uključiti ih u CSP zaglavlje.
• Fleksibilnost i kontrola: JavaScript vam daje preciznu kontrolu nad CSP zaglavljem, omogućujući vam da ga mijenjate u hodu na temelju specifičnih potreba aplikacije.
• Otklanjanje pogrešaka i izvještavanje: JavaScript se može koristiti za hvatanje izvještaja o kršenju CSP-a i slanje na središnji poslužitelj za bilježenje radi analize, pomažući vam da identificirate i popravite sigurnosne probleme.

Postavljanje vašeg JavaScript CSP-a

Općeniti pristup uključuje generiranje CSP zaglavlja u obliku stringa u JavaScriptu, a zatim postavljanje odgovarajućeg HTTP zaglavlja odgovora na strani poslužitelja (obično putem vašeg pozadinskog okvira). Pogledat ćemo specifične primjere za različite scenarije.

1. Generiranje "nonce" vrijednosti

"Nonce" (broj korišten jednom) je nasumično generirana, jedinstvena vrijednost koja se koristi za stavljanje na bijelu listu određenih inline skripti ili stilova. Evo kako možete generirati "nonce" u JavaScriptu:

            function generateNonce() {
  const crypto = window.crypto || window.msCrypto; // For IE support
  if (!crypto || !crypto.getRandomValues) {
    // Fallback for older browsers without crypto API
    return Math.random().toString(36).substring(2, 15) + Math.random().toString(36).substring(2, 15);
  }
  const arr = new Uint32Array(1);
  crypto.getRandomValues(arr);
  return btoa(String.fromCharCode.apply(null, new Uint8Array(arr.buffer)));
}

const nonce = generateNonce();
console.log("Generated Nonce:", nonce);

            

              
                Copy
              
            
          

Ovaj isječak koda generira kriptografski siguran "nonce" koristeći ugrađeni crypto API preglednika (ako je dostupan) i vraća se na manje sigurnu metodu ako API nije podržan. Generirani "nonce" se zatim kodira u base64 format za upotrebu u CSP zaglavlju.

2. Ubacivanje "nonce" vrijednosti u inline skripte

Nakon što imate "nonce", trebate ga ubaciti i u CSP zaglavlje i u <script> oznaku:

HTML:

            <script nonce="YOUR_NONCE_HERE">
  // Your inline script code here
  console.log("Hello from inline script!");
</script>
            

              
                Copy
              
            
          

JavaScript (pozadinski):

            const nonce = generateNonce();
const cspHeader = `default-src 'self'; script-src 'self' 'nonce-${nonce}' 'strict-dynamic' 'unsafe-inline'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests;`;

// Example using Node.js with Express:
app.use((req, res, next) => {
  res.setHeader('Content-Security-Policy', cspHeader);
  // Pass the nonce to the view or template engine
  res.locals.nonce = nonce;
  next();
});

            

              
                Copy
              
            
          

Važne napomene:

• Zamijenite YOUR_NONCE_HERE u HTML-u sa stvarno generiranim "nonceom". To se često radi na strani poslužitelja pomoću sustava za predloške. Gornji primjer ilustrira prosljeđivanje "noncea" sustavu za predloške.
• Direktiva script-src u CSP zaglavlju sada uključuje 'nonce-${nonce}', dopuštajući izvršavanje skripti s odgovarajućim "nonceom".
• 'strict-dynamic' se dodaje direktivi `script-src`. Ova direktiva govori pregledniku da vjeruje skriptama koje učitavaju pouzdane skripte. Ako oznaka skripte ima valjan "nonce", tada će i svaka skripta koju ona dinamički učita (npr. pomoću `document.createElement('script')`) također biti pouzdana. To smanjuje potrebu za dodavanjem brojnih pojedinačnih domena i CDN URL-ova na bijelu listu i znatno pojednostavljuje održavanje CSP-a.
• 'unsafe-inline' se općenito ne preporučuje pri korištenju "noncea" jer slabi CSP. Međutim, ovdje je uključen u demonstracijske svrhe i treba ga ukloniti u produkciji. Uklonite ga čim budete mogli.

3. Generiranje "hasheva" za inline skripte

Za statične inline skripte koje se rijetko mijenjaju, možete koristiti "hasheve" umjesto "noncea". "Hash" je kriptografski sažetak sadržaja skripte. Ako se sadržaj skripte promijeni, promijenit će se i "hash", a preglednik će blokirati skriptu.

Izračunavanje "hasha":

Možete koristiti online alate ili uslužne programe naredbenog retka poput OpenSSL-a za generiranje SHA256 "hasha" vaše inline skripte. Na primjer:

            openssl dgst -sha256 -binary your_script.js | openssl base64
            

              
                Copy
              
            
          

Primjer:

Recimo da je vaša inline skripta:

            <script>
  console.log("Hello from inline script!");
</script>
            

              
                Copy
              
            
          

SHA256 "hash" ove skripte (bez <script> oznaka) mogao bi biti:

            sha256-YOUR_HASH_HERE
            

              
                Copy
              
            
          

CSP zaglavlje:

            const cspHeader = `default-src 'self'; script-src 'self' 'sha256-YOUR_HASH_HERE'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests;`;
            

              
                Copy
              
            
          

Zamijenite YOUR_HASH_HERE sa stvarnim SHA256 "hashem" sadržaja vaše skripte.

Važna razmatranja za "hasheve":

• "Hash" se mora izračunati na točnom sadržaju skripte, uključujući praznine. Bilo kakve promjene u skripti, čak i jedan znak, poništit će "hash".
• "Hashevi" su najprikladniji za statične skripte koje se rijetko mijenjaju. Za dinamičke skripte, "nonce" vrijednosti su bolja opcija.

4. Postavljanje CSP zaglavlja na poslužitelju

Posljednji korak je postavljanje Content-Security-Policy HTTP zaglavlja odgovora na vašem poslužitelju. Točna metoda ovisi o vašoj tehnologiji na strani poslužitelja.

Node.js s Expressom:

            app.use((req, res, next) => {
  const nonce = generateNonce();
  const cspHeader = `default-src 'self'; script-src 'self' 'nonce-${nonce}' 'strict-dynamic' 'unsafe-inline'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests;`;
  res.setHeader('Content-Security-Policy', cspHeader);
  res.locals.nonce = nonce; // Make nonce available to templates
  next();
});
            

              
                Copy
              
            
          

Python s Flaskom:

            from flask import Flask, make_response, render_template, g
import os
import base64

app = Flask(__name__)

def generate_nonce():
    return base64.b64encode(os.urandom(16)).decode('utf-8')

@app.before_request
def before_request():
    g.nonce = generate_nonce()

@app.after_request
def after_request(response):
    csp = "default-src 'self'; script-src 'self' 'nonce-{nonce}' 'strict-dynamic' 'unsafe-inline'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests".format(nonce=g.nonce)
    response.headers['Content-Security-Policy'] = csp
    return response

@app.route('/')
def index():
    return render_template('index.html', nonce=g.nonce)

            

              
                Copy
              
            
          

PHP:

            <?php
function generateNonce() {
  return base64_encode(random_bytes(16));
}

$nonce = generateNonce();
header("Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-" . $nonce . "' 'strict-dynamic' 'unsafe-inline'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests");
?>
<!DOCTYPE html>
<html>
<head>
  <title>CSP Example</title>
</head>
<body>
  <script nonce="<?php echo htmlspecialchars($nonce, ENT_QUOTES, 'UTF-8'); ?>">
    console.log("Hello from inline script!");
  </script>
</body>
</html>
            

              
                Copy
              
            
          

Apache (.htaccess):

Iako se ne preporučuje za dinamički CSP, *možete* postaviti statički CSP pomoću .htaccess datoteke:

            <IfModule mod_headers.c>
  Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests;"
</IfModule>
            

              
                Copy
              
            
          

Nginx:

            add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests;";
            

              
                Copy
              
            
          

Važne napomene:

• Zamijenite 'self' sa stvarnom domenom(ama) s kojih želite dopustiti učitavanje resursa.
• Budite izuzetno oprezni pri korištenju 'unsafe-inline' i 'unsafe-eval'. Ove direktive značajno slabe CSP i treba ih izbjegavati kad god je to moguće.
• Koristite upgrade-insecure-requests za automatsku nadogradnju svih HTTP zahtjeva na HTTPS.
• Razmislite o korištenju report-uri ili report-to za specificiranje krajnje točke za primanje izvještaja o kršenju CSP-a.

Objašnjenje CSP direktiva

CSP koristi direktive za specificiranje dopuštenih izvora za različite vrste resursa. Evo kratkog pregleda nekih od najčešćih direktiva:

• default-src: Specificira zadani izvor za sve resurse koji nisu eksplicitno pokriveni drugim direktivama.
• script-src: Specificira dopuštene izvore za JavaScript.
• style-src: Specificira dopuštene izvore za stilove.
• img-src: Specificira dopuštene izvore za slike.
• font-src: Specificira dopuštene izvore za fontove.
• media-src: Specificira dopuštene izvore za audio i video.
• object-src: Specificira dopuštene izvore za dodatke (npr. Flash). Općenito, trebali biste ovo postaviti na 'none' kako biste onemogućili dodatke.
• frame-src: Specificira dopuštene izvore za okvire i iframeove.
• connect-src: Specificira dopuštene izvore za XMLHttpRequest, WebSocket i EventSource veze.
• base-uri: Specificira dopuštene osnovne URI-je za dokument.
• form-action: Specificira dopuštene krajnje točke za slanje obrazaca.
• upgrade-insecure-requests: Uputa korisničkom agentu da sve nesigurne URL-ove stranice (one poslužene preko HTTP-a) tretira kao da su zamijenjeni sigurnim URL-ovima (onima posluženim preko HTTPS-a). Ova direktiva je namijenjena web stranicama koje su u potpunosti prešle na HTTPS.
• report-uri: Specificira URI na koji preglednik treba slati izvještaje o kršenjima CSP-a. Ova direktiva je zastarjela u korist `report-to`.
• report-to: Specificira imenovanu krajnju točku na koju preglednik treba slati izvještaje o kršenjima CSP-a.

Ključne riječi za popis izvora u CSP-u

Svaka direktiva koristi popis izvora za specificiranje dopuštenih izvora. Popis izvora može sadržavati sljedeće ključne riječi:

• 'self': Dopušta resurse s istog izvora (shema, host i port).
• 'none': Ne dopušta resurse s bilo kojeg izvora.
• 'unsafe-inline': Dopušta inline skripte i stilove. Izbjegavajte ovo kad god je moguće.
• 'unsafe-eval': Dopušta korištenje eval() i srodnih funkcija. Izbjegavajte ovo kad god je moguće.
• 'strict-dynamic': Specificira da se povjerenje koje preglednik daje skripti na stranici zbog pratećeg "noncea" ili "hasha" prenosi na skripte koje ta skripta učitava.
• 'data:': Dopušta resurse učitane putem data: sheme (npr. inline slike). Koristite s oprezom.
• 'mediastream:': Dopušta resurse učitane putem mediastream: sheme.
• https:: Dopušta resurse učitane preko HTTPS-a.
• http:: Dopušta resurse učitane preko HTTP-a. Općenito se ne preporučuje.
• *: Dopušta resurse s bilo kojeg izvora. Izbjegavajte ovo; to poništava svrhu CSP-a.

Izvještavanje o kršenju CSP-a

Izvještavanje o kršenju CSP-a ključno je za praćenje i otklanjanje pogrešaka u vašem CSP-u. Kada resurs prekrši CSP, preglednik može poslati izvještaj na specificirani URI.

Postavljanje krajnje točke za izvještaje:

Trebat će vam krajnja točka na strani poslužitelja za primanje i obradu izvještaja o kršenju CSP-a. Izvještaj se šalje kao JSON payload.

Primjer (Node.js s Expressom):

            app.post('/csp-report', (req, res) => {
  console.log('CSP Violation Report:', req.body);
  // Process the report (e.g., log to a file or database)
  res.status(204).end(); // Respond with a 204 No Content status
});
            

              
                Copy
              
            
          

Konfiguriranje direktive report-uri ili report-to:

Dodajte direktivu report-uri ili `report-to` u svoje CSP zaglavlje. `report-uri` je zastario, stoga je poželjno koristiti `report-to`.

            const cspHeader = `default-src 'self'; script-src 'self' 'nonce-${nonce}' 'strict-dynamic'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests; report-to csp-endpoint;`;
            

              
                Copy
              
            
          

Također trebate konfigurirati krajnju točku Reporting API-ja koristeći zaglavlje `Report-To`.

            Report-To: { "group": "csp-endpoint", "max_age": 10886400, "endpoints": [{"url": "/csp-report"}], "include_subdomains": true }
            

              
                Copy
              
            
          

Napomena:

• Zaglavlje `Report-To` mora biti postavljeno na svakom zahtjevu prema vašem poslužitelju, inače bi preglednik mogao odbaciti konfiguraciju.
• `report-uri` je manje siguran od `report-to` jer ne dopušta TLS enkripciju izvještaja, a i zastario je, stoga je poželjno koristiti `report-to`.

Primjer izvještaja o kršenju CSP-a (JSON):

            {
  "csp-report": {
    "document-uri": "https://example.com/page.html",
    "referrer": "",
    "violated-directive": "script-src 'self' 'nonce-YOUR_NONCE_HERE'",
    "effective-directive": "script-src",
    "original-policy": "default-src 'self'; script-src 'self' 'nonce-YOUR_NONCE_HERE'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests; report-uri /csp-report;",
    "blocked-uri": "https://evil.com/malicious.js",
    "status-code": 200,
    "script-sample": ""
  }
}
            

              
                Copy
              
            
          

Analizom ovih izvještaja možete identificirati i popraviti kršenja CSP-a, osiguravajući da vaša web stranica ostane sigurna.

Najbolje prakse za implementaciju CSP-a

• Počnite s restriktivnom politikom: Počnite s politikom koja dopušta samo resurse s vašeg vlastitog izvora i postupno je ublažavajte prema potrebi.
• Koristite "nonce" vrijednosti ili "hasheve" za inline skripte i stilove: Izbjegavajte korištenje 'unsafe-inline' kad god je to moguće.
• Koristite 'strict-dynamic' kako biste pojednostavili održavanje CSP-a.
• Izbjegavajte korištenje 'unsafe-eval': Ako trebate koristiti eval(), razmotrite alternativne pristupe.
• Koristite upgrade-insecure-requests: Automatski nadogradite sve HTTP zahtjeve na HTTPS.
• Implementirajte izvještavanje o kršenju CSP-a: Pratite svoj CSP na kršenja i brzo ih ispravljajte.
• Temeljito testirajte svoj CSP: Koristite alate za razvojne programere u pregledniku kako biste identificirali i riješili sve probleme s CSP-om.
• Koristite validator za CSP: Online alati mogu vam pomoći da provjerite sintaksu vašeg CSP zaglavlja i identificirate potencijalne probleme.
• Razmislite o korištenju okvira ili biblioteke za CSP: Nekoliko okvira i biblioteka može vam pomoći pojednostaviti implementaciju i upravljanje CSP-om.
• Redovito pregledavajte svoj CSP: Kako se vaša aplikacija razvija, vaš CSP će možda trebati ažuriranje.
• Educirajte svoj tim: Pobrinite se da vaši programeri razumiju CSP i njegovu važnost.
• Implementirajte CSP u fazama: Počnite s implementacijom CSP-a u načinu rada "samo izvještavanje" (report-only) kako biste pratili kršenja bez blokiranja resursa. Kada ste sigurni da je vaša politika ispravna, možete je omogućiti u načinu provedbe.
• Dokumentirajte svoj CSP: Vodite evidenciju o svojoj CSP politici i razlozima iza svake direktive.
• Budite svjesni kompatibilnosti preglednika: Podrška za CSP varira među različitim preglednicima. Testirajte svoj CSP na različitim preglednicima kako biste osigurali da radi kako se očekuje.
• Dajte prednost sigurnosti: CSP je moćan alat za poboljšanje web sigurnosti, ali nije čarobno rješenje. Koristite ga u kombinaciji s drugim najboljim sigurnosnim praksama kako biste zaštitili svoju web stranicu od napada.
• Razmislite o korištenju vatrozida za web aplikacije (WAF): WAF vam može pomoći u provođenju CSP politika i zaštiti vaše web stranice od drugih vrsta napada.

Uobičajeni izazovi pri implementaciji CSP-a

• Skripte trećih strana: Identificiranje i stavljanje na bijelu listu svih domena potrebnih za skripte trećih strana može biti izazovno. Koristite `strict-dynamic` gdje je to moguće.
• Inline stilovi i rukovatelji događajima: Pretvaranje inline stilova i rukovatelja događajima u vanjske datoteke sa stilovima i JavaScript datoteke može biti dugotrajno.
• Problemi s kompatibilnošću preglednika: Podrška za CSP varira među različitim preglednicima. Testirajte svoj CSP na različitim preglednicima kako biste osigurali da radi kako se očekuje.
• Troškovi održavanja: Održavanje vašeg CSP-a ažurnim kako se vaša aplikacija razvija može biti izazov.
• Utjecaj na performanse: CSP može unijeti blagi pad performansi zbog potrebe za provjerom resursa u odnosu na politiku.

Globalna razmatranja za CSP

Prilikom implementacije CSP-a za globalnu publiku, uzmite u obzir sljedeće:

• CDN pružatelji usluga: Ako koristite CDN-ove, osigurajte da ste na bijelu listu stavili odgovarajuće CDN domene. Mnogi CDN-ovi nude regionalne krajnje točke; njihovo korištenje može poboljšati performanse za korisnike na različitim geografskim lokacijama.
• Resursi specifični za jezik: Ako vaša web stranica podržava više jezika, osigurajte da ste na bijelu listu stavili potrebne resurse za svaki jezik.
• Regionalni propisi: Budite svjesni bilo kakvih regionalnih propisa koji bi mogli utjecati na vaše zahtjeve za CSP.
• Pristupačnost: Osigurajte da vaš CSP nehotice ne blokira resurse potrebne za značajke pristupačnosti.
• Testiranje u različitim regijama: Testirajte svoj CSP u različitim geografskim regijama kako biste osigurali da radi kako se očekuje za sve korisnike.

Zaključak

Implementacija robusne politike sigurnosti sadržaja (CSP) ključan je korak u osiguravanju vaših web aplikacija od XSS napada i drugih prijetnji. Korištenjem JavaScripta za dinamičko generiranje i upravljanje vašim CSP-om, možete postići višu razinu fleksibilnosti i kontrole, osiguravajući da vaša web stranica ostane sigurna i zaštićena u današnjem stalno promjenjivom krajoliku prijetnji. Ne zaboravite slijediti najbolje prakse, temeljito testirati svoj CSP i kontinuirano ga pratiti zbog kršenja. Sigurno kodiranje, dubinska obrana i dobro implementiran CSP ključni su za pružanje sigurnog pregledavanja globalnoj publici.