Come eseguire in modo sicuro PHP da un database Mysql [chiuso]

Pensieri generali

Questa sembra una pessima idea per la produzione. Se vuoi solo provare qualcosa, questa è un'altra questione.

Anche io non vedo come sia un vantaggio. Per quanto riguarda i tuoi punti:

1. Dove si trova il tuo db? Perché dovresti dare per scontato che non richiede la lettura dell'HD? E se pensi che i risultati del db siano archiviati in ram, perché non il codice php dai file? E hai davvero profilato questo? Per una grande scala? Assumerei una grande riduzione della velocità (e questo non è nemmeno considerando le cose come non essere in grado di usare le cache PHP).
2. Davvero? Come? E non potresti semplicemente usare una libreria per questo?
3. Cosa? Non penso che ciò valga veramente come lingua neutrale

Devi anche considerare che il debugging sarà piuttosto difficile, che è probabilmente il più grande svantaggio. Sviluppare e implementare un nuovo codice sarà probabilmente anche più difficile.

Minacce

Le cose di cui devi preoccuparti con il tuo approccio:

• Essere in grado di scrivere nel database del codice porterà all'esecuzione del codice. Le scritture possono essere eseguite tramite iniezione, o leggendo o aggiungendo bruteforcing alla password del database (se un utente malintenzionato è in grado di connettersi al database).
• Essere in grado di eseguire l'iniezione nelle query del database di codice SELECT porterà all'esecuzione del codice.

Mitigations

Comunque, se vuoi ancora farlo (suggerimento: non farlo), ci sono un paio di cose che puoi fare per renderlo un po 'più sicuro:

• Archivia il tuo codice PHP in un database separato, accessibile con un altro utente. L'utente che recupera i dati normali dal database non dovrebbe avere accesso a questo database.
• Non consentire l'accesso remoto al database del codice e ovviamente utilizzare una password sicura. Non usare cose come phpmyadmin, che in effetti consentirebbero l'accesso remoto al database.
• Non inserire l'input dell'utente nelle query in esecuzione sul database del codice.
• Idealmente non eseguire query su questo database ovunque. Probabilmente hai solo bisogno di una o due funzioni che selezionano il codice che desideri. Utilizza dichiarazioni preparate per questi.
• Pensa solo a dare al database del codice l'accesso in lettura al database del codice (se questo ha senso nel contesto dell'applicazione).

Inoltre, la difesa corretta contro l'iniezione SQL non è l'input di misure igieniche o di filtraggio (non sarà sbagliato), ma dichiarazioni preparate. L'input cast di Ints è grande come difesa in profondità, ma in pratica è miserabile come unica difesa. Ho visto molte applicazioni che adottano questo approccio (oltre a ecaping / filtering per non-int), e non va mai bene.

_{Supponevo che tu memorizzassi il codice PHP nel db e lo eseguissi con eval, ma la maggior parte dei punti probabilmente si applicherebbe anche ad altri approcci.}

40x speed increase (no HD reads)

OMG, NO.

SehaiunaconfigurazioneincuiilcodicelettodalDBvieneeseguito40voltepiùvelocementedelcodicelettodaifile,quellaconfigurazioneèfondamentalmenterotta.Ilfattochetunonlosappiagiàmifapensarechenonseineanchelontanamenteprontoaprovarequalcosaditantoesotericocomequellochedescrivi.

AmenochetunonabbiariscrittoilcaricatorePHPolasuainterfaccianellacachedell'opcode,quindieseguirail'analisielacompilazione(el'ottimizzazionesesistautilizzandoZendopcache)ognivoltacherecuperiilcodicedaldatabase.Sequestoèinesecuzionepiùvelocedellaletturadeifiledalfilesystem,nonhaicacheopcode,èverymalconfigurato,haialcuniproblemiorrendiconiltuofilesystemolacacheVFS.Qualcosaèmolto,moltosbagliato.

AutomaticDependencyInjection

No.Nonèpossibileperilsistemasaperemagicamentecomesipresentaladipendenzadelcodice.Èpossibiledefinireunframeworkchestiaeffettivamentecopiandoquesto-maquestoèanchepossibilesenzadovermantenereilPHPinundatabase.

OtherProgrammingLanguages.

Eriguardoaloro?Lamaggiorpartedeilinguaggidiprogrammazioneconsentedicrearecostrutticheinvocanoilcodicescrittoinaltrelingue.SiaPHPcheMySQLpossonochiamarelibreriecondivisechesonostatescritteinunmodochepuòessereinvocatodallostessothread/processo.Maquestoèdavverorobadascienzamissilisticaemoltopericolososenonsaicosastaifacendo(èpiuttostopericolosoquandosaicosastaifacendo).IlPHPd'altrapartevienefornitoconmolteestensionibenscritteperlamanipolazionedeidati(crittografia,gestionedelleimmagini,funzionidirete...).MoltopiùdiMySQL.Vienefornitoancheconilsupportoperinvocarealtriprocessiconcomunicazioniuni-obidirezionali.

Inputsanitationwould"seem" to be the most important thing here, and my filter is top notch

Dovresti convalidare input e sanitizzare output. Ti darò il beneficio del dubbio qui e supponi che intendi l'input per il sistema nel suo complesso e non solo un livello. Tuttavia (se le tue giustificazioni fossero valide) farei molte urla a chiunque lavori per me che memorizza il codice eseguibile accessibile / modificabile dallo stesso account che accede / modifica i dati nel database. Anche allora questo comporta enormi rischi di iniezione / modifica del codice.

mostly integer based

= non solo intero basato. Spero che tu stia usando un metodo migliore in cui l'input potrebbe essere qualcosa di diverso da un intero.

Le uniche ragioni che posso giustificare in remoto per il tentativo di una tale architettura sono:

• dove fornisci una funzione (molto pesantemente in modalità sandbox) per eseguire il codice inviato dall'utente in
• in cui si desidera fornire un meccanismo per la gestione delle modifiche in una server farm di grandi dimensioni (ma anche in questo caso prenderei in considerazione l'architettura come inefficiente, pericolosa e inefficace pur essendo ottenibile utilizzando il codice memorizzato nei file).

Non vedo i tuoi vantaggi menzionati validi e ne conseguono il costo, in quanto sono presenti alcune minacce e aspetti negativi che dovresti prestare attenzione a:

1. Con l'aumentare del DB, la tua velocità di recupero è più lenta e più lenta che influirà sull'intera performance del sito web, specialmente quando avrai il recupero annidato: come il tuo codice nel DB accedere nuovamente al DB per altri dati!.

2. Molto difficile da mantenere il tuo codice:

   • L'editing è costoso: per modificare un carattere nel codice, devi aggiornare l'intero testo del codice tramite il comando SQL.
   • Il test è costoso: per ogni modifica o errore, devi aggiornare l'intero testo tramite il comando SQL.
   • Il debug è impossibile.
   • Nessun supporto dal controllo del controllo delle versioni di origine (SVN, GIT, CVS..etc).

3. Nessun controllo delle autorizzazioni , quindi è necessario disporre di più controlli di accesso e autorizzazione a livello di DB, che è più costoso e più difficile da implementare.

4. Problema di disponibilità se il DB non è disponibile.

5. Se hai una perdita di DB, allora avrai perdita di codice che potrebbe rivelare ulteriori informazioni e porte nella tua infrastruttura.

6. Attacchi di code injection saranno più semplici e avranno un impatto maggiore ... immagina di caricare una shell solo tramite SQL injection.

7. Nessun controllo o ultima modifica per verificare se un codice è stato modificato a tua insaputa.