Che cosa è meglio, una struttura consolidata o una soluzione homebrew?

Sicuramente vuoi che il tuo codice sia scritto dallo sviluppatore più abile possibile, ma non è abbastanza. Anche gli sviluppatori più competenti commettono errori (anche se quelli meno competenti tendono ovviamente a commettere più errori).

Per ottenere codice e algoritmi relativamente privi di errori, si desidera iniziare con il codice più pulito possibile, ma questa è solo metà del processo. Il modo migliore per eliminare i guasti è avere il maggior numero possibile di sviluppatori qualificati per sfogliare il codice alla ricerca di questi. Ciò vale per il codice tanto quanto per gli algoritmi. La tua soluzione deve essere ampiamente controllata dalle persone più esperte possibili.

Il punto in cui inizi, il livello di abilità dello sviluppatore originale, è solo il punto di partenza. Dopo una revisione sufficiente, non importa quanto abile sia stato lo sviluppatore originale.

Quindi, ecco la chiave: il valore di sicurezza in qualsiasi codice è in quanto è ben curato . Che sia stato scritto da te, da un noto crittografo, da una grande società o da nessuno in particolare, tutto quello che conta è quanti occhi esperti hanno esaminato il codice.

Una tale regola tende a favorire quadri consolidati su soluzioni homespun. Ma stabilito non è necessariamente lo stesso di vetted , che è parte del motivo per cui molti esperti di sicurezza tendono a favorire soluzioni open source: è difficile per un open progetto sorgente per diventare popolare senza che sia sottoposto a una certa quantità di scrutinio.

Per un framework homebrew, un programmatore competente non è sufficiente. Avete bisogno di un programmatore competente che abbia tempo da dedicare sia all'implementazione sia alla successiva manutenzione, e chi lo farà ancora tra dieci anni. Questo può essere fatto, ma non proprio in un contesto universitario in cui gli studenti vanno e vengono.

Se ti attieni a una struttura consolidata, beneficerai degli aggiornamenti di sicurezza e del lavoro generale del team di manutenzione del framework, che semplificherà il tuo compito.

L'unico punto da ricordare è che un framework homebrew non , da solo, fornisce sicurezza; dà solo un sentimento di sicurezza. Il ragionamento di solito segue le linee di: "dato che abbiamo un framework homebrew, non soffriamo dei bug noti e dei punti deboli di un framework stabilito, e l'hacker non indovinerà mai dove sono i nostri bug". Questo ragionamento è imperfetto: l'hacker conosce già il tuo codice, forse meglio di te. Soprattutto in un'università, che ospita, per definizione, un sacco di persone tecnologicamente esperte con uno spirito d'animo avventuroso, una morale flessibile e, di regola, molto più tempo libero e potenza di calcolo disponibile che può essere considerato sano.

Quindi dovresti usare una struttura consolidata.

Hai due dubbi:

1. "Drive-by hacker" che elimina i tuoi dati, blocca il funzionamento del tuo server web sfruttando contemporaneamente migliaia di siti web.
2. "Targeting di hacker" che desiderano accedere al tuo server web in modo specifico per "guadagni più elevati", qualunque cosa possa essere.

Per prima cosa non è un problema finché si dispone di solidi piani di backup, aggiornamento e ripristino. Verrà battuto il costo di scrivere un framework a meno che non venga hackerato a giorni alterni.

Il secondo non avrà importanza anche se NON utilizzi un framework. Perché se l'incentivo è abbastanza alto, qualsiasi cosa vada, incluso il social hacking, l'acquisto di exploit zero-day dal mercato nero ecc. Quello che devi fare è abbassare l'incentivo. Isolare dati preziosi dal server web e le debolezze del tuo framework non sono più importanti.

Il singolo problema più grande con un framework homebrew: troppi pochi esperti nel codebase.

Scrivere il proprio framework è divertente (beh, è per il tipo di coder che gode di quel genere di cose), ma a meno che la proprietà del codice non sia condivisa ampiamente, è un percorso pericoloso da intraprendere.

Ho lavorato in diversi posti in cui avevano scritto le proprie librerie di framework. in genere, il framework stesso è stato scritto quasi interamente da uno o due sviluppatori. I capi sono convinti che il codice quadro fosse un bene prezioso e gli sviluppatori principali che conoscono il codice al di fuori sono praticamente insostituibili.

Il problema è che in tutti i casi che ho visto, il codice è pieno di bug, buchi di sicurezza e scarsa pratica. Quando lo sviluppatore principale alla fine lascia, i suoi successori sono lasciati a raccogliere i pezzi. A volte combattono solo con il codice esistente; a volte intraprendono un progetto di reingegnerizzazione su larga scala; a volte passano a un framework di terze parti.

L'altro problema che si verifica in genere è che la tecnologia e le esigenze degli utenti si spostano. Se hai scritto il tuo framework, devi continuare a lavorarci costantemente per tenerlo aggiornato. Questo va bene se il framework è il tuo progetto principale, ma se è solo il tuo codice back-end, mangerà il tuo tempo che sarebbe meglio spendere per lavorare sul tuo progetto attuale.

Infine, sicurezza. Questo è il grande, davvero. Molti, molti sviluppatori competenti hanno scritto codice che è insicuro. In effetti, se siamo onesti, lo abbiamo tutti. Java non è stato scritto da incompetenti, eppure Oracle ha dovuto rilasciare una patch per cinquanta buche di sicurezza questa settimana. Ogni altro software che potresti nominare ha anche dei buchi, e probabilmente ha ancora dei buchi. Scrivendo il tuo framework, non categoricamente stai scrivendo qualcosa di più sicuro di qualsiasi ben noto framework di terze parti. In realtà è probabile che sia significativamente peggio e non avrai le risorse per andare alla ricerca di bug di sicurezza. Avrai la "sicurezza per oscurità" perché nessuno avrà visto il tuo codice, ma devi solo usare quella frase per vedere cosa ne pensa il mondo della sicurezza.

Quindi, in sintesi, direi No; una struttura casalinga non è una buona idea.

Vai avanti e scrivine uno comunque - è un ottimo esercizio di apprendimento - ma non aspettarti che sia buono come le strutture già esistenti. Se fosse così facile, non ci sarebbe alcuna necessità per le librerie esistenti.

Come delineato da altri, il framework supportato, controllato e mantenuto sarà quasi sempre migliore di una soluzione "homebrew". Ciò è particolarmente vero nel contesto universitario in cui il lavoro viene spesso svolto inizialmente come progetto e poi si trascina con finanziamenti e sostegno insufficienti per gli anni successivi. A patto che vengano applicati i pachetti di sicurezza, è possibile almeno mantenere un certo livello di sicurezza. Lo stesso non si può dire per un sistema homebrew. Dato che la sicurezza è una festa in evoluzione e commovente, è necessario.

L'unico avvertimento che vorrei sui framework stabiliti è quello di assicurarti di scegliere la struttura giusta per l'attività. Alcuni framework sono enormi, estremamente complessi e richiedono conoscenze specializzate ed esperienza per l'uso corretto. Un framework sicuro e ben progettato non sarà di alcun beneficio se implementato o utilizzato da sviluppatori inesperti. Oltre a considerare gli aspetti di sicurezza del tuo framework, considera anche i set di abilità dei tuoi sviluppatori e cerca un framework che offra solo le funzionalità che desideri e non molte funzionalità aggiuntive che non ti servono e probabilmente non verranno configurate correttamente .