it-swarm-eu.dev

Come potrò mai "controllare" oltre 120.000 righe di Composer PHP codice non scritto da me?

Dipendo da PHP CLI per tutti i tipi di "logica aziendale" personale e (si spera, presto) professionale/mission-critical. (Potrebbe trattarsi di qualsiasi altra lingua e lo stesso identico problema sarebbe ancora valido ; Sto solo affermando ciò che uso personalmente per motivi di contesto.)

Nella misura del possibile, scrivo sempre tutto da solo. Solo quando assolutamente necessario, ricorrere con riluttanza all'uso di una libreria di terze parti. Per alcune cose, questo è semplicemente necessario. Ad esempio, l'analisi della posta elettronica e altre cose molto complicate come questa.

Per la gestione di tali librerie di terze parti, utilizzo PHP Composer . È un gestore di librerie per PHP. È in grado di scaricare le librerie e le loro dipendenze e aggiornarle con comandi simili ad altri "gestori di pacchetti". In senso pratico, questo è molto più bello che tenerne traccia manualmente e scaricare manualmente i file Zip e decomprimerli e affrontare tutti i tipi di problemi. Almeno risparmia molti mal di testa pratici.

Comunque, il problema di sicurezza più importante persiste ancora: non ho idea di cosa contenga questo codice "installato", né so cosa viene aggiunto/modificato con ogni aggiornamento? Uno degli autori delle biblioteche avrebbe potuto facilmente essere compromesso un giorno quando my Composer recupera gli aggiornamenti, causando i miei script CLI PHP per inviare improvvisamente il mio portafoglio Bitcoin.dat su un server remoto, installare un RAT/trojan sul mio computer, o peggio ancora. In effetti, potrebbe già essere successo e non sarei il più saggio. Semplicemente non ne ho idea. Logicamente non posso averne idea.

