Non puoi esaminare singole righe di codice. Morirai solo provando a 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 dei trust. Ad un certo punto, devi fidarti di 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 che rubano malware.

Tu devi fare un'analisi costi-benefici per dare la priorità a ciò che controlli.

Per la maggior parte, dovresti fare del tuo meglio per controllare gli autori del codice, le pratiche di sicurezza interne del progetto e come il il codice ti raggiunge. In realtà la revisione del codice è costosa e difficile, quindi dovrebbe essere riservata alle parti che consideri più importanti per il tuo progetto.

La libreria è una libreria popolare utilizzata da molte persone con un'azienda rispettabile o un noto progetto alla base? Il progetto dispone di processi di gestione del progetto adeguati? La biblioteca ha una buona storia passata di problemi di sicurezza e come li ha gestiti? Dispone di test per coprire tutti i comportamenti che deve gestire? Supera i propri test? Quindi il rischio che la libreria venga compromessa senza che nessuno se ne accorga è ridotto.

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

Il tuo repository del gestore di pacchetti controlla la firma del pacchetto? È necessario un sistema di verifica preliminare per registrare un pacchetto nel repository o è un repository di registrazione aperto? Ricevete la libreria sotto forma di codice sorgente o come binario precompilato? Questi influenzano quanto ci si può fidare della libreria, i fattori di rischio e come si può ulteriormente migliorare 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 della gestione di un eCommerce o di una banca che gestisce i numeri di carta di credito? Questo codice funziona come superutente? Questo codice è critico per la vita / sicurezza? Disponi di controlli compensativi per isolare ed eseguire 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 consentirti di definire un budget su quanto puoi investire nella verifica del codice e quindi su come stabilire la priorità di quali biblioteche necessitano di controllo, a quale livello e quali vanno bene con minore fiducia.

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

Il tuo errore è provare a 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 presumo che una buona parte sia presente perché ne stai usando una dei framework più grandi, come Laravel o Symfony. Framework come questo, come con altre importanti librerie, hanno i propri team di sicurezza; i problemi vengono risolti rapidamente e l'installazione degli aggiornamenti è banale (fintanto che sei su una versione supportata).

Invece di provare a controllare tutto quel codice da solo, devi lasciar perdere e avere fiducia che fatto - e continua a farlo - quel controllo per te. Questo è, dopotutto, uno dei motivi per cui utilizzi codice di terze parti.

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

Dove tutto questo cade, ovviamente, è se le tue librerie di terze parti includono quelle più piccole che sono non supportato o non dispone di una politica di sicurezza. Quindi questa è la domanda che devi porre a tutte le librerie che stai utilizzando: sono completamente supportate e hanno una politica di sicurezza con cui ti senti a tuo agio. Per tutti quelli che non lo fanno, potresti prendere in considerazione la possibilità di trovare un'alternativa a quelle librerie. Ma ciò non significa che dovresti provare a controllarli da solo, a meno che tu non intenda effettivamente assumere il supporto per loro.

Una cosa che aggiungerò, tuttavia: se desideri eseguire un controllo di sicurezza sul tuo codice PHP, ti consiglio vivamente di utilizzare lo scanner RIPS. Non è economico, ma se hai forti requisiti di sicurezza, è facilmente il miglior strumento di analisi della sicurezza automatizzato che puoi ottenere per PHP. Sicuramente eseguilo sul tuo codice; probabilmente sarai sorpreso di quanti problemi rileva. Potresti, ovviamente, eseguirlo anche sulle tue librerie di terze parti se sei abbastanza paranoico. Ti costerà molto di più, però, e i miei punti sopra sono ancora validi; dovresti davvero fidarti dei tuoi fornitori di terze parti per fare questo genere di cose da soli.

Benvenuto nel nuovo paradigma di codifica: stai utilizzando le librerie sopra le librerie. Non sei certo solo, ma devi anche capire che ogni volta che inserisci del codice che non hai scritto, rischi un po '.

La tua vera domanda è come posso gestire quel rischio ?

Comprendi cosa dovrebbe fare il tuo software

Troppo spesso, i gestori di librerie diventano un modo conveniente per schiaffeggiare il codice in quanto "funziona", senza mai preoccuparsi per capire ad alto livello cosa dovrebbe fare. Pertanto, quando il codice della tua libreria di fiducia fa cose cattive, sei colto alla sprovvista, chiedendoti cosa sia successo. È qui che il test unitario può essere d'aiuto, poiché verifica ciò che il codice dovrebbe fare.

