sessioni solo con i cookie, perchè?

[cescoh]

Originariamente inviato da Fabio Heller
Ciao,
Le sessioni utilizzano i cookie o il passaggio nell'url per mantenere la persistenza

ebay usa soltanto i cookie perchè il passaggio del sid nell'url può comportare pratiche poco sicure se non si sta attenti (session hijacking, session fixation) . Infatti anche PHP di default disabilità il trans_id.

Grazie Fabio,

Mi interessava approfondire proprio questa prima parte della tua risposta.

Se ebay ha fatto questa scelta, e non credo i suoi sviluppatori avessero problemi a implementare i sistemi di sicurezza necessari a gestire il mantenimento delle sessioni anche tramite URL, potrebbe essere perchè ha fatto delle valutazioni a livello statistico (ha sicuramente i numeri per trarre conclusioni attendibili) che hanno rivelato la disponibilità dei cookie sulla maggior parte dei client.

Che ne dici?

Ciao e grazie

[daniele_dll]

Originariamente inviato da Fabio Heller
Ciao,
Le sessioni utilizzano i cookie o il passaggio nell'url per mantenere la persistenza

ebay usa soltanto i cookie perchè il passaggio del sid nell'url può comportare pratiche poco sicure se non si sta attenti (session hijacking, session fixation) . Infatti anche PHP di default disabilità il trans_id.

La questione su dove salvare i dati di sessione è leggermente diversa: lo puoi fare su qualsiasi tipo di supporto presente sul server.

La più performante resta l'uso dei file di testo, la più sicura (se ti trovi su un server condiviso) e versatile è l'utilizzo del database

se ti trovi su un server condiviso non è la + sicura xche se in qualche modo riesci ad accedere alla /tmp, sia perché chi ha messo su il server non ha abilitato l'open base dir oppure non ha abilitato il safe mode già puoi accederci
e poi i rischi sono dovuti ad un'errata programmazione non ad un'innato problema interno dovuto alla struttura.

sulla performance non so...xche devi tener conto di una cosa importante

se il tuo sito, negli ultimi 15 minuti, ha avuto 50 utenti connessi, ci saranno 50 file...solo tuoi dentro /tmp
Se su un server ci sono 1000 siti (che sono pochi) ad anche solo la metà usa le sessioni...e la metà di questa meta ha una quantità di utenti medio bassa...essendo che le sessioni php le elimina dopo abbastanza in un giorno ci possono essere ben + di 2000 file di sessioni...basta pensare che se ogni sito in giornata di quei 250 ha avuto 8 utenti...quei 2000 si superano abbastanza
Ora in base al filesystem del server la performance si va a farsi benedire oltre al fatto che se la tmp è una tmpfs, quindi risiede in memoria per questi di velocità questa tende a saturarsi con estrema velocità e quindi possono anche sorgere problemi, aggiungendoci poi che se il file system, per questo tipo di directory, è la ext3 su linux o qualsiasi fs su windows le prestazioni vanno a farsi benedire xche sia la ntfs sia la ext3 non sono adeguate a gestire una grande quantità di piccoli file. (di solito i file delle sessioni sono ben inferiori ad 1 kappa)

Per finire...ad es usando le sessioni su file non puoi sapere quanti utenti ci sono connessi contemporaneamente, dove sono gli utenti ed altro ancora

il mio consiglio è di usare le sessioni su database per maggior sicurezza, xche alla fin fine le prestazioni sono praticamente uguali con la differenza che su db sono + sicure xche puoi accederci tu e solo tu (i file del db su linux hanno come permessi 600 con propietario mysql e gruppo mysql...quindi ci può accedere root e mysql) e puoi avere un maggior controllo della cosa

questo, almeno, è il mio parare

[daniele_dll]

Originariamente inviato da cescoh
Grazie Fabio,

Mi interessava approfondire proprio questa prima parte della tua risposta.

Se ebay ha fatto questa scelta, e non credo i suoi sviluppatori avessero problemi a implementare i sistemi di sicurezza necessari a gestire il mantenimento delle sessioni anche tramite URL, potrebbe essere perchè ha fatto delle valutazioni a livello statistico (ha sicuramente i numeri per trarre conclusioni attendibili) che hanno rivelato la disponibilità dei cookie sulla maggior parte dei client.

Che ne dici?

Ciao e grazie

questo è vero...ma vuol dire comunque escludere una certa fascia di utenti
e siccome si tratta di perdere poco + tempo, beh, alla fin fine non credo sia un gran problema

ad esempio, molti attakki svaniscono nel nulla facendo controllare l'ip della sessione ad ogni esecuzione...un'operazione che richiede meno di quale milionesimo di secondo ti sventa una buona percentuale di attakki

[Fabio Heller]