La mia base di codice è di circa 15.000 righe in totale. Mi ci vuole più di un anno per esaminare scrupolosamente quella base di codice. E questo è il codice che [~ # ~] i [~ # ~] hanno scritto e che conosco intimamente ...

La mia struttura di directory "Composer" è attualmente in oltre 120.000 righe di codice. E questo è per il minimo numero di cruciale PHP librerie di cui ho bisogno. Ne uso pochissime, ma hanno varie dipendenze e tendono ad essere molto gonfie/gonfiate rispetto al mio codice.

Come potrei mai "controllare" tutto questo ?! Semplicemente non accadrà. "Escludo" molto poco dopo aver tentato. Non so nemmeno come farò attraverso un altro "giro di veterinari" di il mio codice - per non parlare di questo 10 volte più grande, codificato da altre persone.

Quando la gente dice che è un "must" per "controllare il codice di terze parti", cosa significano esattamente? Concordo anche sul fatto che è un "must", ma poi c'è la fastidiosa realtà. Semplicemente non avrò mai il tempo e l'energia per farlo. Inoltre, ovviamente non ho i soldi per pagare qualcun altro per farlo.

Ho trascorso innumerevoli ore cercando di conoscere Docker e vedere se ci fosse un modo per "incapsulare" queste librerie di terze parti non attendibili in qualche modo, ma è una battaglia persa. Ho trovato assolutamente impossibile farlo, o ho risposto a una qualsiasi delle mie molte domande in merito. Non penso nemmeno che sia possibile nel modo in cui lo immagino.

86

Non puoi controllare singole righe di codice. Morirai solo cercando di farlo.

Ad un certo punto, devi fidarti di qualcun altro. Nel 1984, Ken Thompson, uno dei co-inventori di gran parte di Unix, scrisse un breve articolo sui limiti di trust . Ad un certo punto, devi fidarti delle altre persone, devi fidarti che chiunque abbia scritto il tuo editor di testo non nasconda automaticamente un codice Trojan che l'interprete PHP eseguirà in alcuni Bitcoin rubando malware .

Devi fare un'analisi costi-benefici per dare priorità al tuo veterinario.

Per la maggior parte, dovresti fare del tuo meglio per controllare gli autori del codice, le pratiche di sicurezza interna del progetto e il modo in cui il codice ti raggiunge. La revisione effettiva del codice è costosa e difficile, quindi dovrebbero essere riservati per le parti che ritieni più importanti per il tuo progetto.

La biblioteca è una biblioteca popolare che viene utilizzata da molte persone con una compagnia rispettabile o un noto progetto guidato dietro di essa? Il progetto ha in atto adeguati processi di gestione del progetto? La biblioteca ha una buona storia passata di problemi di sicurezza e come li ha gestiti? Ha dei test per coprire tutti i comportamenti che deve gestire? Supera i suoi test? Quindi si riduce il rischio che la biblioteca venga compromessa senza che nessuno se ne accorga.

Prendi alcuni file di esempio per un'analisi più approfondita. Vedi qualcosa che riguarda lì? Se i pochi file che hai preso hanno problemi importanti, probabilmente puoi dedurre che il resto della base di codice ha problemi simili; se hanno un bell'aspetto, allora aumenta la tua sicurezza che il resto della base di codice sia scritto allo stesso modo. Si noti che in basi di codice molto grandi, ci saranno diverse aree del codice con livelli variabili di qualità del codice.

Il repository del gestore pacchetti controlla la firma del pacchetto? Esiste un sistema di pre-controllo per registrare un pacchetto nel repository o è un repository di registrazione aperto? Ricevi la libreria sotto forma di codice sorgente o come binario precompilato? Ciò influisce su quanto puoi fidarti della biblioteca, sui fattori di rischio e su come migliorare ulteriormente la fiducia.

È inoltre necessario considerare l'applicazione e l'ambiente di esecuzione su cui verrà eseguita l'applicazione. È per un codice di sicurezza nazionale? Questo codice fa parte di un eCommerce o di una banca che gestisce i numeri di carta di credito? Questo codice funziona come superutente? Questo codice è critico/di sicurezza? Esistono controlli compensativi per isolare ed eseguire il codice con privilegi diversi (ad es. Container, VM, autorizzazioni utente)? Questo codice è per un progetto secondario del fine settimana? Il modo in cui rispondi a queste domande dovrebbe permetterti di definire un budget su quanto puoi investire nel codice di verifica e quindi come stabilire le priorità di quali librerie necessitano di verifica, a quale livello e quali vanno bene con minore fiducia.

140
Lie Ryan

Il mio albero di directory "Composer" è attualmente a oltre 120.000 righe di codice. E questo è per il numero minimo di PHP librerie cruciali di cui ho bisogno.

Il tuo errore è nel tentativo di controllare il codice di terze parti come se fosse il tuo. Non puoi e non dovresti provare a farlo.

Non hai menzionato nessuna delle librerie per nome, ma suppongo che una buona parte di essa sia lì perché stai utilizzando uno dei framework più grandi, come Laravel o - Symfony . Framework come questo, come con le altre principali librerie, hanno i loro team di sicurezza; i problemi vengono risolti rapidamente e l'installazione degli aggiornamenti è banale (purché si disponga di una versione supportata).

Invece di provare a controllare tutto quel codice da soli, devi lasciarti andare e fidarti del fatto che il venditore ha fatto - e continua a fare - quel controllo per te. Questo è, dopotutto, il motivo per cui si utilizza un codice di terze parti.

Realisticamente, dovresti trattare le librerie di terze parti PHP esattamente come tratteresti le librerie di terze parti in un ambiente compilato come . NET o Java. In quelle piattaforme, le librerie sono disponibili come file DLL o simili e potresti non vedere mai il codice sorgente. Non puoi controllarli e non ci proveresti. Se il tuo atteggiamento verso una libreria PHP è diverso da quello, allora devi chiederti perché. Solo perché tu puoi leggere il codice non significa che tu guadagni qualcosa dal farlo.

Ovviamente, tutto ciò si verifica se le librerie di terze parti includono quelle più piccole che non sono supportate o non dispongono di una politica di sicurezza. Quindi questa è la domanda che devi porre a tutte le librerie che stai usando: sono pienamente supportate e hanno una politica di sicurezza che ti fa sentire a tuo agio. Per quelli che non lo fanno, allora potresti prendere in considerazione l'idea di trovare un'alternativa a quelle librerie. Ma ciò non significa ancora che dovresti provare a controllarli da soli, a meno che tu non intenda effettivamente assumerne il supporto.

Una cosa che aggiungerò, tuttavia: se si desidera eseguire un controllo di sicurezza sul codice PHP, si consiglia vivamente di utilizzare scanner RIPS . Non è economico, ma se hai forti requisiti di sicurezza, è facilmente il miglior strumento di analisi della sicurezza automatizzata che puoi ottenere per PHP. Sicuramente eseguilo sul tuo codice; probabilmente rimarrai sorpreso dal numero di problemi rilevati. Naturalmente, potresti eseguirlo anche su librerie di terze parti se sei abbastanza paranoico. Ti costerà molto di più, e i miei punti sopra rimangono ancora; dovresti davvero fidarti dei tuoi fornitori di terze parti per fare questo genere di cose da soli.

47
Spudley

Benvenuto nel nuovo paradigma della codifica: stai usando librerie in cima alle librerie. Sei a malapena solo, ma devi anche capire che ogni volta che porti codice che non hai scritto, rischi.

La tua vera domanda è come posso gestire quel rischio?

Comprendi cosa dovrebbe fare il tuo software

Troppo spesso, i gestori di biblioteche diventano un modo conveniente per schiaffeggiare il codice in quel "solo lavoro", senza mai preoccuparsi di capire ad alto livello cosa dovrebbe fare. Pertanto, quando il tuo codice di libreria attendibile fa cose cattive , sei sorpreso, chiedendoti cosa è successo. È qui che nit testing può essere d'aiuto, in quanto verifica cosa dovrebbe fare il codice.

Conosci le tue fonti

Il compositore (o qualsiasi gestore di pacchetti) può installare da qualsiasi fonte specificata, inclusa una libreria arrotolata ieri da una fonte completamente sconosciuta. Ho installato volentieri pacchetti da fornitori che dispongono di SDK, poiché il fornitore è una fonte altamente affidabile. Ho anche usato pacchetti da fonti che svolgono altri lavori di fiducia (ad es. Qualcuno nel progetto PHP ha un repository di librerie). La fiducia cieca di qualsiasi fonte può metterti nei guai.

Accetta che esiste un rischio che non puoi mai mitigare completamente

Nel 2016, un singolo sviluppatore di NodeJS paralizzato una tonnellata di pacchetti quando hanno lasciato il progetto e hanno richiesto che le loro librerie non fossero pubblicate. Avevano una semplice libreria che centinaia di altri pacchetti elencavano come dipendenza. O forse l'infrastruttura non è stata costruita per gestire la distribuzione dei pacchetti quindi fallisce in modo casuale. Internet è diventato così bravo a "far funzionare le cose" nel mondo dello sviluppo del software distribuito, che le persone tendono a essere turbate o confuse quando smette di funzionare.

Quando PHP 7.0, ho dovuto fare un sacco di lavoro per creare un pacchetto software di terze parti open source che usiamo funzione nell'ambiente 7.0. Da parte mia ci sono voluti dei tempi significativi, ma sono stato in grado di aiutare l'autore di quel pacchetto a risolvere alcuni problemi e renderlo utilizzabile nell'ambiente 7.0. L'alternativa era sostituirlo ... che avrebbe richiesto ancora più tempo. È un rischio che accettiamo perché quel pacchetto è abbastanza utile.

27
Machavity

Tuttavia, il problema di sicurezza più importante persiste ancora: non ho idea di cosa contenga questo codice "installato", né so cosa viene aggiunto/modificato con ogni aggiornamento. Uno degli autori delle biblioteche avrebbe potuto facilmente essere compromesso un giorno quando my Composer recupera gli aggiornamenti, causando i miei script CLI PHP per inviare improvvisamente il mio portafoglio Bitcoin.dat su un server remoto, installare un RAT/trojan sul mio computer, o peggio ancora. In effetti, potrebbe già essere successo e non sarei il più saggio. Semplicemente non ne ho idea. Logicamente non posso averne idea.

Cerca Heartbleed , l'enorme buca di sicurezza in OpenSSL. Heartbleed ha efficacemente nerfatto SSL salvando prima le ultime centinaia o migliaia di transazioni (crittografate in rete) come testo normale e quindi lasciando una struttura semplice e non blog per chiunque ne fosse a conoscenza per connettersi in remoto e recuperare tutte le transazioni memorizzate nella cache che gli utenti pensavano sono stati crittografati in modo sicuro, in testo semplice. A quel tempo OpenSSL stava proteggendo la stragrande maggioranza dei siti Web self-hosted e un numero enorme di banche e persino servizi di intelligence del governo.

Quindi cerca Meltdown e Spectre , enormi bug incorporati nelle moderne CPU Intel. Meltdown e Spectre contrastano completamente l'esecuzione di una CPU in modalità protetta e, essendo indipendenti dal sistema operativo, sono sfruttabili su ogni sistema operativo.

Anni e anni fa, un malware chiamato MSBlaster sfruttava un (non sono nemmeno sicuro che fosse un bug - solo un eccezionalmente stupido) Windows XP servizio in background che non aveva alcuna attività commerciale in esecuzione per impostazione predefinita: sarebbe stato utilizzato attivamente solo da una vasta minoranza di utenti Windows e poi conosciuto solo dai dipartimenti IT. Ciò ha spinto gli ISP a emettere firewall hardware integrati nei loro dispositivi modem e ha spinto Microsoft a incorporare un firewall software integrato nei loro sistemi operativi. Nello stesso periodo, è stato scoperto che una distribuzione della presunta piattaforma Linux "a prova di virus" contiene un rootkit incorporato nella versione principale della distribuzione.

Come altri hanno già detto: a un certo punto devi fidarti di qualcuno. Sia gli incidenti che la malizia causano problemi. Sono come te - grande fan di The X-Files e - plink (FIDUCIA NESSUNO!) - ma la realtà è che il tuo motore di crittografia SSL o i tuoi dispositivi hardware fisici hanno la stessa probabilità di presentare falle nella sicurezza e quelle hanno molte più probabilità di rappresentare guasti critici quando si presentano.

Se sei seriamente intenzionato a fare quel miglio in più per reinventare la Composer per la sicurezza di te e dei tuoi utenti, allora sii serio nel fare quel miglio in più: costruisci la tua CPU, scheda madre, RAM, HDD e unità ottiche. Scrivi il tuo sistema operativo e driver hardware. Crea anche i tuoi compilatori. E dimenticati di PHP perché potrebbero esserci problemi nell'interprete - in effetti dimentica anche C e C++ perché potrebbero esserci problemi nel compilatore e non pensare nemmeno al linguaggio Assembly con un assemblatore scritto da qualcun altro. Scrivi tutto il tuo software da zero nelle istruzioni della macchina, con un editor esadecimale.

Oppure potresti agire come un membro del settore. Iscriviti alle newsletter degli aggiornamenti di Composer's/PHP's/YourLinuxDistro e magari accedi anche ad alcune newsletter indipendenti basate sulla sicurezza e ottieni un abbonamento a Wired. Rivedi i log di sistema. Testare periodicamente la rete con un PCAP per assicurarsi che non vi siano flussi di rete non autorizzati né in entrata né in uscita. Sii proattivo nel monitorare possibili minacce e non paranoico su cose che non sono ancora avvenute.

3
user116960

Come sviluppatore di livello intermedio o avanzato, ho considerato lo stesso problema. Alcuni punti da considerare:

  • Priorità revisione del codice critico ai fini della sicurezza. Ovviamente ciò includerebbe cose come autenticazione e codice di accesso, convalida delle autorizzazioni, integrazioni del processore di pagamento . Tutto ciò che richiede informazioni sensibili o effettua chiamate di rete.
  • Visual skim cose come le librerie di stile - dovresti essere in grado di determinare rapidamente che stanno solo facendo lo stile - e cose come le funzioni di utilità. Stringhe maiuscole, sostituzioni di spazi bianchi, riordino di array ... dovresti essere in grado di scorrere rapidamente il codice e vedere che non stanno facendo nulla di inaspettato.
  • Anche se non decodifichi completamente il codice come se fosse il tuo, dovresti essere in grado di dare un'occhiata alla fonte e determinare se era previsto essere amichevole verso il reverse engineering . Il codice deve essere documentato con commenti utili, i nomi delle variabili e dei metodi devono essere pertinenti e utili, le funzioni e le implementazioni non devono essere troppo lunghe o troppo complesse o contenere funzionalità non necessarie. Codice molto piacevole alla vista non è certamente il vettore di attacco preferito dagli hacker malintenzionati.
  • Conferma che il codice ha un base utenti consolidata e matura. Volete gravitare verso progetti che le aziende redditizie e famose sono note per usare.
  • Conferma identità del mondo reale dei principali collaboratori. Per progetti su larga scala, lo sviluppatore principale sarà lieto di prendersi il merito per il loro lavoro. Dovresti essere in grado di trovare post di blog, account di social media e probabilmente un curriculum o una pagina di marketing per il lavoro di consulenza. Contattami! ecc.
  • Conferma che il codice open source è gestito attivamente con correzioni recenti. Guarda le segnalazioni di bug in sospeso - ce ne sono alcune - e non fidarti delle affermazioni secondo cui un determinato strumento o libreria è privo di bug. È un'affermazione delirante.
  • Evita siti "freeware" con pubblicità eccessiva. Evita i progetti che non dispongono di un sito demo disponibile o in cui la demo è "brutta", mal gestita o spesso offline. Evita i progetti con troppe parole in eccesso o parole d'ordine eccessive, fai affermazioni non testate di prestazioni superiori. Evita di scaricare da blog anonimi. Eccetera.
  • Pensa maliziosamente. Se volessi rompere il tuo sito, cosa proveresti? Se volessi intrufolare codice non sicuro in una libreria ampiamente utilizzata, come lo faresti? (Non provarlo, ovviamente.)
  • Fork progetti open-source o download di backup. Non fidarti mai che il repository ufficiale del progetto open source che ti piace rimarrà online a tempo indeterminato.

Quindi, invece di tentare di leggere e comprendere ogni singola riga di codice singolarmente, basta avere un'idea di che cosa fa ogni libreria, e why credi che lo faccia. Penso davvero che, se il tuo lavoro è redditizio, non esiste un limite massimo alla dimensione di un progetto; puoi "controllare" oltre 1.200.000 righe di codice o 120.000.000+ righe di codice!

2

Il compositore può lavorare con un composer.lock file e, per impostazione predefinita, scarica i pacchetti tramite https://packagist.org/ (nota l'HTTP [~ # ~] s [~ # ~] .) Quindi hai un enorme repository di pacchetti e un download sicuro con il checksum SHA1 di accompagnamento per assicurarti di scaricare esattamente ciò che era stato specificato in precedenza. Solo questo ti aiuta parecchio.

Se rimani sul lato conservatore degli aggiornamenti delle dipendenze, puoi anche aspettarti che le versioni del pacchetto abbiano visto l'uso della produzione.

Alla fine, però, dovrai fidarti di qualcuno. Puoi fidarti di te stesso per scrivere codice privo di exploit, oppure puoi, come altri, fidarti dei progetti di community utilizzati da migliaia e visti da ancora più utenti.

Alla fine, però, non penso che tu abbia una scelta. Se gli altri "volano alla cieca", cioè senza i controlli di sicurezza che si vogliono fare, e prendono i "vostri" clienti con prezzi più bassi e versioni più veloci delle funzionalità, nessuno trarrà comunque beneficio dalla vostra applicazione sicura scritta da soli.

0
knallfrosch