Strumenti per sviluppatori · SHA calcolatore hash
Integrità delle risorse secondarie: come i browser utilizzano SHA-384 per controllare gli script
· Sfondo
sha-256 base64 API del browser sicurezza
L'attributo di integrità consente a un browser di rifiutare uno script CDN i cui byte sono cambiati. Questo post spiega il formato dell'attributo, perché SHA-384 in base64 è la scelta comune e da cosa SRI non può proteggere.
Il CDN che potrebbe servire a tutto: il rischio della catena di fornitura SRI è stato progettato per
Un tag script su una pagina Web può contenere un attributo di integrità: `<script src="https://cdn.example.com/lib.js" integrity="sha384-..."></script>`. Il valore di integrità è un digest crittografico dei byte dello script. Quando il browser scarica lo script, calcola il digest dei byte ricevuti e lo confronta con l'attributo di integrità. Se corrispondono, lo script viene caricato. Se non corrispondono, il browser si rifiuta di caricarlo e segnala l'errore nella console. Ciò protegge da un CDN compromesso che fornisce codice modificato o da un utente malintenzionato di rete che intercetta e altera la risposta.
L'integrità della risorsa secondaria (SRI) è una specifica W3C che si applica a script e fogli di stile. È l'unica garanzia crittografica che un browser può fornire riguardo al contenuto di una risorsa di origine incrociata: i byte devono corrispondere al digest, altrimenti la risorsa verrà rifiutata. Ciò non prova chi ha creato la risorsa, ma solo che questa non è cambiata da quando è stato calcolato il digest. Per una risorsa fornita su HTTPS da un CDN rispettabile, il digest fornisce una protezione contro la compromissione di CDN o la fornitura specifica di contenuti obsoleti memorizzati nella cache.
L'attributo di integrità: prefisso dell'algoritmo, trattino, digest base64 e supporto per hash multipli
L'attributo di integrità ha un formato specifico: nome algoritmo, trattino, digest in base64. Esempio: `integrity="sha384-JZDdQnrrAMe+sxxpn47in+PwhkxrCrt4SNvt+xWqV3zPJUkeFF0Qq/wNtuvNqPP5"`. Il nome dell'algoritmo può essere SHA-256, SHA-384 o SHA-512. Base64 è la codifica, non esadecimale; questa è una scelta deliberata della specifica SRI. Base64 è più compatto di quello esadecimale (circa il 33% più corto per lo stesso digest), il che è importante quando si incorpora negli attributi HTML. Il trattino separa il nome dell'algoritmo dal digest. È possibile elencare più valori di integrità, separati da spazi: se uno qualsiasi di essi corrisponde, la risorsa viene accettata.
Perché SHA-384? La specifica SRI consente SHA-256, SHA-384 e SHA-512. SHA-384 è diventato l'impostazione predefinita della community perché offre un saldo size/security. SHA-256 è più piccolo (32 bytes, 44 caratteri in base64) ma SHA-384 è più largo (48 bytes, 64 caratteri in base64) e non ha aumentato in modo significativo la dimensione dell'attributo rispetto a SHA-256. SHA-512 è disponibile ma usato raramente perché il suo digest più grande non sembrava necessario per questo caso d'uso. La scelta di SHA-384 è storica e pragmatica, non riflette proprietà di sicurezza superiori (tutti e tre sono crittograficamente forti per questo scopo).
Viene offerto SHA-384 e produce il materiale base64 richiesto; la preferenza della comunità non viene dedotta dallo strumento
La codifica Base64 in SRI è base64 standard, non base64url. Base64 standard utilizza i caratteri + e /, che sono validi negli attributi HTML senza codifica percentuale, sebbene abbiano significati speciali negli URL e nei dati dei moduli. Il formato SRI è progettato per gli attributi HTML, non per gli URL, quindi lo standard base64 è appropriato. Se stai creando un valore di integrità manualmente, calcoli il digest SHA-384 (una sequenza di byte), quindi codifichi tali byte come base64 standard, quindi anteponi `sha384-` e incollali nell'attributo di integrità.
Il browser esegue gli stessi passaggi al contrario: estrae base64 dall'attributo di integrità, decodifica in byte per recuperare il digest, calcola SHA-384 dei byte di script scaricati e confronta i due valori digest. Devono corrispondere esattamente; una differenza di un solo bit nel digest provoca il rifiuto. Non esiste corrispondenza fuzzy o credito parziale: l'integrità è binaria.
Il comportamento SRI multiorigine richiede la documentazione del browser oltre a questo calcolatore di hash
SRI richiede CORS sulle risposte multiorigine. Se carichi uno script da un'origine diversa, il server deve rispondere con `Access-Control-Allow-Origin: *` o un'intestazione di origine specifica che includa la tua. Senza le intestazioni CORS, il browser non può controllare SRI, perché senza CORS non può confermare che il corpo della risposta corrisponda a ciò che il server intendeva inviare. Le intestazioni CORS sono la dichiarazione del server che questa risposta è sicura da controllare; SRI è il tuo controllo che i byte siano corretti. Insieme, formano un impegno nella catena di fornitura: il server ti consente di verificare il contenuto, e tu lo fai.
Se uno script multiorigine è privo di intestazioni CORS e ha un attributo di integrità, il browser lo scaricherà (se gli script da quell'origine sono consentiti dal CSP del sito), ma non ne verificherà l'integrità. Lo script verrà caricato come se l'attributo di integrità fosse assente. Questo non è un errore di SRI; è un limite di sicurezza: non puoi verificare una risposta che non puoi leggere.
Cosa succede in caso di mancata corrispondenza: il browser blocca la risorsa e riporta nella console
Quando il browser rileva una mancata corrispondenza di integrità, rifiuta di eseguire lo script e registra un messaggio nella console del browser. Il messaggio in genere nomina URL, l'hash previsto e l'hash calcolato. Il fallimento è atomico: o la risorsa viene caricata così com'è oppure viene completamente rifiutata. Non è previsto alcun caricamento parziale o fallback. Se un sito web si basava su quello script e veniva rifiutato, il sito potrebbe rompersi. Questo è intenzionale: fornire codice sbagliato è peggio che non fornire codice e gli errori silenziosi consentono agli attacchi di persistere indefinitamente.
Testare una configurazione SRI è semplice: apri la console del browser, carica la pagina e cerca i messaggi relativi alle discrepanze di integrità. Se noti una mancata corrispondenza, confronta l'hash calcolato mostrato nella console con quello nel tuo attributo di integrità. Se non corrispondono, ricalcola: lo script potrebbe essere stato aggiornato e hai bisogno di un nuovo digest.
Esempio realizzato: calcolo di un digest per uno script e formattazione in un valore di integrità, incluso il passaggio base64
Il calcolo manuale di un digest SRI richiede solo i byte di script e uno strumento hash. Scarica lo script, incollalo nel calcolatore hash ToolAcre SHA, seleziona SHA-384, copia l'output base64 (non esadecimale), anteponi `sha384-` e incollalo nell'attributo di integrità. Se lo script è di grandi dimensioni, utilizzare curl o wget per salvarlo in un file e quindi leggere il file è più veloce che incollarlo. Per gli script in linea (in un tag `<script>` in HTML anziché da URL), SRI non è applicabile; gli script inline sono sempre attendibili per definizione. SRI è per risorse esterne.
Un esempio funzionante: supponiamo di voler caricare jQuery da un CDN con SRI. Trova lo script URL, scaricalo (o usa curl per recuperarlo), incolla i byte nella calcolatrice o usa `sha384sum` sulla riga di comando, ottieni il digest SHA-384 come base64 e formattalo come `sha384-[base64-digest]`. Incolla nell'attributo di integrità del tag script. Carica la pagina e verifica che non vengano visualizzati errori della console.
Cosa non copre: script che cambiano intenzionalmente e siti come ToolAcre che non caricano alcun script esterno e quindi non hanno nulla da bloccare
SRI non protegge da tutti gli attacchi alla catena di approvvigionamento. Protegge dalla modifica dei byte dopo il calcolo del digest, ma non dal calcolo del digest a partire da codice compromesso. Se un CDN viene compromesso prima di calcolare il digest, SRI non può essere d'aiuto. Il digest è affidabile tanto quanto la fonte da cui lo hai calcolato. Per la massima sicurezza, calcola i digest dalla fonte originale (ad esempio le versioni GitHub della libreria) e utilizza tali digest durante il caricamento da un CDN. Il digest diventa un impegno da parte del manutentore attraverso il processo di rilascio.
SRI inoltre non protegge da una rete compromessa nel momento in cui si calcola il digest o da una macchina di sviluppo compromessa. Protegge solo dalle modifiche allo script tra il momento in cui viene creato il digest e il momento in cui il browser carica lo script. Per una garanzia continua, alcune distribuzioni utilizzano la firma del rilascio oltre a SRI: il rilascio è firmato dalla chiave di un manutentore, tu verifichi la firma, calcoli il digest dai byte verificati e lo usi in SRI.
Questo articolo non asserisce l'inventario di script esterni a livello di sito di ToolAcre da origini hash
Il calcolatore hash ToolAcre SHA emette direttamente il digest nello standard base64 (come output `base64` dalla funzione `toBase64()`). Per convertire nel formato SRI, anteponi il nome dell'algoritmo e un trattino: `sha256-`, `sha384-` o `sha512-`. La calcolatrice non applica automaticamente quel prefisso perché gli hash compaiono in molti contesti (git, Docker, npm, URL) in cui il nome dell'algoritmo è separato o codificato in modo diverso. Il confine è chiaro: la calcolatrice esegue l'hashing del testo UTF-8 che incolli, non dei file o delle chiavi binarie. Fornisce sia esadecimale che base64. Scegli quale utilizzare in base al contesto. Per SRI, base64 è richiesto dalle specifiche. Per Git e altri strumenti, hex è convenzionale. Per npm e Go viene utilizzato base64. La scelta della codifica è tua; i byte digest sono gli stessi.
SRI rimane uno dei pochi controlli crittografici che un browser può eseguire lato client senza un'autorità centralizzata. L'informatica si digerisce con uno strumento affidabile come il calcolatore SHA di ToolAcre e verificarli rispetto alle risorse caricate è un modo accessibile per rafforzare un sito Web contro determinati attacchi alla catena di approvvigionamento. La protezione è buona quanto il digest; ricalcolare dopo ogni aggiornamento della risorsa esterna e verificare che il browser carichi lo script senza rifiutarlo.