Visualizzazione dei risultati da 1 a 4 su 4
  1. #1

    area riservata e variabili di sessione

    Memorizzare dati di login (es. username) nelle variabili di sessione può creare problemi di protezione..
    Come posso risolvere il problema?

    Salvare i dati di accesso in un database
    (username, ip, orario di autenticazione)
    e salvare solo l'ip e una variabile del tipo "autenticato"
    nella variabile di sessione è una scelta fattibile?
    Che problemi di protezione può darmi?

    Dall'ip risalirei così alla username autenticata tramite query sul database degli accessi ogni volta che occorre.

    Esistono altre soluzioni meno complesse e magari più sicure al problema?

    Grazie a tutti coloro che risponderanno!

  2. #2
    Ciao.

    Di solito lo username e' univoco. I dati di accesso sono gia' nel database. Puoi metterci a piacer tuo altri dati come l'ora dell'ultimo accesso o altro ancora che possa servire da statistica. Puoi anche fare una tabella dove associ ip <-> id_user.

    Nel file di sessione personalmente memorizzo il nickname tanto per poter salutare o per chiamare lo user con un nome quando occorre, ed i privilegi. Se mi servono altri dati li peschero' tramite il nickname, il codice del privilegio servira' per autorizzare pagine od azioni.

    Vuoi fare il complicato? memorizza nel file di sessione anche un hash formato da nick + privilegio. prima di ogni azione sensibile potrai verificare se nick e privilegio corrispondono all'hash immesso in origine.

    E' un argomento trito e ritrito un molti threads. Tutti come se dovessero proteggere fort knox... Il problema non e' il file di sessione, ma e' l'utilizzo di password e nick altrui. Possono essere dei fuck ma saranno custoditi con ogni cura. La prima protezione e' una password non banale e tenuta segreta da parte dello user.


    Il silenzio è spesso la cosa migliore. Pensa ... è gratis.

  3. #3
    Grazie Piero,
    quello che sto scrivendo non l'ho scritto a caso
    e anche se non necessito di un sito-fort knox, ho già avuto amici simpatici che si sono divertiti ad entrare nel mio db e a cambiare i dati della community che ho scritto..
    Non è niente di serio, anzi, ma vorrei ke funzionasse come si deve..
    Io ho memorizzato la username nel file di sessione per poter richiamare sempre i dati dell'utente nelle pagine di modifica profilo e per richiamarlo nel guestbook..

    La pass l'ho codificata in base 64 (l'md5 non posso usarlo perché vorrei risalire alla pass quando viene smarrita) ma non mi ha dato problemi.

    I problemi me li ha dati la pagina di iscrizione e la variabile di sessione..

    e quindi ritengo utile fare un log degli accessi e togliere la user
    dalla variabile di sessione..

    in alternativa utilizare la user in md5 nella sessione può essere utile?

    come posso proteggere i campi di un form in post in modo da evitare qualsiasi tipo di intrusione nel db?

    htmlentities è sufficiente?

    grazie a piero e tutti coloro che hanno letto il mio post!

  4. #4
    Hai un mucchio di dubbi. Se hai avuto intrusioni devi valutare da dove sono avvenute. Altrimenti rischi di blindare finestre tenendo le porte aperte.

    Se il tuo user passa per celia la pwd ad altri non ci puoi fare nulla. Devi solo differenziare lo user nella connessione a mysql. Dare allo user admin la possibilita di togliere, modificare, aggiungere ed allo user normale solo quella di inserire. Oppure di modificare solo quella inserita da lui stesso.

    Piu' che una sicurezza dell'accesso user, direi che dovresti puntare alla sicurezza dell'accesso al db.

    Ovvio che controlli sui contenuti devono esserci. Ma non puoi dire basta questo o quello, dipende da cio' che vorresti controllare. Fai una ricerca sui precedenti post su questi argomenti. Troverai materiale da leggere fino al prossimo autunno...



    Il silenzio è spesso la cosa migliore. Pensa ... è gratis.

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 © 2024 vBulletin Solutions, Inc. All rights reserved.