Dici di non avere scelta, ma non è vero. Potresti scrivere tutto il codice di cui hai bisogno. Oppure potresti pagare un professionista di fiducia per scrivere il codice per te. Oppure potresti pagare una società di sicurezza per controllare il codice prima di usarlo. Oppure potresti accettare il rischio e implementare altri controlli di sicurezza per mitigare i rischi. Ad esempio, se temi che del codice possa essere vulnerabile a SQL injection, potresti impostare un WAF (Web Application Firewall) di fronte ad esso.

La sicurezza ha un costo: tempo, risorse, esperienza, denaro. Non c'è pranzo gratis. Se non puoi permettertelo, dovresti evitare il problema (ripensare il tuo progetto), o delegarlo (qualcun altro se ne occuperà), o mitigarlo (ad esempio con una difesa in profondità) o semplicemente accettare il rischio che tu possa essere hackerato.

Personalmente, nel tuo caso, quando hai a che fare con codice poco utilizzato, se la libreria non è troppo grande proverei a leggere il codice Almeno per controllare se c'è qualche "odore di codice". Anche se non controlli tutta la logica, è facile controllare se ci sono abbastanza commenti, se hanno senso, se il codice è pulito e comprensibile, se certe funzioni vengono utilizzate secondo le migliori pratiche, se ci sono controlli sul dati di input, ecc. Il rischio che il codice venga utilizzato solo da poche persone e mantenuto da pochi sviluppatori è anche che potrebbe smettere di essere mantenuto, o la manutenzione risulta essere comunque troppo lenta, quindi alla fine della giornata potresti essere costretto a leggere e capire comunque il codice, per aggiustare la tua applicazione. Quindi, se possibile, proverei anche a implementare qualcosa per la difesa in profondità, anche se configurare correttamente un WAF potrebbe non essere facile, se vuoi davvero che sia efficace e allo stesso tempo evita di interrompere la tua applicazione a causa di falsi positivi.

Affronterò prima la parte generica della tua domanda, quindi la parte PHP specifica.

1. Non fidarti delle librerie PHP oscure che nessuno usa!

   È solo la solita domanda guadagno / rischio. Se il rischio è basso, puoi fare qualsiasi cosa e utilizzare librerie oscure (o addirittura danneggiate). Ciò significa che né la piattaforma né il risultato dell'applicazione finale sono mission critical. Se in un momento non riesce, sarà sufficiente produrre una correzione o trovare una soluzione alternativa.

   Se si desidera includere la libreria in un'applicazione a valore aggiunto, è necessaria una valutazione del rischio che la libreria non si comporta esattamente come previsto. Il modo più comune è (come in Stack Exchange) la reputazione . Se si sa che la libreria è stata ampiamente testata ed è ancora mantenuta, il rischio di cadere in un caso d'angolo non testato è basso e si può sperare che se si nota un problema verrà risolto. Se viene mantenuto solo occasionalmente e ha pochi utenti, tu (o i tuoi utenti) potreste cadere in un secondo momento in un caso così angosciante e non avere modo migliore di documentare che la tua applicazione non può farlo.

   Se la reputazione non è ben consolidata, potresti provare a scavare un po 'nel codice. Se sembra ben strutturato, ben documentato e contiene test, puoi almeno fidarti che le regole delle migliori pratiche sono state osservate. Come punto a margine, i test mostreranno su quale caso d'uso si concentra la libreria.

   Se la libreria sembra davvero una libreria oscura e vuoi usarla, avrai per testare non solo il tuo codice, ma anche verificare che la libreria si comporti come ti aspetti per tutti i casi d'uso che intendi accettare dalla tua applicazione. Perché non puoi fidarti ciecamente. Ma se lo fai sul serio, ci vorrà tempo.

