Scrittura di file in una sottocartella della cartella Web (sicurezza apache)

Question

Scrittura di file in una sottocartella della cartella Web (sicurezza apache)

#1 da (4 voti)
#2 da (2 voti)

2

Ho bisogno di salvare i dati di sessione per uno script dinamico di una pagina Web scrivendo su file. Ho due domande:

Ci sono delle preferenze di sicurezza riguardo al salvataggio dei dati UNDER della cartella web o OUTSIDE della cartella web?
Ho tentato di scrivere nella cartella un (senza preavviso), ho avuto un errore di tipo "permessi file rifiutati". Devo impostare la proprietà della cartella all'utente di apache (600, 640 o 644?)

[[Edit]]

core     <- 'OUTSIDE' web folder (php script live here)
data     <- 'OUTSIDE' web folder (session data and other misc data resides here)
web      <-  web root folder
   js    <-  any folder below is 'INSIDE' the web folder
   css
   html

Ad esempio, in uno script php (cioè una pagina PHP dinamica), posso provare a scrivere su un file usando qualcosa come fput('../data',data) ancora (a quanto ho capito) ../ data non dovrebbe essere accessibile - per motivi di sicurezza.

Qualcuno potrebbe fornire un semplice esempio che mostra come fornire l'accesso a ../ data / nell'esempio sopra riportato ?.

Quali sono i passaggi SPECIFICHE effettivi richiesti?

BTW, sto correndo su uno stack LAMP.

apache

posta Homunculus Reticulli 30.03.2012 - 02:33

fonte

2 risposte

Leggi altre domande sui tag apache

Come posso proteggere il contenuto distribuito su una macchina virtuale Linux? Un sistema di crittografia per file sarebbe più o meno sicuro della crittografia del volume?

score 4 · Answer 1

Esiste assolutamente è una preferenza di sicurezza per salvare dati sensibili al di fuori della tua web root. Se non si desidera che gli utenti casuali possano accedere ai dati, non inserirli in Web root.

Certo, puoi impostare i permessi del file come non leggibili o configurare Apache per negare l'accesso al file o usare mod_rewrite per bloccare i tentativi di accesso al file, ma questi meccanismi di sicurezza sono molto più soggetti a errori e più scomodi che semplicemente mettere dati sensibili al di fuori della web root. E i dati di sessione si qualificano sicuramente come dati sensibili.

E cosa impostare i permessi della cartella dipende dalla configurazione del tuo server. In una configurazione LAMP standard, PHP verrà eseguito come lo stesso utente di Apache (spesso nobody ). Tuttavia, in hosting condiviso lo script PHP viene spesso eseguito con l'utente SFTP / shell del dominio. In ogni caso, non dovresti dare agli altri utenti l'accesso in lettura ai tuoi dati di sessione.

score 2 · Answer 2

Alcune regole generali sulla sicurezza ti faranno risparmiare molto dolore. Sì, è tecnicamente possibile memorizzare contenuti aggiornabili all'interno del webroot. Ma è necessario assicurarsi che gli elementi che non si desidera modificare dagli utenti non possano essere modificati dagli utenti e che l'archiviazione del contenuto non possa essere utilizzata per ospitare dati che non dovrebbero essere presenti e che non vi è alcuna diretta accedere al cotnent tramite il webserver e che i dati memorizzati non sono di per sé codice (PHP, javascript, ssi ...). La vita diventa molto più semplice quando si archiviano i dati inviati dall'utente altrove. Inoltre, aiuta a rendere l'intero contenuto del webroot in sola lettura sul server web.

I had a 'file permission refused' type error. Should I set the folder ownership to the apache user (600, 640 or 644?)

Questa è una domanda molto più generale. Di solito definisco un paio di gruppi (e faccio buon uso del flag setgid nelle directory), compresi gli amministratori del sito ma escludendo il web server uid (webdev) e uno con gli amministratori del sito e il web server uid (webdata). Tutti i file all'interno della web root sono leggibili da altri solo scrivibili da webdev. La directory dei dati (file di sessione, alcuni contenuti dinamici) è scrivibile dal gruppo webdata. Ma questo potrebbe non essere il modello giusto per te. Creare directory / file .rwxrwxrwx dovrebbe essere l'ultima risorsa.

Inoltre, cerca di non utilizzare le directory relative quando fai riferimento a parti diverse del tuo sito. Rende il sito nel suo complesso mobile, ma mina la capacità di spostare facilmente parti del sito. Se definisci un URL di base nella tua configurazione, usa questo prefisso per i percorsi che ottieni il meglio da entrambi i mondi.