Elenco di controllo della sicurezza di base per l'utilizzo di una libreria open source

L'open source non è di per sé né una garanzia di qualità, né l'assicurazione di un codice innocuo. Non ho esempi di applicazioni, framework o librerie open source che abbiano contenuto una backdoor volontaria, ma dobbiamo essere consapevoli che:

Le vulnerabilità
• possono essere difficili da trovare e influire sull'intera applicazione. Un buon esempio di ciò è un difetto di implementazione in OpenSSL che potrebbe consentire a un utente malintenzionato di rubare qualsiasi segreto incluse le chiavi private: ref. su wikipedia
• Il codice riservato o il codice raramente esaminato dagli esperti di sicurezza (ad esempio le utilità php) potrebbe avere una backdoor per un tempo piuttosto lungo prima che venga scoperto e reso pubblico.

Le pratiche comuni si affidano solo al software aperto ben noto , perché più sono usate, più possibilità ci sono che il codice dannoso venga scoperto.

Per essere onesti, dovresti anche notare che il software commerciale ha quasi sempre una limitazione della responsabilità . Ciò significa che non sei più protetto con software commerciale che con software gratuito (open source), e almeno quest'ultimo ti dà la possibilità di controllare il loro codice - o di pagare un esperto per farlo per te.

Ma non dovresti affidarti a software scarsamente recensito, anche se open source per un'applicazione altamente sensibile. Come al solito, deve essere considerato il buon rapporto rischio / costo.

C'è una differenza tra lato server e lato client qui. Dal momento che stai parlando di scrollbar e editor di markdown, presumo che si tratti di client side. Sarei meno interessato ai problemi del lato client, dal momento che la maggior parte dei browser moderni riprende velocemente problemi di sicurezza. Inoltre, i browser cercano di limitare i rischi per la sicurezza e, a volte, agiscono per conto dell'utente (rilevati malware, richieste xhr non valide).

Lato client

Le backdoor sono piuttosto rare per queste librerie o qualsiasi parte del software lato client. Pensato che esistano, HTML5 e il moderno web hanno spinto i browser a implementare alcuni trucchi per prevenire attività dannose, ad esempio; stessa origine, contenuto misto, blocchi popup e avvisi iframe, rimozione di flash, activex e applet e così via ...

Lato server

Il lato server è un'altra storia. Se si utilizzano librerie di terze parti (siano esse opensource o meno) si espone l'ambiente in cui viene eseguita l'applicazione. Spesso le tecniche utilizzate come il jailing, gli autdit, le autorizzazioni per directory applicative e per database (operazioni) minimizzano la possibilità di corrompere / accedere correttamente ai dati e / o ad altri dati ambientali.

Per rispondere alla domanda, si tratta di un problema legittimo che può causare un errore catastrofico. Non è facile / impossibile controllare ogni pezzo di codice che semplicemente. Oggigiorno le strutture dipendono molto da plugin, estensioni e librerie. Opensource non equivale a correzioni rapide di sicurezza, ma possiamo supporre che più persone usano qualcosa, i bug più veloci sono segnalati e risolti. Metti in atto i sistemi per limitare le possibilità quando fa non funziona. Avere un piano di emergenza, progettare per il fallimento, usare i log (di controllo), fare in modo che i daemon eseguano la scansione degli accesslogs e così via. Quando si tratta di backdoor, le persone sembrano spesso dimenticare il firewall in uscita.

Quando si uniscono i componenti lato client e li si distribuiscono a un browser come parte dell'applicazione nel contesto del dominio da cui viene servita l'applicazione, il codice viene eseguito all'interno del limite di attendibilità che il browser presume esista con il dominio .

Ciò significa che quel codice di terze parti può fare qualsiasi cosa che il codice della prima parte possa fare. Ha una visibilità DOM completa, può raggiungere server di terze parti, può visualizzare tag di annunci e di tracciamento sul browser, ecc. Questa è un'esposizione significativa.

In termini di cosa si può fare per difendere questa esposizione:

1. Gestire versioni e dipendenze e verificare un servizio di vulnerabilità come retire.js può presentare una protezione contro vulnerabilità note. In questo senso, scoraggiare copia-incolla del codice di terze parti in favore di dipendenze esplicite. Forse questa pratica è già in uso.

2. L'uso delle intestazioni di Content-Security-Policy consente di autorizzare l'utilizzo e la comunicazione con terze parti:

   link

3. Guidare l'applicazione con Selenium, ecc., in un ambiente sandbox / test con un proxy offre l'opportunità di scoprire a volte nuove comunicazioni e utilizzo di terze parti una volta introdotti.

   Detto questo, gli aggressori più sofisticati con codice nel percorso di esecuzione cercano di rilevare quando vengono eseguiti in ambienti sandbox o in una modalità di rilevamento e non attiveranno il payload delivery.