2. PHP e linguaggi meno utilizzati

   PHP è probabilmente il linguaggio più utilizzato dai programmatori non professionisti. Ciò significa che se hai bisogno di qualcosa, qualcun altro l'ha già prodotto. Ma non puoi essere sicuro della qualità. Java è molto meno utilizzato al di fuori dei prodotti di livello professionale. Ma molte biblioteche sono prodotte da organizzazioni grandi e ben note e pesantemente testate. Quando ricevo qualcosa dai progetti Spring, confido che abbia seguito le regole delle migliori pratiche e sia stato ampiamente testato.

   Solo la mia opinione, ma è uno dei motivi per cui sono riluttante a usare il codice PHP: lì c'è un sacco di codice PHP in giro, alcuni dei quali di ottima qualità, ma il rischio di ottenere un pezzo di codice di scarsa qualità è alto.

Il consiglio è fondamentalmente una mappatura dei principi di fiducia che si hanno nel mondo "reale" nel mondo dello sviluppo del software:

• Non fidarti ciecamente di qualcuno ma controlla la reputazione. È meglio fidarsi di qualcuno che già da tempo si fida anche di molti altri perché in questo caso è meno probabile che la fiducia venga abusata. Per lo sviluppo del software questo significa usare librerie che sono usate anche da altri e hanno una buona reputazione.
• E se hai a che fare con qualcuno che non ha una reputazione consolidata, stai molto attento. In caso di sviluppo di software questo significa verificare che il codice stia effettivamente facendo quello che dovrebbe fare e niente di più (cioè niente backdoor, niente bug critici).

Se non segui queste semplici regole del mondo reale nello sviluppo del software puoi bruciarti nello stesso modo in cui potresti essere bruciato nella vita reale: qualcuno potrebbe abusare della fiducia (infondata) che hai che potrebbe ad esempio provocare una backdoor o un bug critico nel software. E questo a sua volta potrebbe danneggiare anche la tua reputazione.

Certo, è ancora possibile che qualcuno abbia una buona reputazione e continui ad abusare della fiducia. E ci sono abbastanza esempi in cui ciò viene fatto. Ma è molto meno probabile rispetto a qualcuno senza reputazione poiché ci vogliono molti sforzi per costruire una buona reputazione in primo luogo. Rispetto a ciò, una buona reputazione può essere facilmente e rapidamente persa se utilizzata in modo improprio, quindi la maggior parte non cercherà di abusare della propria buona reputazione.

Non devi utilizzare PHP per il tuo sito web

Ci sono alternative migliori. Consulta ocsigen progettato da scienziati informatici che comprendono qualcosa sulla sicurezza informatica e in haxe. Ovviamente passerai mesi per impararlo e se scegli di usare ocsigen corri dei rischi commerciali (le persone e le aziende che lo mantengono potrebbero scomparire, il cosiddetto fattore bus). Ma conosco personalmente l'architetto e designer principale di Ocsigen e posso assicurarti che capisce un bel po 'di sicurezza informatica (metà della sua tesi di dottorato è su questo argomento).

Devo entrambi usalo o niente.

No, è sbagliato. Non devi usare PHP. Ad esempio, leggi questo blog sulla creazione del tuo sito web in C ++ e quello sulle tecnologie web in Common Lisp. Potresti utilizzare altri approcci (ad es. Server FastCGI scritti in C ++ o in Go, il tuo server HTTP specializzato scritto in C ++ ad es. Con libonion o con pistache o con CppCMS o Wt, in Go, in Common Lisp con SBCL). Con Rocket.rs puoi scrivere applicazioni web in Rust (e la comunità di Rust si interessa molto alla sicurezza informatica). Puoi programmare server web dinamici in SML. E molti server web ( Apache, Lighttpd, ...) possono essere personalizzati o adattati alle tue esigenze (ad es. Con i tuoi plugin scritti da te per loro) senza un solo bit di cose relative a PHP.