Conosci le tue fonti

Composer (o qualsiasi gestore di pacchetti ) può essere installato da qualsiasi origine specificata, inclusa una libreria arrotolata ieri da una fonte completamente sconosciuta. Ho installato volentieri pacchetti da fornitori che dispongono di SDK, perché il fornitore è una fonte altamente affidabile. Ho anche usato pacchetti da fonti che svolgono altri lavori attendibili (cioè qualcuno nel progetto PHP ha un repository di libreria). Affidarsi ciecamente a qualsiasi fonte può metterti nei guai.

Accetta il rischio che non puoi mai mitigare completamente

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

Quando è uscito 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. Ci è voluto un po 'di tempo da parte mia, ma ho potuto aiutare l'autore di quel pacchetto a risolvere alcuni problemi e renderlo utilizzabile nell'ambiente 7.0. L'alternativa era sostituirlo ... il che avrebbe richiesto ancora più tempo. È un rischio che accettiamo perché quel pacchetto è molto utile.

Tuttavia, il problema di sicurezza più fondamentale persiste: non ho idea di cosa contenga questo codice "installato", né so cosa viene aggiunto / modificato ad ogni aggiornamento. Uno degli autori delle biblioteche avrebbe potuto essere facilmente compromesso un giorno quando il mio Composer recupera gli aggiornamenti, facendo sì che i miei script PHP CLI inviassero improvvisamente il mio portafoglio Bitcoin.dat a qualche server remoto, installassero un RAT / trojan sulla mia macchina o anche peggio. In effetti, potrebbe già essere successo, e io non sarei più saggio. Semplicemente non ne ho idea. Logicamente non ne ho idea.

Cerca Heartbleed, l'enorme falla di sicurezza di OpenSSL. Heartbleed ha effettivamente nerfato SSL salvando prima le ultime centinaia o migliaia di transazioni (crittografate in rete) come testo normale e quindi lasciando una struttura facile e non registrata 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 normale. A quel punto OpenSSL proteggeva la stragrande maggioranza dei siti Web ospitati autonomamente e un numero enorme di banche e persino servizi di intelligence governativi.

Quindi cerca Meltdown e Spectre, enormi bug incorporati direttamente nelle moderne CPU Intel. Meltdown e Spectre neutralizzano 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 servizio in background di Windows XP (non sono nemmeno sicuro che fosse un bug, solo un eccezionalmente stupido) che non funzionava nemmeno per impostazione predefinita, sarebbe utilizzato attivamente solo da una vasta minoranza di utenti Windows e quindi conosciuto solo dai reparti IT. Questo ha finalmente spinto gli ISP a rilasciare firewall hardware integrati nei loro dispositivi modem e ha spinto Microsoft a incorporare un firewall software integrato nei loro sistemi operativi. Più o meno nello stesso periodo, si scoprì che una distribuzione della presunta piattaforma Linux "a prova di virus" conteneva un rootkit integrato nella versione principale della distribuzione.

Come altri hanno detto: devi fidarti di qualcuno in alcuni punto. Sia gli incidenti che la malizia causano problemi. Sono come te, grande fan di X-Files e Uplink (NON FIDARTI DI NESSUNO!) - ma la realtà è che il tuo motore di crittografia SSL o i tuoi dispositivi hardware fisici hanno la stessa probabilità di presentare falle di sicurezza e queste hanno molte più probabilità di rappresentare errori mission-critical quando si presentano.

Se sei seriamente intenzionato a fare quel qualcosa in più per reinventare la ruota Composer per la tua sicurezza e quella dei tuoi utenti, allora sii seriamente intenzionato a fare quel passo in più: progetta la tua CPU, scheda madre, RAM, HDD e unità ottiche. Scrivi il tuo sistema operativo e driver hardware. Crea anche i tuoi compilatori. E dimentica 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 sugli aggiornamenti di Composer / PHP / YourLinuxDistro e magari entra anche in alcune newsletter indipendenti basate sulla sicurezza e ottieni un abbonamento a Wired . Rivedi i log di sistema. Verifica periodicamente la tua rete con un PCAP per assicurarti che non ci siano flussi di rete non autorizzati in entrata o in uscita. Sii proattivo sul monitoraggio di possibili minacce e non paranoico su cose che non sono ancora accadute.

