Le estensioni hanno accesso a privilegi speciali all'interno del browser, il che le rende un obiettivo interessante per gli autori di attacchi. Se un'estensione viene compromessa, ogni utente dell'estensione diventa vulnerabile a intrusioni dannose e indesiderate. Per mantenere un'estensione sicura e proteggere i suoi utenti, incorpora queste pratiche.
Proteggere gli account sviluppatore
Il codice dell'estensione viene caricato e aggiornato tramite gli Account Google. Se gli account degli sviluppatori vengono compromessi, un autore di attacchi potrebbe inviare codice dannoso direttamente a tutti gli utenti. Proteggi questi account attivando l'autenticazione a due fattori , preferibilmente con un token di sicurezza.
Utilizzare i ruoli membro appropriati
Se il tuo editore ha più membri, assicurati che il ruolo concesso a ogni utente sia appropriato.
Non utilizzare mai HTTP
Quando richiedi o invii dati, evita una connessione HTTP. Supponi che tutte le connessioni HTTP abbiano intercettatori o contengano modifiche. HTTPS dovrebbe essere sempre preferito, in quanto ha una sicurezza integrata che aggira la maggior parte degli attacchi man-in-the-middle.
Richiedere autorizzazioni minime
Il browser Chrome limita l'accesso di un'estensione ai privilegi che sono stati richiesti esplicitamente in il manifest. Le estensioni devono ridurre al minimo le autorizzazioni registrando solo le API e i siti web da cui dipendono.
La limitazione dei privilegi di un'estensione limita ciò che un potenziale autore di attacchi può sfruttare.
fetch() multiorigine
Un'estensione può utilizzare fetch() e XMLHttpRequest() solo per ottenere risorse dall'
estensione e dai domini specificati nelle autorizzazioni. Tieni presente che le chiamate a entrambi vengono intercettate da
il gestore di recupero nel service worker.
{
"name": "Very Secure Extension",
"version": "1.0",
"description": "Example of a Secure Extension",
"host_permissions": [
"https://developer.chrome.com/*",
"https://*.google.com/*"
],
"manifest_version": 3
}
Questa estensione nell'esempio precedente richiede l'accesso a qualsiasi elemento su developer.chrome.com e ai sottodomini di Google
elencando "https://developer.chrome.com/*" e "https://*.google.com/*" nelle autorizzazioni. Se l'
estensione fosse compromessa, avrebbe comunque l'autorizzazione a interagire solo con i siti web che soddisfano
il pattern di corrispondenza. L'autore dell'attacco avrebbe solo una capacità limitata di accedere a "https://user_bank_info.com" o
interagire con "https://malicious_website.com".
Limitare i campi del manifest
L'inclusione di chiavi e autorizzazioni non necessarie nel manifest crea vulnerabilità e rende un'estensione più visibile. Limita i campi del manifest a quelli su cui si basa l'estensione.
Connettibile esternamente
Utilizza il campo "externally_connectable" per dichiarare con quali estensioni e pagine web esterne l'
estensione scambierà informazioni. Limita le fonti attendibili con cui l'estensione può connettersi esternamente.
{
"name": "Super Safe Extension",
"externally_connectable": {
"ids": [
"iamafriendlyextensionhereisdatas"
],
"matches": [
"https://developer.chrome.com/*",
"https://*.google.com/*"
],
"accepts_tls_channel_id": false
},
...
}
Risorse accessibili dal web
Se rendi le risorse accessibili dal web, in "web_accessible_resources", un'
estensione sarà rilevabile da siti web e autori di attacchi.
{
...
"web_accessible_resources": [
{
"resources": [ "test1.png", "test2.png" ],
"matches": [ "https://web-accessible-resources-1.glitch.me/*" ]
}
]
...
}
Più risorse accessibili dal web sono disponibili, più modi un potenziale autore di attacchi può sfruttare. Mantieni questi file al minimo.
Includere una policy di sicurezza dei contenuti esplicita
Includi una policy di sicurezza dei contenuti per l'estensione nel manifest per impedire attacchi di cross-site scripting. Se l'estensione carica risorse solo da se stessa, registra quanto segue:
{
"name": "Very Secure Extension",
"version": "1.0",
"description": "Example of a Secure Extension",
"content_security_policy": {
"extension_pages": "default-src 'self'"
},
"manifest_version": 3
}
Se l'estensione deve utilizzare WebAssembly o aumentare le restrizioni sulle pagine in sandbox, può essere aggiunta:
{
"name": "Very Secure Extension",
"version": "1.0",
"description": "Example of a Secure Extension",
"content_security_policy": {
"extension_pages": "script-src 'self' 'wasm-unsafe-eval'; object-src 'self';",
"sandboxed_pages":"script-src 'self' 'wasm-unsafe-eval'; object-src 'self';"
},
"manifest_version": 3
}
Evitare document.write() e innerHTML
Sebbene possa essere più semplice creare dinamicamente elementi HTML con document.write() e innerHTML, l'estensione e le pagine web da cui dipende sono esposte all'inserimento di script dannosi da parte degli autori di attacchi. Crea invece manualmente i nodi DOM e utilizza innerText per inserire contenuti dinamici.
function constructDOM() {
let newTitle = document.createElement('h1');
newTitle.innerText = host;
document.appendChild(newTitle);
}
Utilizzare con cautela gli script di contenuti
Sebbene gli script di contenuti vivano in un mondo isolato, non sono immuni agli attacchi:
- Gli script di contenuti sono l'unica parte di un'estensione che interagisce direttamente con la pagina web. Per questo motivo, le pagine web ostili potrebbero manipolare parti del DOM da cui dipende lo script di contenuti, o sfruttare comportamenti sorprendenti degli standard web, come gli elementi denominati.
- Per interagire con il DOM delle pagine web, gli script di contenuti devono essere eseguiti nello stesso processo di rendering della pagina web. In questo modo, gli script di contenuti sono vulnerabili alla perdita di dati tramite attacchi side-channel (ad es. Spectre) e possono essere violati da un autore di attacchi se una pagina web dannosa compromette il processo di rendering.
Le operazioni che utilizzano dati sensibili (ad esempio le informazioni private di un utente) o le API Chrome con accesso alle funzioni del browser devono essere eseguite nel service worker delle estensioni. Evita di esporre accidentalmente i privilegi dell'estensione agli script di contenuti:
- Supponi che i messaggi di uno script di contenuti possano essere stati creati da un autore di attacchi (ad es. convalida e sanifica tutti gli input e proteggi gli script dal cross-site scripting).
- Supponi che tutti i dati inviati allo script di contenuti possano essere divulgati alla pagina web. Non inviare dati sensibili (ad es. segreti dell'estensione, dati di altre origini web, cronologia di navigazione) agli script di contenuti.
- Limita l'ambito delle azioni privilegiate che possono essere attivate dagli script di contenuti. Non consentire
agli script di contenuti di attivare richieste a URL arbitrari o di passare argomenti arbitrari alle
API delle estensioni (ad es. non consentire il passaggio di URL arbitrari ai metodi
fetch()ochrome.tabs.create()).
Registrare e sanificare gli input
Proteggi un'estensione da script dannosi limitando i listener solo a ciò che l'estensione si aspetta, convalidando i mittenti dei dati in entrata e sanificando tutti gli input.
Un'estensione deve registrarsi solo per runtime.onMessageExternal se prevede
comunicazioni da un sito web o un'estensione esterni. Convalida sempre che il mittente corrisponda a una fonte attendibile.
// The ID of an external extension
const kFriendlyExtensionId = "iamafriendlyextensionhereisdatas";
chrome.runtime.onMessageExternal.addListener(
function(request, sender, sendResponse) {
if (sender.id === kFriendlyExtensionId)
doSomething();
});
Anche i messaggi tramite l'evento runtime.onMessage dell'estensione stessa devono essere esaminati attentamente per assicurarsi che MessageSender non provenga da uno script di contenuti compromesso.
chrome.runtime.onMessage.addListener(function(request, sender, sendResponse) {
if (request.allowedAction)
console.log("This is an allowed action.");
});