Originariamente inviato da daniele_dll
se ti trovi su un server condiviso non è la + sicura xche se in qualche modo riesci ad accedere alla /tmp, sia perché chi ha messo su il server non ha abilitato l'open base dir oppure non ha abilitato il safe mode già puoi accederci
e poi i rischi sono dovuti ad un'errata programmazione non ad un'innato problema interno dovuto alla struttura.

Infatti ho escluso esplicitamente il caso del server condiviso

sulla performance non so...xche devi tener conto di una cosa importante

se il tuo sito, negli ultimi 15 minuti, ha avuto 50 utenti connessi, ci saranno 50 file...solo tuoi dentro /tmp
Se su un server ci sono 1000 siti (che sono pochi) ad anche solo la metà usa le sessioni...e la metà di questa meta ha una quantità di utenti medio bassa...essendo che le sessioni php le elimina dopo abbastanza in un giorno ci possono essere ben + di 2000 file di sessioni...basta pensare che se ogni sito in giornata di quei 250 ha avuto 8 utenti...quei 2000 si superano abbastanza

Per evitare la proliferazione di file di solito si azzera il controllo automatico di PHP sui file di sessione scaduti e lo si fa da codice (dallo script stesso che lo usa) o attraverso un crontab periodico. I file di default restano 20 minuti, ma si può abbassare tranquillamente il tempo.

Ora in base al filesystem del server la performance si va a farsi benedire oltre al fatto che se la tmp è una tmpfs, quindi risiede in memoria per questi di velocità questa tende a saturarsi con estrema velocità e quindi possono anche sorgere problemi, aggiungendoci poi che se il file system, per questo tipo di directory, è la ext3 su linux o qualsiasi fs su windows le prestazioni vanno a farsi benedire xche sia la ntfs sia la ext3 non sono adeguate a gestire una grande quantità di piccoli file. (di solito i file delle sessioni sono ben inferiori ad 1 kappa)

Siamo d'accordo che ci vogliono le risorse hardware più adatte alla propria applicazione e il filesystem migliore (mi pare che ultimamente Reiser vada per la maggiore).

Per finire...ad es usando le sessioni su file non puoi sapere quanti utenti ci sono connessi contemporaneamente, dove sono gli utenti ed altro ancora

Lo puoi fare attraverso un conteggio (gestibile da shell, o via PHP) dei file presenti (ogni sito ha la sua temp per le sessioni, ovviamente).

il mio consiglio è di usare le sessioni su database per maggior sicurezza, xche alla fin fine le prestazioni sono praticamente uguali con la differenza che su db sono + sicure xche puoi accederci tu e solo tu (i file del db su linux hanno come permessi 600 con propietario mysql e gruppo mysql...quindi ci può accedere root e mysql) e puoi avere un maggior controllo della cosa

Sono d'accordo che il database sia la soluzione preferibile (perchè più versatile e comoda) nei siti di grandi dimensioni (anche se non si tratta di server condiviso e anche quando non ci sono problemi di sicurezza).
Ma bisogna comunque fare attenzione RDBMS perchè come MySQL bloccano l'intera tabella quando fai un delete, quindi all'eliminazione delle sessioni scadute (che di solito usando il db si fa ad ogni accesso) corrisponde una coda di accessi in attesa.
Insomma anche il database non è la soluzione di tutti i mali

[Fabio Heller]

Originariamente inviato da cescoh
Se ebay ha fatto questa scelta, e non credo i suoi sviluppatori avessero problemi a implementare i sistemi di sicurezza necessari a gestire il mantenimento delle sessioni anche tramite URL, potrebbe essere perchè ha fatto delle valutazioni a livello statistico (ha sicuramente i numeri per trarre conclusioni attendibili) che hanno rivelato la disponibilità dei cookie sulla maggior parte dei client.

Che ne dici?

Immagino di sì, anche perchè bell'avere i cookie attivi non c'è veramente nulla di male.
Se si tratta di un'esigenza di maggiore sicurezza, quindi in un'area riservata, meglio secondo me obbligare l'utente ad attivare i cookie.
In tutti gli altri casi (semplice persistenza tra le pagine) vale la pena tenere conto anche di chi non ha i cookie attivi

[daniele_dll]

Originariamente inviato da Fabio Heller
Infatti ho escluso esplicitamente il caso del server condiviso

pardon avevo capito che ti riferivi esplicitamente ai server condivisi

Siamo d'accordo che ci vogliono le risorse hardware più adatte alla propria applicazione e il filesystem migliore (mi pare che ultimamente Reiser vada per la maggiore).

molti hoster montano distro pre-pronte come red hat 9 o debian stable e questi montano principalmente ext3 :\ (che è ottima se non ci sono migliaia di piccoli file, io uso principalmente questa, anche xche mi sembra MOLTO + stabile...il mio server a casa si spegne ogni giorno di botto e non ho mai avuto problemi di corruzione invece con reiserfs si :\)

