Strumenti per sviluppatori · SHA calcolatore hash
Incollare segreti negli strumenti hash online: perché il digest dovrebbe essere locale
· Perché è importante
sha-256 sicurezza privacy API del browser
Se uno strumento di hash invia il tuo input al suo server, il segreto che stavi sottoponendo ad hashing ha già lasciato il tuo computer. Questo post spiega il rischio, come Web Crypto rende superfluo un server e come verificare che uno strumento sia locale.
La chiave API che hai sottoposto ad hashing per confrontarla con un file di configurazione e dove è andata
Uno sviluppatore deve eseguire l'hashing di una chiave API per confrontarla con un valore archiviato nella configurazione, in modo da raggiungere lo strumento di hash online più vicino. Incollano la chiave, fanno clic sul pulsante e ottengono il digest. L'hash corrisponde, quindi il test viene superato. Ciò che probabilmente non si rendono conto è che la chiave API ha già lasciato il loro computer. Qualsiasi strumento di hash eseguito su un server riceve l'input in testo normale prima di calcolare qualsiasi digest. Il server può registrarlo, archiviarlo, venderlo o inoltrarlo ai concorrenti.
L'inganno è sottile perché uno strumento di hash può davvero produrre un output corretto e comunque inviare l'input a un server. L'operazione matematica dell'hashing è indipendente dalla posizione, quindi un hash lato server è crittograficamente corretto anche se l'architettura non è sicura. Un utente malintenzionato non ha bisogno di corrompere il calcolo dell'hash per vincere; hanno solo bisogno dell'input in chiaro. Uno sviluppatore che presuppone che uno strumento hash sia locale perché l'output è corretto si fida della proprietà sbagliata.
Ciò che riceve uno strumento di hash lato server: l'intero input di testo in chiaro, per definizione, prima che venga calcolato qualsiasi digest
Uno strumento di hash lato server richiede l'input di testo in chiaro come input, per definizione. Il server lo riceve tramite HTTPS, che lo protegge durante il transito, ma solo fino al raggiungimento del server. Il testo in chiaro viene quindi registrato dal server, archiviato in memoria durante l'hashing, potenzialmente scritto su disco e incluso in eventuali backup o tracce di monitoraggio conservate dal server. L'azienda che gestisce il server può leggere i registri e vedere ogni segreto che sia mai stato sottoposto ad hashing lì.
L'alternativa è utilizzare Web Crypto, che è l'implementazione crittografica del browser. Su un'origine sicura, che significa HTTPS o localhost, il browser espone crypto.subtle.digest, una funzione che calcola SHA-1, SHA-256, SHA-384 e SHA-512 digest interamente all'interno del processo del browser. L'input non lascia mai il dispositivo e non è coinvolto alcun server. L'implementazione del browser viene controllata dai fornitori di browser, patchata dai fornitori di browser e viene eseguita come codice nativo ottimizzato anziché come JavaScript spedito.
Perché il server non è necessario: il Web Crypto del browser calcola ogni digest SHA-2 localmente
Per verificare che uno strumento di hash sia locale è sufficiente aprire il pannello di rete DevTools e osservare cosa invia lo strumento sulla rete. Nella maggior parte dei browser, DevTools si apre con F12 o Cmd+Opzione+I e la scheda Rete è il posto in cui monitorare il traffico di rete. Con la scheda di rete aperta e lo strumento hash visibile, incolla il testo in chiaro, fai clic sul pulsante hash e osserva cosa succede. Se viene utilizzato uno strumento locale, il pannello di rete non mostra nuove richieste.
Questo metodo di verifica funziona perché i browser implementano una restrizione della stessa origine. La pagina può effettuare richieste alla propria origine senza attivare problemi CORS, quindi uno strumento locale potrebbe effettuare richieste a un server sullo stesso dominio, se lo desidera. Quando viene visualizzata una richiesta di rete nel pannello DevTools, dimostra che lo strumento sta inviando dati da qualche parte. Uno sviluppatore che controlla questo e non vede traffico di rete ha la certezza assoluta che l'input non esce dal browser. Il calcolatore di hash ToolAcre SHA produce un pannello di rete che rimane vuoto durante l'hashing.
Verifica con il pannello di rete: incolla, hashing e controlla zero richieste
Una rigorosa politica di sicurezza dei contenuti può fornire ulteriore garanzia oltre il controllo del pannello di rete. La Content Security Policy è un'intestazione HTTP che il server invia, dichiarando quali domini il browser dovrebbe consentire di caricare script ed effettuare richieste. Una politica che non consente tutti gli script esterni, tutti i fogli di stile esterni e tutti gli invii di moduli a origini esterne limita ciò che una pagina compromessa può fare. Un utente malintenzionato non può inviare codice dannoso che invia l'input a un server esterno se la policy vieta richieste esterne.
Le intestazioni della policy di sicurezza dei contenuti vengono inviate con la risposta HTTP e possono essere controllate nella sezione Intestazioni di risposta della scheda Rete DevTools. Una riga come Content-Security-Policy: default-src 'self'; script-src 'self' dichiara che gli script possono provenire solo dalla stessa origine. Una policy più rigorosa che include i frame antenati "nessuno" impedisce alla pagina di essere incorporata in un iframe, bloccando così un vettore di attacco se un iframe dannoso tenta di rubare il focus. Questi dettagli sono utili per comprendere le difese, ma il controllo del pannello di rete resta la verifica primaria.
CSP è la difesa in profondità; le fonti del repository lette qui non stabiliscono l'intestazione distribuita
Un esempio funzionante: incollare una chiave API da AWS o Azure nel calcolatore hash ToolAcre SHA per verificarla rispetto a un'impronta digitale archiviata. Apri DevTools, seleziona la scheda Rete e assicurati che stia registrando. Incolla la chiave API nello strumento hash, seleziona SHA-256 e fai clic su hash. Il digest viene visualizzato nello strumento e il pannello di rete non mostra nuove richieste. Il vettore di test è disponibile nella documentazione dello strumento per effettuare un controllo incrociato della correttezza dell'hash, se necessario. Il punto chiave è che la chiave API non ha mai lasciato il browser e ora il digest può essere confrontato con un valore memorizzato senza mai esporre il segreto.
Ciò che questo flusso di lavoro non copre è se un'estensione del browser è stata compromessa o se il browser stesso è stato compromesso. Un'estensione dannosa con ampi permessi può vedere tutto il traffico, intercettare il contenuto degli appunti e osservare ciò che l'utente digita. Un browser compromesso, a causa di una vulnerabilità zero-day o di un'installazione dannosa, può essere costretto a inviare l'input ovunque. Per queste minacce, nessuno strumento web può fornire protezione. La difesa adeguata è fidarsi dell'installazione del browser, mantenerlo aggiornato ed esaminare le estensioni installate.
Esempio funzionante: utilizza un indicatore innocuo e ispeziona le richieste anziché incollare una chiave API attiva
Il consiglio per chiunque incolli segreti negli strumenti è di verificare che lo strumento sia locale prima di incollare. Questo è un passaggio semplice che elimina il rischio più grande: l'operatore del server, i suoi dipendenti, i suoi backup e i suoi registri vedono tutti il testo in chiaro. Utilizza il pannello di rete DevTools, controlla se non ci sono richieste, quindi affida allo strumento il segreto. Il calcolatore hash ToolAcre SHA è progettato per essere utilizzato in questo modo. Non memorizza nulla, non carica nulla e il pannello Rete rimane vuoto.
Per gli sviluppatori che hanno già incollato i segreti negli strumenti lato server, il passaggio successivo consiste nel ruotarli. Una chiave API inviata a un server sconosciuto dovrebbe essere considerata compromessa. Dovrebbe essere revocato e dovrebbe essere emesso uno nuovo. Le password dovrebbero essere cambiate. Le chiavi SSH dovrebbero essere sostituite. Per i segreti statici come le chiavi API dell'infrastruttura, si tratta di un'operazione una tantum. Per i token di sessione o le credenziali temporanee, la rotazione avviene automaticamente alla scadenza dei token.
Ciò che questo non copre: estensioni del browser e macchine compromesse, da cui nessuno strumento web può difendersi
Costruire la fiducia negli strumenti online inizia con la comprensione di dove avviene il calcolo e la verifica di tale comprensione con gli strumenti di sviluppo del browser. Il pannello di rete è un segnale chiaro: se i dati lasciano il browser, appariranno lì. Se nessuna richiesta contiene l'input di test distintivo, quella sessione fornisce la prova di un percorso di conversione locale. Non costituisce una garanzia su estensioni, codice del browser compromesso o implementazioni future. Combinare questo controllo con la revisione del codice sorgente, se disponibile, fornisce sicurezza.
Per le organizzazioni che valutano strumenti crittografici da utilizzare con dati sensibili, il principio rimane lo stesso: verificare che il calcolo avvenga dove lo controlli. Per gli utenti che eseguono l'hashing di una chiave API o che verificano un file, utilizzare prima il controllo del pannello di rete. Per i sistemi di produzione, utilizzare HMAC o firme invece di semplici hash per l'autenticazione. Il calcolatore hash ToolAcre SHA è uno strumento per l'apprendimento e per il calcolo del digest locale. Non è appropriato per l'autenticazione della produzione.
Conclusione: verifica, poi fidati: il calcolatore di hash ToolAcre SHA viene eseguito nel tuo browser, non carica nulla e non memorizza nulla tra una visita e l'altra
Il principio di trasparenza è centrale nell'approccio ToolAcre: ogni strumento documenta cosa fa, cosa fornisce il browser e cosa deve fare lo sviluppatore. Il calcolatore dell'hash SHA documenta che utilizza l'implementazione Web Crypto del browser per SHA-256, SHA-384 e SHA-512 e che non implementa HMAC o la derivazione della chiave. Per l'hashing, lo strumento è esatto. Per l'autenticazione, gli sviluppatori devono cercare altrove. Questa chiarezza previene la confusione che si crea quando un singolo strumento tenta di fare troppo.
Quando uno sviluppatore vede che il pannello di rete è vuoto e il codice sorgente è aperto, il rapporto di fiducia è su basi solide. Lo strumento fa ciò che afferma: calcola gli hash localmente utilizzando l'implementazione del browser. Lo sviluppatore può quindi prendere una decisione informata se lo strumento è adatto al proprio caso d'uso. Per verificare una chiave API, si adatta perfettamente. Per l'autenticazione di produzione, è necessario HMAC. Per l'archiviazione della password è necessaria una funzione di derivazione della chiave come Argon2id. Conoscere questi confini è il primo passo verso la creazione di sistemi sicuri.