Posted by Le pagine web sono una zona di battaglia per la sicurezza delle informazioni mentre combattiamo gli hacker che cercano di rubare i segreti aziendali. Le pagine web moderne spesso sfruttano risorse da più di un’origine (dominio). Con l’aumentare della pressione sui problemi di sicurezza che interessano le nuove funzionalità, i webmaster dispongono di un elenco crescente di opzioni dai produttori di browser, comprese quelle per le risorse “cross-origin” per aiutare a prevenire fughe di informazioni.
Misure di sicurezza
Potresti già avere familiarità con rel = "noopener" , un modo per assicurarti che i link ipertestuali e gli elementi del modulo con azioni in uscita, come i link che aprono un altro sito in un nuovo scheda del browser, non consentire a una pagina esterna di accedere a una pagina interna tramite la proprietà Window.opener .
Immagina di fare clic su un collegamento che apre una nuova scheda. Quando chiudi la nuova scheda, la pagina originale è stata segretamente passata a una con esche di phishing. I produttori di browser vogliono fornire impostazioni di sicurezza sofisticate per i webmaster in modo da poter bloccare ed “consentire-list” domini che possono utilizzare, ad esempio, la proprietà Window.opener per prevenire esattamente tali attacchi.
Potresti aver visto riferimenti al campo dell’intestazione della risposta http Cross-Origin-Resource-Sharing ( CORS ). I valori CORS ( Access-Control-Allow- * ) limiteranno l’accesso solo a una serie di domini specificati come elenco. Quando la tua pagina include analisi, pubblicità e altre risorse di script di terze parti, quelle non specificatamente in un elenco di autorizzazioni (quando usi CORS) vengono bloccate e attiveranno messaggi di errore della console del browser per informarti.
Spectre meltdown
Quando le cose si surriscaldano, è più sicuro disattivare del tutto una funzione del browser. Questo è quello che è successo con SharedArrayBuffers quando i produttori di browser lo hanno puntato per affrontare i problemi lungo la strada. Dopo che un proof of concept ha dimostrato una vulnerabilità “side-channel” entro 6 mesi dal suo debutto nel 2017, SharedArrayBuffers è stato messo da parte nel 2018 fino a poco tempo fa, nel gennaio 2021.
In poche parole, un attacco race condition ha consentito l’accesso ingiustificato a una cache di memoria privata nelle CPU vulnerabili ( Spectre ), che a sua volta consente l’accesso teorico da parte di una pagina di malware ad altre pagine che un utente potrebbe avere aprire in un altro contesto del browser (sessione). Le informazioni fuoriuscite da questo tipo di attacco possono costituire informazioni di identificazione personale altamente sensibili che possono esporre a furti di identità e potenzialmente consentire attacchi mirati contro le organizzazioni, compresi i sistemi governativi.
Android Chrome 88 di Google e Chrome 91 desktop, più Firefox 79+, implementano tutti SharedArrayBuffers di nuovo dopo che hanno deciso che una nuova impostazione dei criteri di sicurezza mitiga il pericolo derivante dall’accesso di terze parti a memoria privata. L’accesso alla memoria condivisa è bloccato per tutte le risorse non specificatamente su un elenco di autorizzazioni che segue il protocollo come delineato nelle nuove direttive di risposta http.
Fallimenti silenziosi
API come WebGLRenderingContext implementano la funzione, che non funzionava silenziosamente durante il periodo di blackout temporaneo. Le implementazioni che in precedenza passavano inosservate, in cui gli sviluppatori non sono a conoscenza e mancano delle nuove impostazioni di sicurezza, ricevono improvvisamente avvisi in Google Search Console mentre i rapporti di errore iniziano ad accumularsi.
Email di errore GSC incomprensibili che oggi raggiungono nuove vette: #SharedArrayBuffers #COOP #COEP pic.tnwitterh.com/v02 19459006]
– Joost de Valk (@jdevalk) 15 marzo 2021
Implementazione della nuova politica di sicurezza
È stata a lungo una best practice stabilire una policy di sicurezza con CORS come perimetro solo attorno alle risorse di terze parti che si intende utilizzare. Senza una politica di sicurezza in atto, risorse di terze parti causano già abbastanza scompiglio, per non parlare della possibilità di divulgare i tuoi segreti. Si desidera consentire le risorse dell’elenco che non riescono utilizzando un criterio di sicurezza “ sfiducia per impostazione predefinita “. Solo lavorando intenzionalmente da errori (script bloccati) vorresti aggiungere alla tua lista di permessi per limitare i rischi.
Le impostazioni devono essere configurate utilizzando le intestazioni di risposta http della pagina del punto di ingresso. Quando gestisci il tuo server web, puoi modificare le intestazioni delle pagine utilizzando le impostazioni di configurazione nel framework o nello stack tecnologico che alimenta il tuo sito web. In alternativa, alcune reti di distribuzione dei contenuti (CDN) offrono la possibilità di modificare le intestazioni di risposta al volo. In ogni caso, si tratta di aggiungere nomi e valori di campo, una direttiva per riga.
Isolamento cross-origin
L’ambiente di sicurezza in cui si blocca l’accesso, pur consentendo la nuova implementazione di SharedArrayBuffers, è chiamato isolamento tra origini . Per configurare Cross-Origin Isolation , aggiungi due nuove intestazioni di pagina, COOP e COEP, come illustrato di seguito, che funzionano in tandem con una o più altre intestazioni di sicurezza, ovvero CORS e or CORP , che singolarmente o in combinazione forniscono i domini cross-origin presenti nella white list.
Cross-Origin-Embedder-Policy : require-corp
Cross-Origin-Opener-Policy : stessa origine Google utilizza l’API di reporting di Chrome open source per raccogliere le azioni che si verificano contro questi criteri di sicurezza. Quando si accumula un numero significativo, potrebbero provare a trovare un modo per avvisarti come sembra essere il caso di un utente di Google Search Console.
Un campo di intestazione di pagina Report-To specifico di Chrome può essere utilizzato per trasmettere i dati al proprio repository, sebbene sia molto più semplice controllare semplicemente lo stato booleano della proprietà crossOriginIsolated di l’API sperimentale WindowWorkerGlobalScope durante lo sviluppo. In questo modo, puoi gestire questi problemi direttamente dal tuo flusso di lavoro di sviluppo.
if (crossOriginIsolated) {
// Post SharedArrayBuffer
console.log ("CrossOriginIsolation: true")
} altro {
// Fai qualcos'altro
console.log ("CrossOriginIsolation: false")
} Perché ci interessa
Dato che gli errori di best practice delle norme di sicurezza già attivano avvisi in Lighthouse e messaggi di errore nelle console dei browser, e in questo caso il servizio Search Console di Google, dobbiamo comprendere i dettagli per offrire i nostri consigli su cosa fare. Se siamo coinvolti nello sviluppo web, allora vogliamo che siano preparate informazioni specifiche in modo da poter guidare o condurre l’implementazione di una correzione come parte del nostro lavoro.
La sicurezza delle informazioni è importante, come evidenziato da SharedArrayBuffers , modifiche alla politica sui cookie e molte altre questioni simili sono all’orizzonte.