Il criterio di sicurezza dei contenuti (CSP) è una funzione di sicurezza implementata nei browser Web per proteggere i siti e le applicazioni Web da vari tipi di attacchi, come gli attacchi di tipo cross-site scripting (XSS) e data injection. Il CSP controlla e limita le fonti di diversi tipi di contenuti che possono essere caricati o eseguiti su una pagina Web. Questi tipi di contenuti includono:
- Script
- Fogli di stile
- Images
In questo post, daremo innanzitutto un'occhiata a come funziona CSP. Vedremo che un uso più efficace e dinamico di CSP include alcuni calcoli che devono essere eseguiti sul server. Tuttavia, è possibile spostare tale calcolo sull'edge, riducendo la latenza e garantendo un'esperienza ottimale all'utente finale. Esploreremo anche come potrebbe funzionare questa soluzione di edge computing.
Siete pronti a tuffarvi? Cominciamo col capire come funziona il CSP.
Come funziona il CSP
Un CSP è tipicamente definito dal lato server aggiungendo un'opzione Content-Security-Policy alla risposta HTTP. Viene inviata dal server Web all'utente che richiede una pagina Web. Questa intestazione specifica le regole che il browser deve seguire per il caricamento e l'esecuzione dei contenuti della pagina.
Esempi di impostazione del parametro Content-Security-Policy intestazione
Supponiamo di lavorare con Express in Node.js. Si imposterebbe l'intestazione del CSP in questo modo:
const express = require('express'); |
Se si utilizzasse Python con Flask, il codice sarebbe simile a questo:
app = Flask(__name__) |
Lavorare con le direttive
Ogni intestazione CSP può avere più direttive e ogni direttiva può avere valori appropriati per il tipo di impostazione fornita. Queste direttive definiscono le regole di sicurezza per vari tipi di risorse. Ad esempio, la direttiva script-src specifica le fonti consentite per i fogli di stile.
Si consideri la seguente intestazione CSP:
Content-Security-Policy: default-src 'self'; script-src 'self' https://static.example.com; style-src 'self' 'unsafe-inline'; |
Nell'intestazione di cui sopra, vediamo tre direttive, ciascuna con i relativi valori.
- Il
default-srcimpostata su'self'specifica che, per impostazione predefinita, tutti i contenuti devono essere caricati dalla stessa origine della pagina stessa. - Il
script-srcpermette agli script di essere caricati dalla stessa origine ('self') e la sorgente esterna specificata (https://static.example.com). - Il
style-srcpermette ai fogli di stile di essere caricati dalla stessa origine e consente anche gli stili in linea.
L'elenco delle direttive disponibili è in realtà abbastanza esaustivo. Lo si può trovare qui. Le direttive includono:
font-src: Sorgenti per i font caricati con@font-faceframe-src: Fonti per contesti di navigazione nidificati caricati in elementi come<frame>e<iframe>img-src: Fonti di immagini e favicon
Legare il CSP all'HTML
Una volta impostata l'intestazione CSP sul server, il browser applica queste regole quando carica le risorse sulla pagina web.
Nel sorgente HTML, gli sviluppatori possono aggiungere elementi (come script o fogli di stile) in linea o facendo riferimento a risorse (della stessa origine o di altre). Il browser controllerà quindi l'intestazione CSP per verificare che queste risorse siano conformi alle regole definite. Se una risorsa non è consentita dal CSP, il browser ne blocca l'inclusione e l'esecuzione.
Unico per ogni richiesta
Per il modo in cui sono definite le intestazioni CSP, esse sono in genere coerenti tra tutte le richieste di una particolare pagina Web. I dettagli e le direttive per ogni richiesta di una singola pagina saranno gli stessi per ogni richiesta successiva di quella pagina.
Ciò solleva una questione interessante: Come gestire gli script e gli stili dinamici in linea? Potremmo voler consentire l'esecuzione di script e stili in linea specifici, senza aprire la porta all'inclusione di tutti gli script e gli stili in linea.
In questo scenario, è possibile introdurre valori nonce o hash per garantire che, anche se l'origine di uno script o di uno stile non è esplicitamente elencata nel CSP, possa essere eseguita, purché corrisponda al valore nonce o hash specificato dall'intestazione del CSP.
Questi valori nonce o hash possono cambiare a ogni richiesta, rendendoli così unici. Pertanto, devono essere generati e gestiti su un server. Tuttavia, solo perché questi nonce o hash devono essere eseguiti su un server, non è detto che debbano essere eseguiti sul server principale del sito. È qui che entra in gioco l'edge computing.
Che cos'è l'edge computing?
L'edge computing è essenzialmente il concetto che alcuni calcoli possono essere impostati per essere eseguiti al margine esterno della rete, geograficamente vicino agli utenti finali. In sostanza, si tratta di un tipo di calcolo distribuito che consente di avvicinarsi alla velocità di calcolo in tempo reale, anche su Internet, riducendo al contempo la latenza della rete.
Con l'edge computing, potreste spostare le preoccupazioni, generando nonces e hash per le intestazioni del CSP più vicino ai vostri utenti finali, riducendo il tempo che devono aspettare per proteggere il vostro sito.
Come l'edge computing può aiutare il CSP
Uno dei motivi principali per cui il CSP può rallentare il vostro sito è che i nonce nelle intestazioni possono causare cache miss, richiedendo al browser del cliente di andare fino al server per ottenere le intestazioni più fresche generate correttamente. Per risolvere questo problema, è possibile implementare un generatore dinamico di nonce CSP in un'istanza edge. In questo modo si potrà garantire che la cache sia ancora utile, mantenendo al contempo la sicurezza.
I vantaggi di questo approccio includono:
- Latenza ridotta: L'istanza di edge compute genera e inserisce il nonce nella richiesta. Le richieste, ora con il nonce inserito, continuano ad attraversare la cache, evitando così la necessità di rivolgersi al server di origine per ottenere nuove risposte ogni volta che viene effettuata una richiesta.
- Sicurezza distribuita: L'uso dell'edge computation significa avere un ulteriore livello di sicurezza prima che i clienti debbano interagire con i server primari e il codice applicativo del sistema. Anche in caso di vulnerabilità dell'applicazione, l'edge computation che calcola il CSP nonce fornisce un ulteriore livello di sicurezza, aiutandovi a mitigare i potenziali problemi.
- Facilità di manutenzione: Se si gestisce il nonce dinamico per l'header CSP nell'edge con un approccio serverless, si semplificano le attività di manutenzione. In particolare, è possibile gestire i criteri CSP senza modificare il codice dell'applicazione. Inoltre, è possibile gestire questo tipo di modifiche da un sistema di controllo centrale, senza bisogno di effettuare distribuzioni di codice speciali. Queste funzioni di calcolo edge possono anche essere utilizzate da più applicazioni indipendenti, separando così le preoccupazioni dai team specifici che lavorano su ciascuna applicazione e consentendo ai professionisti della sicurezza di assicurarsi che la generazione di nonce sia corretta.
Conclusione
Siete interessati a saperne di più sull'utilizzo dell'edge computing? Se sì, date un'occhiata ad alcuni dei prodotti di Akamai. In particolare, gli EdgeWorker creano un'esperienza serverless in grado di fare esattamente ciò di cui abbiamo parlato in questo articolo, senza la complessità di capire come distribuire da soli i server ai margini delle reti.
Se siete pronti a provarlo di persona, iscrivetevi oggi stesso per una prova gratuita! È ora di lavorare per proteggere il vostro sito con intestazioni CSP migliori che non mandino in tilt il vostro sistema di caching!
Commenti