Protezione di DB e dati di sessione su un host condiviso PHP

Question

Ho scritto un'applicazione Web PHP utilizzando SQLite e sessioni archiviate su filesystem.

Questa operazione è funzionale e richiede una manutenzione minima. Ma ora deve essere eseguito su un host condiviso.

Tutte le applicazioni web in fuga host condiviso lo stesso account utente, quindi i dati della sessione miei utenti è vulnerabile, come è il database, codice, ecc

Molti consiglia di conservare le sessioni in DBMS come ad esempio MySQL in questa situazione. Quindi all'inizio pensavo che lo avrei fatto e sposterei anche i dati SQLite in MySQL. Ma poi mi sono reso conto che le credenziali MySQL devono essere leggibili dall'utente dell'applicazione Web, quindi sono tornato al punto di partenza.

Penso che la soluzione migliore sia utilizzare PHP come CGI in modo che venga eseguito come utente diverso per ogni applicazione Web. Questo suona bene, ma il mio ospite non lo fa utilizza mod_php. Ci sono degli svantaggi dal punto di vista di un amministratore per abilitare questo? (prestazioni, retrocompatibilità, ecc.)? Altrimenti, chiederò loro di abilitarlo.

Altrimenti, c'è qualcosa che posso fare per proteggere il mio database e i dati di sessione in questa situazione?

Answer 1

Fintanto che il codice è in esecuzione come utente Web condiviso, qualsiasi elemento memorizzato sul server sarà vulnerabile. Qualsiasi altro utente può scrivere uno script PHP per esaminare qualsiasi file leggibile sul server, inclusi i dati e il codice PHP.

Se il vostro provider di hosting lo permetterà, in esecuzione come PHP come CGI sotto un altro utente vi aiuterà, ma mi aspetto ci sarà un significativo calo di prestazioni, come ogni richiesta sarà necessario un nuovo processo da creare. (Si potrebbe guardare a FCGI come un'alternativa migliore.)

L'altro approccio sarebbe impostare un cookie basato su qualcosa che l'utente fornisce e utilizzarlo per crittografare i dati di sessione. Ad esempio, quando l'utente effettua il login, prende un hash del proprio nome utente, password (come appena fornita da loro) e l'ora corrente, cripta i dati della sessione con l'hash, imposta un cookie contenente l'hash. Alla richiesta successiva, recupererai il cookie, che potrai quindi utilizzare per decrittografare i dati della sessione. Si noti tuttavia che questo proteggerà solo i dati della sessione corrente; la tua tabella utente, altri dati e codice saranno comunque vulnerabili.

In questa situazione, è necessario decidere se il compromesso del basso costo dell'hosting condiviso è accettabile considerando la ridotta sicurezza fornita. Questo dipenderà dalla tua applicazione, e potrebbe essere che invece di cercare di creare un modo complesso (e forse nemmeno molto efficace) per aggiungere sicurezza, è meglio accettare il rischio.

Answer 2

Non vedo la sicurezza come tutto o niente. Ci sono dei passi che puoi compiere. Dare all'utente web db solo le autorizzazioni necessarie. Memorizza le password come hash. Utilizza il login openid in modo che gli utenti forniscano le loro credenziali su SSL.

PHP su cgi può essere più lento e alcuni host potrebbero semplicemente non voler supportare più di un ambiente.

Potrebbe essere necessario rimanere con l'host per qualche motivo, ma in genere ci sono così tanti disponibili che è un buon promemoria per le persone a confrontare funzionalità e sicurezza, nonché i costi. Ho notato che molte aziende stanno iniziando a offrire hosting di macchine virtuali - quasi a livello di sicurezza a livello di server in termini di isolamento del codice da parte di altri utenti - a un costo ragionevole.

Answer 3

Un host condiviso non è un modo per eseguire un sito Web se si è consapevoli della privacy e della sicurezza dei dati dai siti con cui si condivide il server. Tutto ciò che è accessibile alla tua applicazione web è un gioco leale per gli altri; sarà solo questione di tempo prima che possano accedervi (supponendo che abbiano un incentivo a farlo per voi).

Answer 4

"è possibile inserire le variabili di connessione DB in un file sotto la radice Web. Questo almeno lo proteggerà dall'accesso Web. Se si intende utilizzare anche sessioni basate su file, è possibile impostare il percorso della sessione in la directory dell'utente e nuovamente all'esterno della web root. "

Non ho un account quindi non posso effettuare il downvote ... ma seriamente non è nemmeno pertinente alla domanda.

Duh si memorizzano le cose al di fuori del webroot. Questo vale per qualsiasi scenario di hosting e non è specifico per l'hosting condiviso. Non stiamo parlando di proteggere dagli estranei qui. Stiamo parlando di protezione da altre applicazioni sulla stessa macchina.

Per l'OP penso che PHP come CGI sia la soluzione più sicura, come hai già suggerito tu stesso. Ma come ha detto qualcun altro, c'è un successo in questo.

Qualcosa che potresti guardare è spostare le tue sessioni e db su MySQL e usare safe_mode e/o open_basedir.

Answer 5

Vorrei risolvere il problema con un cambiamento di infrasturtura anziché uno di codice. Considerare l'aggiornamento a un server VPS. Oggigiorno è possibile ottenere loro molto economici. Ho visto i VPS a partire da @ 10 $/mese.