Nelle estensioni del browser, l'impatto di una vulnerabilità dipende in gran parte dal contesto e dalle autorizzazioni richieste. Gli strumenti statici (JSHint, AMO validator) per verificare il codice esistono, ma nessuno di essi è affidabile al 100%, specialmente per il codice offuscato.

Quindi, non mostrerò un'espressione regolare magica che ti dice se un codice è vulnerabile o meno, ma fornisci una breve panoramica su come funzionano le estensioni e un piccolo elenco di potenziali problemi specifici delle estensioni.

Strumenti esistenti

Lo strumento di analisi del codice statico di Mozilla, utilizzato su addons.mozilla.org è pubblicamente disponibile come AMO Validator . Questo strumento funziona con tutti i componenti aggiuntivi Jetpack . Innanzitutto, identifica (per hash) ed esclude tutte le librerie JS autorizzate. Quindi, esegue questi casi di test sul restante contenuto dell'archivio XPI.

Nessuno degli altri fornitori ha pubblicato uno strumento del genere. Fortunatamente, estensioni (non plug-in) per Chrome / Safari / Opera non possono ottenere tutti i privilegi dei componenti aggiuntivi di Firefox.

Estrazione

I componenti aggiuntivi di Firefox (xpi) e Opera (oex) sono file zip con un'estensione diversa.
Le estensioni di Chrome (crx) sono file zip con una precedente intestazione CRX .
Le estensioni di Safari (safariextz) sono firmate archivi xar.

7-zip è in grado di estrarre tutti questi archivi.

Permessi

Chrome, Safari e Opera richiedono allo sviluppatore dell'estensione di dichiarare le autorizzazioni per accedere a determinate origini o funzioni. Queste dichiarazioni si possono trovare su:

• Chrome: /manifest.json . Vedi modelli di corrispondenza e avvisi di autorizzazione
• Safari: /<extension-name>.safariextension/Info.plist . Vedi Accesso e permessi .
• Opera: /config.xml . Vedi config.xml .

L'accesso all'origine non può essere configurato nei componenti aggiuntivi di Firefox.

Script contenuto / Script inseriti

Tutti gli ambienti di estensione supportano l'esecuzione del codice su pagine che corrispondono a un pattern URL predefinito. Questi sono chiamati script di contenuto in Chrome / Firefox e script di Injected in Opera / Safari. Questi script hanno accesso diretto al DOM della pagina, ma non hanno accesso diretto alle variabili JavaScript della pagina, perché i contesti di esecuzione sono diversi.

Pagine di sfondo

Queste pagine sono la parte più privilegiata di un'estensione.

Vulnerabilità

Non menzionerò errori evidenti come usare setTimeout con stringhe (questi sono già menzionati nella risposta di Bobince), o metodi inverosimili che sono improbabili che siano accidentali, come un'estensione che preleva le credenziali da una pagina e la invia a un servizio Web canaglia.

• Uso di .innerHTML o jQuery per analizzare l'HTML esterno (vedere questa domanda su Stack Overflow ):

  // Example 1:
  var heading = $(xhr.responseText).find('h1').text();
  // Example 2:
  document.body.innerHTML += '';
  // For: <img src="bogus" onerror="do_something_evil_with_privileges()">
  

• Uso dell'evento window.onmessage senza convalida dei dati o controllo event.origin . Nell'esempio seguente, qualsiasi terza parte può utilizzare window.open e postMessage per inviare un messaggio a Gmail e abusare delle caratteristiche trapelate involontariamente:

  // Content script running on https://mail.google.com/mail/
  addEventListener('message', function(event) {
      if (event.data.type === 'send-mail') doSomething();
      // or:
      notifyBackgroundPage(event.data);
  });
  

• Caricamento del codice esterno (JS) (peggio: caricamento di un codice esterno su http). Se la fonte esterna è compromessa, tutti gli utenti saranno suscettibili di abuso.

• Uso di framework di estensioni cross-browser come Crossrider e Kango . Questi sono convenienti per gli sviluppatori, ma le estensioni generate richiedono un numero non necessario di autorizzazioni.

• Non è sufficiente limitare l'influenza di un'API di estensione. Un esempio estremo: rimozione del flag di cookie httpOnly per tutti i siti, invece del solo sito pertinente. Ciò include anche l'esecuzione di script di contenuto su troppe pagine.

• Problemi di privacy:

  • Uso di servizi come Google Analytics (ricerca di _gaq.push )
  • Caricamento di risorse esterne, come i pulsanti dei social media.

La maggior parte dei vettori regolari sono rilevanti anche per le estensioni. Usa i cheatsheets sul link o dai un'occhiata al link .

Metodi comuni per iniettare JS da JS.

In quasi tutte le circostanze la cosa sbagliata:

• eval
• new Function()
• setTimeout e setInterval con una stringa per il primo parametro
• setAttribute (o equivalente quadro, ad esempio attr() ) su un attributo gestore eventi on... (o nome attributo variabile)
• javascript: URL

Può essere necessario in circostanze limitate, ma dovrebbe essere ridotto al minimo e le istanze rimanenti attentamente controllate:

• createElement('script') e impostazione del corpo del testo
• assegnazione di un URL esterno variabile a <script> o <link>
• tramite iniezione HTML - impostazione innerHTML su una stringa creata con una variabile senza escape, ad esempio div.innerHTML= '<p>'+message+'</p>' . Solitamente è meglio sostituire i metodi di creazione di contenuti in stile DOM (specialmente se si dispone di un framework per renderlo facile); per alcuni casi come enormi tavoli lunghi può essere necessaria una soluzione che implichi la creazione di markup
• Iniezione HTML nascosta dietro una funzione framework, ad esempio una qualsiasi delle funzioni di manipolazione jQuery ( .html() , .append() , .before() ecc.) chiamata con un argomento stringa (usa invece $('<div>', {dynamic attributes}) scorciatoia)

Può essere inevitabile in alcuni casi, ma è necessario verificare:

• utilizzando un URL variabile durante la navigazione di location , creando un collegamento o impostando immagine / oggetto / iframe / etc src (o new Image() o CSS url() proprietà). Esistono schemi URL pericolosi (inclusi, ma non limitati a, javascript: ), quindi questi richiedono la whitelist. Questo è un problema molto comune nelle estensioni del browser, che spesso finisce per fare un XSS universale
• Iniezione CSS nel set di contenuti in style elemento / attributo (utilizzando proprietà pericolose come legami ed espressioni per elevare all'iniezione JS)

Non sono sicuro di come si applicherebbe alle estensioni del browser, ma nelle app web di solito cerco stringhe codificate che vengono concatenate con variabili. Spesso non è un problema, ma mi aiuta a trovare i luoghi in cui l'HTML viene creato dall'input dell'utente grezzo. Ad esempio il codice potrebbe apparire come:

var myHtml = "<h1>" + userinput + "</h1>";

Questo non è sicuro perché l'input dell'utente potrebbe contenere HTML (incluso lo script), e dovrebbe essere codificato in HTML prima di essere utilizzato in questo modo.

Ecco un'espressione regolare che trova i casi di stringhe codificate che vengono concatenate con le variabili:

["']\s*\+|\+\s*["']