Pagina 1 di 3 1 2 3 ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 25

Discussione: Sicurezza con sessioni

  1. #1

    Sicurezza con sessioni

    Mi è sorto un dubbio, per quanto riguarda la sicurezza dell'uso delle sessioni, per tener traccia dell'avvenuto login di un utente.
    Ora i passaggi sono:
    -login utente
    -controllo validità credenziali
    -se il controllo ha esito positivo,salvo l'orario di accesso dell'utente sul db, l'id del record in una variabile di sessione e una variabile di sessione fittizia ("$_SESSION['logged']")
    -per ogni pagina controllo che la variabile fittizia sia settata, e se non lo è, faccio un redirect alla pagina di login
    -al logout, aggiorno il record di accesso salvato all'inizio, che ha id uguale a quello salvato nella variabile di sessione, con l'orario di uscita e distruggo la sessione.

    Mi chiedevo se non fosse meglio , invece che controllare solo se la variabile di sessione fittizia è settata o meno, generare un hash casuale da salvare dentro di essa, salvare l'hash e l'id del record di accesso sul datatbase, e controllare la corrispondenza per ogni pagina.

    Potrebbe andare ?

  2. #2
    Utente di HTML.it L'avatar di Virus_101
    Registrato dal
    Sep 2008
    Messaggi
    2,497
    Beh come sistema di sicurezza e' abbastanza basilare.
    E ovviamente devi valutare te che "improvements" fare.

    Una soluzione potrebbe essere simile alla tua :

    1- tracciare la timestamp di login
    2- tracciare il session id generato
    3- tracciare l'ip

    Generare un hash da md5 basato su username+pwd+1+2+3 e quindi per controllare che l'utente sia proprio quello che cerchi nel layer di controllo sessione esegui una query

    del tipo select quellochetipare from utenti where MD5( concat(username,pwd,loginTs,sessionId,ip) )=$phpGeneratedChecksum

    E' uno dei tanti modi che puoi usare per aumentare la sicurezza.
    Volendo cipuoi tracciare anche lo user agent o altri dati .... magari un sync code salvato in cookie o quello che sia. Puoi crittografare le stringhe che metti in sessione e recuperare la chiava da db e confrontare etc...

    CMq il controllo con hashstring ti da qualche sicurezza in piu' contro session hijacking.... poi se ci sono altre idee ben vengano

  3. #3
    Utente di HTML.it
    Registrato dal
    Apr 2004
    Messaggi
    3,709
    non cambia nulla, anzi è peggio (in termini di "risorse")... per controllare la corrispondenza dell'hash dovresti cmq avere l'id e quindi registrarlo sempre e cmq come prima

    per "migliorare" la sicurezza puoi solo verificare ad ogni controllo se alcuni dati sono ancora validi, p.es. controllare che NON vari l'ip durante la connessione, ma cmq devi usare:
    - dati reperibili automaticamente (come l'ip)
    oppure
    - dati immessi dall'utente (come lo username: ma questo lo chiedi solo la prima volta!)

    ...infatti alcuni servizi a certe azioni o ogni tot richiedono di nuovo lo username

  4. #4
    Utente di HTML.it L'avatar di Virus_101
    Registrato dal
    Sep 2008
    Messaggi
    2,497
    Ovviamente ogni operazione richiede risorse e va bilanciato il livello di sicurezza che si vuole mantenere con le risorse richieste dallo stesso.

    Ogni reuqest infatti deve eseguire una serie di controlli (anche da database) e questo pesa.
    Come pesano le forcedure di hashing.

    Quindi puoi pensare varie soluzioni eseguire i test di performance , eseguire qualche conteggio in base all'utenza media e di picco sul sistema e verificare quale soluzione possa essere la migliore.

    Diciamo che crc potrebbe anche andarti bene che generi un checksum eseguendo XOR sulla stringa ... e quindi e' abbastanza veloce poi io farei alcune funzioni di prova
    Avvierei i test e in base ai risultati deciderei

  5. #5
    E' un'area di amministrazione, quindi al massimo si connette l'amministratore del sito, e credo (correggetemi se sbaglio ) che di grandi problemi di prestazioni non ce ne siano.
    Comunque il vostro consiglio è quello di stare su dei controlli che richiedano meno uso possibile di database?

  6. #6
    Utente di HTML.it L'avatar di Virus_101
    Registrato dal
    Sep 2008
    Messaggi
    2,497
    DIpende sempre da te, da quanto vuoi spingere sui controlli in relazioni alle prestazioni che ti servono. Se necessiti di area supersicura allora timeout molto bassi con richiesta user-code ongi x tempo. Controllo database, controllo ip controllo login , e synccode nonche' user agent etc.....

    Eventuale filtro ip in base alla loro geolocalizzazione etc... li puoi spingerti davvero oltre ogni modo.
    Dipende da quanti controlli vuoi fare.

  7. #7
    Una sicurezza buona. Credo che il metodo che hai esposto prima,con alcune aggiunte, possa andare bene:
    -salvo la timestamp nel db appena si effettua il login
    -in una variabile di sessione salvo l'id corrispondente al record salvato prima ( mi serve per aggiornarlo con la timestamp del logout, nella tabella degli accessi)
    - con l'ip e l'id creo un hash, che salvo in un'altra variabile di sessione e nel database nella tabella di controllo accessi
    -per ogni pagina controllo che l'hash salvato nella variabile di sessione sia uguale a quello nel database

    Alla fine avrò due variabili di sessione, una contenente l'id della tabella accessi e una l'hash di controllo, e per ogni pagina dovrò effettuare una query per controllare l'hash.
    Inoltre ad ogni logout cancellerò tutto il contenuto ( hash corrente e hash rimasti perchè non è stato effettuato il login) della tabella degli hash.

    Come la vedete?

  8. #8
    Utente di HTML.it L'avatar di Virus_101
    Registrato dal
    Sep 2008
    Messaggi
    2,497
    Un poco incasinata sinceramente.

    L'idea da questo punto di vista e' di stipare informazioni di tracciamento e sincronizzazione + info sensibili in locazioni diverse in modo che i controlli possa assicurare che :

    - sulla rete viaggino il minor numero di info sensibili possibile
    - sia sempre possibile identificare il corretto utente in base una serie di controlli eseguiti su info eterogenee inviate da contesti differenti(cookie,user agent, ip etc..)

    Quindi nel database devi mantenere i dati sensibili che saranno usati da opportune procedure per poter generare le stringhe di sincronizzazione, tali stringhe si generano con tecniche di hahing in quanto non sono reversibili (a differenza di tecniche di crittografia).

    Quindi io farei una cosa del genere

    1- database con i dati utente
    2- database colonne per gestione accessi :
    + timestamp ultimo login eseguito
    + id sessione corrente
    + timeout massimo per il controllo utente(opzionale ma se ti serve un livello alto puo' essere utile)
    + token privato di controllo (stringa casuale assegnata all'utente e utilizzata per generare gli hash)
    + ip connessione attuale
    + user agent connessione attuale
    + token attuale

    Poi quando l'utente esegue login :

    1- recuperi e controlli user e pwd dell'utente
    2- salvi in sessione tutti i dati dell'utente
    4- generi il token di controllo
    3- aggiorni il database con i dati di ip user agent etc...


    La procedura di controllo sessione recupera i dati dalla request
    ip user agent session id etc etc....
    A questo punto generi il crc dai dati della request e puoi eseguire tutti i controlli
    che vuoi. Al cambiamento anche di 1 solo parametro che dipende da user agent, ip
    cod sync o altro ..... blocchi tutto e distruggi la sessione .

    Ci sono cmq anche altri modi ad esempio non salvare il token attuale in db ma generarlo al volo in query con le funzioni sql .. quindi se cambi un par in database la sessione di blocca in auto.

    Poi vedi te ma considera sempre bene i contesti cosa devono fare e come devono interagire in base sempre a cosa gesticono

  9. #9
    Non credo di inserire il timeout per il controllo utente, ma solo per curiosità , che valore avresti salvato in questo campo?
    Per generare il token privato mi basta solo una stringa di caratteri e numeri casuali?
    Per il token attuale invece devo criptare i dati dell'utente usando il token privato come chiave?
    la procedura di controllo recupera i dati dal database, e poi?
    verifico i dati facendo un confront tra il checksum dei dati nel database e quelli attuali??

  10. #10
    Utente di HTML.it L'avatar di Virus_101
    Registrato dal
    Sep 2008
    Messaggi
    2,497
    Originariamente inviato da addictedToPhp
    Non credo di inserire il timeout per il controllo utente, ma solo per curiosità , che valore avresti salvato in questo campo?
    Il tiemout lo userei per i controlli di ri-conferma utente, dopo x secondi devi inserire username o codice di controllo o quello che ti pare per confermare che sei sempre tu.(Pignolerie ma se vuoi aumentare i lvl di security ... e' come quando parte lo screensaver con password sul pc)

    Originariamente inviato da addictedToPhp
    Per generare il token privato mi basta solo una stringa di caratteri e numeri casuali?
    Esatto puoi fare 1 metodo che li genera stringe di dimensione x con dati "casual"

    Originariamente inviato da addictedToPhp
    Per il token attuale invece devo criptare i dati dell'utente usando il token privato come chiave?
    Mai paralto di crittazione dati, ma solo di hashing usa crc che e' il piu' veloce genrei il cheksum dei dati sensibili dai dati della request e confronti il checksum con quanto hai in database e anche qui puoi operare in 2 modi 1->generi il checkusm a login e nella query fai il controllo where chekcsum="$checksum" oppure non lo salvi e la query diventa where crc( concat(campo1,campo2,camp3) )="$checksum"

    Originariamente inviato da addictedToPhp
    la procedura di controllo recupera i dati dal database, e poi?
    Poi li controlli con i dati della request.

    Originariamente inviato da addictedToPhp
    verifico i dati facendo un confront tra il checksum dei dati nel database e quelli attuali??
    Esatto recupera i dati da request e conforna con database !

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.