Lo puoi fare attraverso un conteggio (gestibile da shell, o via PHP) dei file presenti (ogni sito ha la sua temp per le sessioni, ovviamente).

il problema è che praticamente nessun servizio di hosting ha una cartella tmp per ogni utente (cosa che dovrebbe invece essere) e di conseguenza si corrono moltiii rischi...ad esempio se voglio vedere il contenuto di una sessione di un'altro utente...basta che mi setto il cookie e avvio uno script che mi fa un print_r di $_SESSION, ovviamente devo conoscere l'id di sessione
Il problema è serio...xche se open base dir non è abilitato e quindi posso accedere alla tmp...posso quindi modificare TUTTI i vari contenuti senza problemi...e ciò è grave e posso anche visualizzarmi le varie sessioni xche sono tutte sotto lo stesso utente (per evitare questo è problematico xche si può fare SOLO con apache 2 e questo comunque configurato in un certo modo)
Se non si può usare open base dir la possibilità di avere l'id di sezzione è praticamente nullo ma anche quello di conteggiare il numero di utenti o altro

Sono d'accordo che il database sia la soluzione preferibile (perchè più versatile e comoda) nei siti di grandi dimensioni (anche se non si tratta di server condiviso e anche quando non ci sono problemi di sicurezza).
Ma bisogna comunque fare attenzione RDBMS perchè come MySQL bloccano l'intera tabella quando fai un delete, quindi all'eliminazione delle sessioni scadute (che di solito usando il db si fa ad ogni accesso) corrisponde una coda di accessi in attesa.
Insomma anche il database non è la soluzione di tutti i mali

questo è vero, però, secondo me, ha meno mali di altre soluzione in complessivo :P

[cescoh]

Intanto vi ringrazio molto per i preziosi contributi, mi avete messo diverse pulci nell'orecchio che cercherò di approfondire studiano un po'.

Cercando di tirare le somme, una soluzione che potrebbe ritenersi abbastanza sicura per il mio caso (ma anche in generale) potrebbe essere:

- sessioni solo con i cookie
- controllo anche dell'ip di provenienza (questo ovviamente penalizza chi si connette da un accesso PPP che vedrà terminata la sua precedente sessione nel caso in cui si disconnetta momentaneamente dalla rete)
- l'handler delle sessione lo lascerei su file in quanto il server è dedicato, magari implementando gli accorgimenti di cui si è detto per non appesantire il file system. E poi il db, che gira sulla stessa macchina, viene usato pesantemente anche da tutti i moduli che compongono il carrello, il che significa moltissimi accessi per recuperare semplici dati, quindi penso che fargli gestire anche le sessioni potrebbe appesantirlo.

Ciao

[Fabio Heller]

Il controllo sull'ip lo lascerei stare, perchè non distingue tra utenti che si trovano nella stessa LAN e , con alcuni provider, fornisce anche falsi negativi: alcuni provider (specialmente americani) modificano l'ip dell'utente durante la navigazione.

Direi che basta far sì che la sessione possa rimanere inattiva solo lo stretto necessario

[daniele_dll]

Originariamente inviato da Fabio Heller
Il controllo sull'ip lo lascerei stare, perchè non distingue tra utenti che si trovano nella stessa LAN e , con alcuni provider, fornisce anche falsi negativi: alcuni provider (specialmente americani) modificano l'ip dell'utente durante la navigazione.

Direi che basta far sì che la sessione possa rimanere inattiva solo lo stretto necessario

beh, credo che sia una percentuale abbastanza eseguia
ma io per lo + mi riferivo all'accoppiata IP-SESSIONE non solo IP

sarebbe inutile nel caso di una LAN per il quale il controllo non darebbe l'effetto desiderato...ovvero se io pinco pallo X mi metto la SID del mio collega allora si...è inutile ma i casi sono abbastanza pochi e comunque può servire ad arginare il problema nella maggioranza dei casi

per quanto riguarda i provider americani che cambiano l'ip, non so dove l'hai letto, ma mi sembra surreale perché se cambio l'ip nell'intestazione del pacchetto il picci remoto mi butta l'ip da un'altra parte nella risposta...e quindi o il provider americano ha uno stack tcp/ip modificato con delle tabelle per lo scrambling interne (ed ovviamente l'ip a cui vengono renviati i dati sono comunque suoi) oppure è una bufala xche non è tecnicamente fattibile

Tornando su...è inutile anche nei cosi con FastWeb o altre reti che fanno il NAT, però comunque sono una quantità abbastanza ridotta

[cescoh]

anche io intendevo dire controllo sia del SID che dell'IP.

Per le reti NATTATE, il problema non si pone in quanto, anche se credo che sia molto improbabile, se arrivano due client dalla stessa LAN avranno si lo stesso IP ma SID diversi per cui va bene.