Quali problemi di sicurezza ci sono durante la lettura dei cookie con .htaccess?

1

Ho un sito web (per hobby) che funziona solo su SSL (ad es. HTTPS a livello di sito). Il sito non tratta di finanze, numeri di previdenza sociale o altro di quel livello di importanza. Tuttavia, mi piacerebbe assicurarlo il più ragionevolmente possibile. Quando un utente effettua l'accesso, vengono scritti due cookie: un cookie memorizza l'id utente e un secondo memorizza un ID sessione. I cookie sono contrassegnati come Secure e HttpOnly.

Ho una directory in cui mi piacerebbe che tutti gli utenti registrati potessero accedere ai file. Mi sembra che un modo per ottenere questo risultato sia utilizzare .htaccess nella directory della chiave per vedere se esiste un cookie valido per l'utente-id: in tal caso, concedere l'accesso, ma in caso contrario, reindirizzare alla pagina di accesso. In questo modo, non ho bisogno di continuare ad aggiornare i valori legali per il cookie o di avere un sovraccarico nel controllo dell'accesso.

Ho trovato il seguente codice per .htaccess:

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_COOKIE} !^.*cookie-name.*$ [NC]
RewriteRule .* /login-error/set-cookie-first.html [NC,L]

e tutto funziona perfettamente: quando si accede come utente registrato (ad esempio, quando c'è un cookie chiamato cookie-name) ottengo l'accesso alla directory; quando non effettuato l'accesso, sono reindirizzato alla pagina di accesso.

Tuttavia, mi chiedo: quali problemi di sicurezza ho trascurato? Ad esempio, è possibile che un utente malintenzionato crei un cookie con il nome corretto nel browser dell'hacker e poi pensi che il mio sistema sia un vero cookie?

    
posta RPW 13.02.2013 - 15:58
fonte

2 risposte

0

Se il tuo server concede l'accesso solo visualizzando un cookie con l'ID utente, allora la conoscenza dell'ID di un utente è sufficiente per ottenere l'accesso. L'ID utente è quindi un prezioso segreto. Ma l'ID utente non è veramente segreto; spesso, l'ID utente è il suo nome , che può essere considerato pubblico o almeno ipotetico.

Ciò di cui hai bisogno è un segreto specifico dell'utente, che, quando presentato, concede l'accesso - qualcosa che l'utente normale può mostrare, ma che non può essere indovinato dagli estranei. Questo è solitamente noto come "password". La configurazione completa è quindi:

  • Ci sono sessioni . Una sessione è uno stato lato server che è "di proprietà" di un utente. Le sessioni sono identificate da grandi stringhe di byte casuali (almeno 16 byte, generate con un PRNG crittograficamente protetto ).

  • Quando un utente si connette per la prima volta, non ha cookie da rinviare. Il server reindirizza l'utente a una pagina di accesso.

  • Quando l'utente immette nome e password e il server ha verificato che la password sia corretta, il server crea una nuova sessione, con l'ID di sessione casuale, e invia quella ID della sessione come valore del cookie.

  • Per ogni pagina successiva, il browser dell'utente invierà il cookie. Dopo aver ricevuto tale cookie, il server cerca nel suo database la sessione corrispondente. Se il server non trova una sessione con quell'ID, quindi reindirizza l'utente alla pagina di accesso.

  • Per mantenere sotto controllo la dimensione della memoria, il server farà scadere le sessioni (ovvero dimenticandole tutte) che non sono state utilizzate per qualche tempo (quindi il server dovrebbe mantenere in ogni sessione una data dell'ultimo utilizzo).

La sicurezza di questo schema dipende dal fatto che gli attaccanti non possono "indovinare" un ID di sessione valido: dal momento che l'ID di sessione a caso, l'unico algoritmo di ipotesi possibile è la fortuna (gli attaccanti cercano alcuni byte casuali e spera di colpire un ID di sessione esistente ); l'utilizzo di un ID sessione sufficientemente ampio (i 16 byte con generazione sicura) garantisce che la probabilità di successo per l'autore dell'attacco sia sufficientemente bassa da essere trascurata.

    
risposta data 13.02.2013 - 17:11
fonte
0

Vuoi legare agli ID di sessione non gli ID utente. Gli ID utente non cambiano e non possono scadere. Possono anche essere falsificati se è noto un ID utente. Poiché gli ID sessione sono casuali, non riutilizzati e scadono, è molto più difficile creare un cookie di sessione valido senza effettuare effettivamente l'accesso.

    
risposta data 13.02.2013 - 16:05
fonte

Leggi altre domande sui tag