Creazione del codice di database open source

Questa è una buona domanda con una risposta semplice:

Best practices cannot be applied in every situation.

Le migliori pratiche di "non dire al mondo quali algoritmi di sicurezza utilizzi" e anche "non esporre la tua struttura DB" esistono come possibili ripiegamenti, solo nel caso in cui il tuo codice abbia un difetto di sicurezza in esso, è molto più difficile per qualcuno sfruttarlo se non sanno come funziona dietro le quinte. Ovviamente entrambe queste buone pratiche sono in conflitto diretto con l'Open Source, quindi dovresti concentrarti solo sul non avere falle di sicurezza in primo luogo. Fortunatamente, l'apertura del codice sorgente ti sarà d'aiuto.

Affidarsi a mantenere segreto lo schema per proteggere il sistema non è un buon punto di partenza. Non è il principio di Kerchoff, ma se la sicurezza del tuo sistema si basa sull'oscurità dello schema, allora anche se lo tieni chiuso e non lo offri a nessun altro, hai dei problemi.

the script with the connection username/password should not be hosted on the source repository

No.

Certamente non vuoi mettere le tue credenziali del database in un repository pubblico, ma dovresti inserire il codice per gestirle e applicarle nel rapporto. È possibile utilizzare i valori fittizi nel repository, leggerli da un file flat o dall'env, utilizzare i valori predefiniti in PHP.ini, utilizzare le credenziali fornite dall'utente memorizzate nella sessione, limitare l'accesso a localhost 'e non richiedere una password ... . Ci sono potenzialmente molte soluzioni.

However I am unsure how to proceed as I have also heard that you do not want to expose your database structure to others.

Non vuoi esporli perché se esiste SQL injection sanno quali sono le tabelle da indirizzare. Tuttavia, se SQL iniettato esiste per fare in modo che ciò accada, è una protezione controventata poiché la sicurezza è già stata interrotta. Soprattutto dal momento che molte applicazioni PHP / SQL in natura raramente impostano le autorizzazioni utente SQL appropriate. Quindi la maggior parte delle volte l'attaccante può fare una discarica della tua struttura e non ha bisogno di indovinarlo.

The only thing I'm sure of is that the script with the connection username/password should not be hosted on the source repository of my choice.

Un sacco di progetti aggirano questo problema fornendo una configurazione di esempio e quindi attraverso il loro software di controllo delle versioni crea una regola che impedisce che la loro configurazione venga trasferita al repository di controllo della versione. Un esempio di questo è che possono avere un esempio di configurazione chiamato config-EXAMPLE.php e il loro script di installazione rinomina questo in config.php (o crea da zero) non appena le informazioni per esso sono disponibili. E se usano Github, ad esempio, includi una regola .gitignore per bloccare config.php che assicurerà che non indossino esporre accidentalmente la propria configurazione.

It is currently not open source, but I am considering making it open source, so that others can fix bugs, improve it...

Non dimenticare la sicurezza quando fai questa affermazione. La cosa migliore dell'open source sono gli altri in grado di individuare ciò che non si è e correggere o migliorare su di esso. E questo include sicurezza. Apri il tuo progetto di sourcing potrebbe potenzialmente risolvere più problemi di sicurezza di quelli che espone.