La mia opinione parziale è che i framework web al di sopra di Common Lisp o C ++ o Go o Rust siano solitamente progettati da informatici qualificati che per professione comprendono e si preoccupano della sicurezza informatica. PHP è stato progettato con una mentalità completamente diversa: essere in grado di codificare rapidamente siti Web dinamici. Al momento in cui è stato progettato PHP (1995), la sicurezza informatica non era una delle principali preoccupazioni, ma essere in grado di creare un sito Web dinamico dall'aspetto gradevole in pochi giorni era in pratica essenziale.

Ma qualunque cosa tu stia usando, ha un certo costo. Informazioni sulle esternalità. Leggi il lavoro accademico di J.Tirole su di essi (è un premio Nobel per l'economia; vale la pena leggere il suo articolo sulla semplice economia dell'open source e il più citato quell'argomento). Anche se è software libero (dal momento che il software libero riguarda la libertà, non il budget). Almeno non dimenticare il costo dei tuoi sforzi per apprenderlo e valutare i suoi aspetti di sicurezza informatica.

Se utilizzi librerie open source, hanno ancora un costo per te: bisogno di impararli, per valutarli. Di solito vengono forniti SENZA GARANZIA . Ma puoi acquistare il supporto per queste librerie.

Se utilizzi librerie proprietarie o componenti software, sei vincolato dal loro EULA.

La sicurezza è sempre un questione di compromessi.

Non puoi allacciare la cintura di sicurezza durante la guida, ma poi corri un rischio aggiuntivo e paghi per quello (ad esempio perché la tua assicurazione non ti coprirà se qualcosa va sbagliato, o perché ti prendi qualche multa). È lo stesso per le scelte del software.

Sii comunque consapevole del teorema di Rice. In un certo senso, dice che la piena sicurezza informatica è impossibile. Ma anche vivere è un'attività rischiosa. (Tu o io potremmo avere un attacco di cuore in poche ore).

Il tuo problema non è tecnico, ma sociale. Se utilizzi software open source, hai la possibilità di studiare ogni riga del codice sorgente ed essere convinto (o meno) che la sicurezza sia sufficientemente buona. Naturalmente, ciò potrebbe richiedere decenni (o secoli: un'intera distribuzione Linux è ora 20 miliardi di righe di codice sorgente). Ma la scelta è tua (e puoi delegare la valutazione della sicurezza di ogni componente software che stai utilizzando).

Penso che tu stia già seguendo il consiglio! Dici:

Non conto quelli obsoleti, abbandonati, spazzatura.

Quindi, quale misura usi per decidere se qualcosa è "obsoleto , abbandonato, spazzatura "? Pochissimi pacchetti sono effettivamente contrassegnati come "abbandonati" su siti come packagist.org e "spazzatura" è chiaramente un giudizio soggettivo, quindi sospetto che il tuo processo effettivo sia qualcosa del genere:

1. Cerca pacchetti dall'aspetto pertinente
2. Verifica se sono adatti al tuo caso d'uso
3. Verifica che siano di qualità ragionevole

Il fatto che spesso finisci con un'unica opzione alla fine di questo processo è molto diverso dal fatto che ci sia solo un'opzione all ' inizio di questo processo.

È anche Vale la pena notare che se esiste una libreria di alta qualità per risolvere un particolare lavoro, spesso non c'è alcun incentivo per qualcuno a scriverne una nuova. Ancora una volta, questo non vanifica il consiglio di utilizzare librerie rispettate, ma lo rafforza: se ci sono molte persone che usano la stessa implementazione, è più probabile che alcune di loro individuino difetti o paghino per gli audit. Questa è fondamentalmente una reiterazione della "Legge di Linus":

visti abbastanza bulbi oculari, tutti i bug sono superficiali

L'unico caso in cui posso vedere il problema effettivamente fare domanda è dove non ci sono non librerie decenti per un lavoro, perché è un caso d'uso sufficientemente raro che nessuno ne abbia scritta una. In quella situazione, sta a te scrivere la libreria (o pagare per la sua scrittura) e sta a te renderla sicura (o pagare qualcuno che controlli che sia sicura).