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

1

Ho un database Mysql con un'API ad esso legata per chiamare ed eseguire il codice PHP memorizzato in quel database. Sì, hai sentito bene, codice PHP memorizzato ed eseguito da un database Mysql. Quindi, questo è abbastanza serio dal punto di vista della sicurezza, e questo è il mio dilemma. Il tuo primo suggerimento potrebbe anche essere: "NO, cattivo!". Non temere, può essere fatto. Ci sono alcuni buoni motivi per farlo.

  1. Aumento della velocità di 40 volte (nessuna lettura HD)
  2. Iniezione delle dipendenze automatiche.
  3. Altri linguaggi di programmazione.

Sicurezza.

I risanamenti in ingresso "sembrano" essere la cosa più importante qui, e il mio filtro è di prim'ordine. SQL Injection sarebbe il tuo peggior incubo.

La mia domanda è questa: quando si esegue il codice live da un database, può essere difeso, può essere attaccato? Quali vettori di attacco potrebbero essere possibili? E come hai potuto difendere?

In sintesi, ho bisogno di una consulenza di esperti, Worst-Case, Best-Case, Fallo, non farlo. Sei pazzo, qualcosa.

UPDATE1: leggerò tutti i commenti più e più volte, The Truth Matters.

  1. Sto usando un cluster di percona mysql, si sta verificando una velocità misurabile (memorizzata nella ram)
  2. Il versioning è facile (e integrato) Hai un tavolo con L (lingua) FunctionName Vars Deps RequiredVars VERSION # etc ... ecc.
  3. Vorrei aggiungere per il livello di interesse, che Un'applicazione potrebbe essere basata principalmente su interi, nel qual caso l'input può essere disinfettato mediante il casting su (int) (IE. $ num = (int) $ _ GET ['s'];)
  4. Accolgo con favore idee, suggerimenti e argomenti. Credo che questo ostacoli molte barriere mentre ne raggiungiamo di nuove e ora sono completamente disposto e pre-dedicato a capirlo, quella parte è un affare fatto; O, l'umanità! Ma credo che questo possa avere successo.
  5. Un altro vantaggio aggiunto è la neutralità della lingua, dal momento che memorizzo il mio codice in un database, etichettando un codice come PHP e uno come RUBY o PYTHON, ha seri usi. Nulla di un po 'di azione php-shellexec può rivelarsi bello (anche in questo caso, per quanto riguarda l'igienizzazione degli input quasi perfetta)

Continuerò ad aggiornare (ho un programma fitto di impegni, ma sarò il più attento possibile.)

    
posta iGNEOS 27.12.2016 - 16:44
fonte

3 risposte

5

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.

    
risposta data 27.12.2016 - 17:13
fonte
2

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).
risposta data 28.12.2016 - 00:31
fonte
1

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.

risposta data 27.12.2016 - 18:34
fonte

Leggi altre domande sui tag