2009-07-25 15 views
48

Ho uno script di accesso che verifica un nome utente/password rispetto ai dati in una tabella "utente". Inoltre, ho una tabella 'ruoli' che specifica il livello di accesso di un determinato utente. Supponendo che io stia usando degli script di login sicuri, ci sono delle falle nella sicurezza semplicemente eseguendo una query aggiuntiva, al login, contro la tabella 'ruoli' per scoprire il livello di autorizzazione dell'utente e archiviarlo in una variabile di sessione? L'idea sarebbe allora quella su qualsiasi pagina con autorità mista, potrei semplicemente interrogare la variabile di sessione per scoprire il livello di autorizzazione dell'utente connesso.Quanto sono sicure le variabili di sessione PHP?

Grazie.

risposta

69

Le sessioni sono significativamente più sicure rispetto, ad esempio, ai cookie. Ma è ancora possibile rubare una sessione e quindi l'hacker avrà accesso a tutto ciò che è in quella sessione. Alcuni modi per evitarlo sono IP Checking (che funziona piuttosto bene, ma è molto basso fi e quindi non affidabile da solo), e usa un nonce. In genere con un nonce, si dispone di un "token" per pagina in modo che ogni pagina controlli che il nonce dell'ultima pagina corrisponda a ciò che ha memorizzato.

In entrambi i controlli di sicurezza, c'è una perdita di usabilità. Se fate il controllo IP e l'utente è dietro un firewall Intranet (o qualsiasi altra situazione che causa questo), che non detiene una costante IP per l'utente, dovranno ri-autenticarsi ogni volta che perdono la loro IP. Con un nonce, si ottiene sempre la situazione "Facendo clic indietro causerà la rottura di questa pagina".

Ma con un cookie, un hacker può rubare la sessione semplicemente utilizzando tecniche XSS piuttosto semplici. Se si memorizza l'ID sessione dell'utente come cookie, anche questo è vulnerabile. Quindi, anche se la sessione è solo penetrabile a qualcuno che può fare un hack a livello di server (che richiede metodi molto più sofisticati e di solito una certa quantità di privilegi, se il tuo server è sicuro), hai ancora bisogno di un ulteriore livello di verifica su ogni richiesta di script. Non dovresti usare i cookie e AJAX insieme, poiché questo rende un po 'più facile andare in città se quel cookie viene rubato, poiché le tue richieste di ajax potrebbero non ottenere i controlli di sicurezza su ogni richiesta. Ad esempio, se la pagina utilizza un nonce, ma la pagina non viene mai ricaricata, lo script può verificare solo la corrispondenza. E se il cookie è in possesso del metodo di autenticazione, ora posso andare in città a fare la mia cattiveria usando il cookie rubato e il buco AJAX.

+19

Si noti che PHP memorizza l'ID di sessione come cookie. –

+0

+1 Potresti spiegare di più su un nonce? link possibile? – Petrogad

+5

L'articolo wiki su nonce è piuttosto leggero, ma ha link decenti: http://en.wikipedia.org/wiki/Cryptographic_nonce l'idea di base, a quanto ho capito, è come un token, ma può essere usata solo una volta (numero usato una volta). Ogni richiesta di pagina controlla l'ultimo nonce e ne crea uno nuovo. Quindi se provo un attacco di forza bruta sulla tua password, ottengo uno sparo, poiché il nonce non combacerà nel round 2. Se rubo la sessione e il nonce di quella pagina, potrei continuare a fare richieste e rinnovare il nonce fino a quando fai una richiesta che butta fuori la partita nonce. Perché vedrebbe la mia richiesta e il mio nonce, aggiornare ... – Anthony

16

Solo gli script in esecuzione sul server hanno accesso alla matrice _SESSION. Se si definisce l'ambito del cookie di sessione, è possibile anche limitarlo a una directory specifica. L'unico modo in cui qualcuno oltre a te potrebbe ottenere i dati della sessione è iniettare del codice PHP in una delle tue pagine.

Per quanto riguarda il sistema che si sta utilizzando, è accettabile ed è un buon modo per salvare le chiamate al database, ma tenere presente che richiederà all'utente di disconnettersi e accedere nuovamente per applicare eventuali modifiche di autorizzazione. Quindi se volevi bloccare un account e quell'utente è già loggato, non puoi.

2

Se si basano su un valore memorizzato all'interno di una variabile di sessione per determinare ruoli poi si perde la capacità di modificare il valore nel DB e lo hanno riflesso contro la sessione corrente dell'utente. Se si guarda a Zend Framework, c'è una chiara distinzione tra l'autenticazione e l'autorizzazione, e gli avvisi fortemente formulate nel manuale per memorizzare solo la minima quantità di dati nella sessione (cioè "Yup, egli dell'utente # 37 & ha registrato") .

Per quanto riguarda la 'sicurezza' va - a meno che non siete su host condiviso, non c'è niente di cui preoccuparsi. Su un host condiviso configurato correttamente, dovrebbero essere anche relativamente sicuri.

13

Va notato che in Apache il PHP $ _SESSION superglobale è accessibile attraverso virtualhosts.Considerare questo scenario:

  • Il server ospita due domini, esempio.com e instance.org. Le sessioni PHP sono memorizzate in cookie che sono limitati al dominio.
  • Un utente accede a example.com e riceve un ID di sessione. Example.com imposta alcune variabili di sessione (che sono memorizzate sul server, non nel cookie).
  • Una terza parte intercetta il cookie durante la trasmissione e lo passa a instance.org. Instance.org ora ha accesso alle variabili di sessione example.com.

Questo non è un grande affare quando si controlla tutte le VirtualHosts sul server, ma se siete su una macchina condivisa, è problematico.

+1

sai come limitare uno sperglobal per host virtuale, se possibile? – JRsz

+0

@JRsz è possibile modificare la directory in cui sono memorizzate le sessioni nel proprio php.ini ou tramite la funzione session_save_path() (http://php.net/manual/en/function.session-save-path.php). – SandroMarques

Problemi correlati