In qualità di sviluppatore di livello intermedio e avanzato, ho considerato lo stesso problema. Alcuni punti da considerare:

• Assegna priorità alla revisione del codice critico ai fini della sicurezza. Ovviamente ciò includerebbe cose come codice di accesso e autenticazione, convalida delle autorizzazioni, integrazioni del processore di pagamento . Tutto ciò che richiede informazioni sensibili o effettua chiamate di rete.
• Scorri visivamente cose come le librerie di stili: dovresti essere in grado di determinare rapidamente che stanno solo facendo stili e cose come le funzioni di utilità. Stringhe maiuscole, sostituzioni di spazi, riordino di array ... dovresti essere in grado di scorrere rapidamente il codice e vedere che non stanno facendo nulla di imprevisto.
• Anche se non decodifichi completamente il codice come se se fosse tuo, dovresti essere in grado di dare un'occhiata alla fonte e determinare se intendeva essere amichevole nei confronti del reverse engineering . Il codice dovrebbe essere documentato con commenti utili, i nomi delle variabili e dei metodi dovrebbero essere pertinenti e utili, le funzioni e le implementazioni non dovrebbero essere troppo lunghe o troppo complesse o contenere funzionalità non necessarie. Il codice molto gradevole alla vista non è certamente il vettore di attacco preferito dagli hacker malintenzionati.
• Verifica che il codice abbia una base di utenti consolidata e matura . Desideri gravitare su progetti che aziende famose e redditizie sono note per utilizzare.
• Conferma le identità del mondo reale dei collaboratori principali . Per progetti su larga scala, lo sviluppatore principale sarà lieto di prendersi il merito del proprio lavoro. Dovresti essere in grado di trovare post di blog, account di social media e probabilmente un curriculum o una pagina di marketing per lavori di consulenza. Contattami! ecc.
• Conferma che il codice open source sia mantenuto attivamente con le correzioni di bug recenti. Guarda le segnalazioni di bug in sospeso - ce ne saranno alcune - e non fidarti delle affermazioni secondo cui un particolare strumento o libreria è privo di bug. È un'affermazione delirante.
• Evita i siti "freeware" con troppi annunci. Evita i progetti che non dispongono di un sito demo disponibile o in cui la demo è "brutta", mal tenuta o spesso offline. Evita progetti eccessivamente pubblicizzati o parole d'ordine eccessive, fai affermazioni non testate di prestazioni superiori. Evita di scaricare da blog anonimi. Etc.
• Pensa in modo malizioso . Se volessi rompere il tuo sito, cosa proveresti? Se volessi introdurre codice non sicuro in una libreria ampiamente utilizzata, come lo faresti? (Ovviamente non provarlo.)
• Fork progetti open source o scarica backup. Non fidarti mai che il repository ufficiale del progetto open source che ti piace rimarrà online per un tempo indefinito.

Quindi, invece di tentare di leggere e comprendere individualmente ogni singola riga di codice, fatti un'idea di cosa fa ogni libreria e perché credi che lo faccia. Penso davvero che, se il tuo lavoro è redditizio, non ci sono limiti superiori a quanto può essere grande un progetto; puoi "esaminare" più di 1.200.000 righe di codice o più di 120.000.000 di righe di codice!

Composer può lavorare con un file composer.lock e, per impostazione predefinita, scarica i pacchetti tramite https://packagist.org/ (nota il S .) Quindi hai un enorme repository di pacchetti e un download sicuro con relativo checksum SHA1 per assicurarti di scaricare esattamente ciò che è stato specificato una volta. Questo da solo ti aiuta molto.

Se rimani sul lato conservatore degli aggiornamenti delle dipendenze, puoi anche aspettarti che le versioni del pacchetto abbiano visto un uso di 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 della comunità usati da migliaia e visti da ancora più utenti.

Alla fine, però, non credo che tu avere una scelta. Se altri "volano alla cieca", cioè senza gli audit di sicurezza che si desidera eseguire, e accettano i "tuoi" clienti con prezzi più bassi e versioni più veloci delle funzionalità, nessuno potrà mai trarre vantaggio dalla tua sicura applicazione autoprodotta.