Pagina 1 di 22 1 2 3 11 ... ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 216
  1. #1
    Utente di HTML.it L'avatar di blukarma
    Registrato dal
    Aug 2002
    Messaggi
    1,186

    sessioni e password quale è il medoto corretto?

    ho letto pillole e 3d ma ancora non riesco a capire, come potete immaginare devo proteggere delle pagine da visitatori indesiderati e, abbandonati i coockie, ho deciso di optare per le sessioni.

    a questo punto decido di cominciare ma leggendo vari 3d credo di aver capito che non conviene mai passare variabili tipo pwd e usr, da form si intende.

    pensavo di articolare il login in questo modo:

    form.php ---> autenticazione.php (se verificata reindirizza) ---> pagina_protetta.php

    ora vorrei capire cosa di preciso devo mettere in autenticazione.php ed in pagina_protetta.php

    come avrete capito ho un pò di confusione in testa eppure ci riescono tutti, perchè io no???
    "viva la mucca, che dio la beneducca"
    (Diego Abatantuono - Eccezziunale... Veramente - 1982)

  2. #2
    una volta effettuato il login devi far si che il tuo utente durante la sua permanenza sul sito venga riconosciuto.

    Per far ciò puoi usare le sessioni,un metodo molto comodo; quindi crea un oggetto o una funzione(dipende da come programmi) che al caricamento di ogni pagina dell'area protetta verifichi che il tuo utente abbia effettuato login.

  3. #3
    Utente di HTML.it L'avatar di blukarma
    Registrato dal
    Aug 2002
    Messaggi
    1,186
    ok, il form lo ho già, mando tutto alla pagina di autenticazione (aut.php per esempio), lì ci dovrà essere una parte di codice che verifica se pwd e usr e o dà orrere o reindirizza alla prima pagina protetta (index.php).

    la funzione comincia dove? in aut.php o index.php?

    mi fate un esempio?
    "viva la mucca, che dio la beneducca"
    (Diego Abatantuono - Eccezziunale... Veramente - 1982)

  4. #4
    hum tu devi mettere il login nella pagina in cui ti serve...se poi i dati li fai analizzare in quella pagina o in un altra...bhe nn ha importanza...

    se ti serve evitare i bruteforcer in caso farei come fa IBF...ovvero scrive su HD delle immagini e le invia come codice da inserire insieme a login e passwd...con questo sistema...bhe un bruteforcer normale nn può neanche partire

    cmq...ti sconsiglio di usare le sessioni standard di php xche sono leggibili da tutti gli script...tutte le sessioni stanno in un'unica cartella e tutte con lo stesso utente (sotto linux, sotto win nn c'è neacneh il problema)

    uno script tonto può entrare nella dir, copiare, comprimere e far downloadare i file...se tu salvi info li...bhe è la fine.

    io ti consiglio caldamente di crearti delle sessioni "virtuali"
    ovvero su DataBase!

    è un po + fastidioso...ma x le sessioni a te serve sapere solo 1 cosa...l'ID DI SESSIONE...grazie a quello sei al sicuro!

    se hai 1 ID di sessione che passi sempre via GET o via COOKIE, l'unica cosa che può accadere è:
    l'user lascia il suo pc acceso appena loggato...entra un ladro copia la stringa, entro 5\10 minuti arriva dove deve arrivare inserisce la stringa ed fa ciò che vuole...(i 5\10 minuti indicano il tempo di timeout della sessione)...come ti rendi ben conto è MOLTOOOOOOO difficile...se poi ti vuoi mettere ancor + al sicuro...fai controllare l'IP della sessione...ovvero ti segni l'ip da cui è stato eseguito il LOGIN e quando controlli la sessione nel database controlli anche l'ip...cosi al ladro gli fai printare:

    "AH FESSO...questo è un ottimo sistema di login...con chi credi di avere a che fare?!?!?!?" :P

    Se poi la vuoi fare sporca...fai controllare pure l'user agent...ma poi si rischia la paranoia ^_^

    ok finito la premessa una ipotetica tabella sessioni è cosi:

    Table Sessions:

    id_sess - CHAR 32
    id_user - INT 10 - UNSIGNED
    ip - VARCHAR 25
    user_agent - VARCHAR 255
    last_action - INT 10 - UNSIGNED

    ovviamente devi avere una tabella utenti cosi:

    id_user - INT 10 - UNSIGNED - AUTOINCREMENT
    username - VARCHAR 255
    password - VARCHAR 255
    last_login - INT 10 - UNSIGNED


    il codice è stupido...e si divide in:
    - Login
    - LogOut
    - CheckSession
    - GarbageCollection

    ---=== LOGIN ===---

    in questa fase lo script nn deve far altro che controllare:

    1) Username e password siano corretti.
    2) Aggiungere la sessione
    3) Updatare il campo LAST_LOGIN

    il passo numero 1 nn te lo spiego...penso che tu sia tranquillamente in grado di farlo ^_^ :P

    Passo 2)
    1° Calcola id_sess così:
    $id_sess = md5(uniqid(microtime()));

    otterrai una stringa al 99% unica di 32 caratteri hashata in MD5. quello sarà l'ID di sessione

    2° Inserire nel DB la sessione
    Quando inserisci l'id ti devi assicurare che nn ci siano altre sessioni con lo stesso ID...xo siccome le possibilità sono 1 su un miliardo...fai un bel:
    DELETE FROM sessioni WHERE id_sess={$id_sess}
    poi x evitare carico qui io inserisco anche la garbage collection... (il punto numero 4)
    quindi il delete diventa:

    DELETE FROM sessioni WHERE id_sess={$id_sess} OR UNIX_TIMESTAMP(NOW()) - last_action => {$_SESSIONS_VARS['gc_time']}

    avrai delle domande tipo...

    1) Q: xche usi il timestamp?
    A: semplice...è un numero ed è + facile da gestire ed inoltre occupa di meno di una data normale

    2) Q: Cos'è $_SESSIONS_VARS['gc_time']?
    A: il $_sessions_vars è l'array che uso io per salvare tutte le info riguardo alla sessione...ad es la durata massima della sessione, ogni quando deve essere eseguita la garbage_collection, il prefisso del cookie ed altre cose cosi

    3) Q: xche usi un array?
    A: perché mi inglobo solo quello ed ho finito...ed inoltre se c'è il register_global ON e io ho un bug...usando l'array non possono settarmi le variabili ^_^

    ---
    Passo 3)
    a questo punto basta lanciare un update del tipo
    UPDATE users SET last_login = UNIX_TIMESTAMP(NOW()) WHERE id_user={$id_user}

    $id_user è l'ID utente che hai estratto durante il login...essenzialmente serve solo quello :P

    ok...penso che con questa fase abbiamo finito.

    ---=== LogOut ===---

    Questa fare è molto stupida...basta lanciare 1 semplice query di delete:

    DELETE FROM sessions WHERE id_sess={$_COOKIE['s']}

    premettendo che stai usando un cookie di nome s per salvare la sessione...se stai passando la var in GET allora: (io te lo consiglio...)

    DELETE FROM sessions WHERE id_sess={$_GET['s']}

    fine...

    ---=== CheckSession ===---

    questa è altrettanto semplice...basta controllare se la sessione che l'utente passa esiste e non sia scaduta...quindi una cosa del genere

    codice:
    function CheckSession() {
      global $_SESSIONS_VARS;
      $s = $_GET['s'] // o $_COOKIE['s'] se passi l'id via cookie
      
      if (!$s || strlen($s) != 32) {
        // id di sessione invalido!
        return FALSE;
      }
    
      $_querysql = "SELECT COUNT(id_sess) FROM sessioni WHERE id_sess={$s} AND UNIX_TIMESTAMP(NOW()) - last_action <= {$_SESSIONS_VARS['session_time']}";
      $_query=mysql_query($sql_query);
      $_result=mysql_fetch_row($_query);
    
      if ($_result[0] == 0) {
        //sessione inesistente...
        return FALSE;
      }
    
      /* a questo punto potresti voler controllare se l'utente magari e stat disabilitato in questo caso devi modificare la query di sopra e diventa cosi:
    
    
      $_querysql = "SELECT COUNT(id_sess) FROM sessioni AS s, users AS u WHERE id_sess={$s} AND UNIX_TIMESTAMP(NOW()) - last_action <= {$_SESSIONS_VARS['session_time']} AND s.id_user = u.id_user AND u.canlogin=1";
    
      qui canlogin è un tinyint unsigned dove ZERO indica che nn può accedere e UNO indica che può accedere.
      */
    
      // fatto questo devi aggiornare la last_action per evitare che la sessione scada anche se l'user lavora
    
      $_querysql = "UPDATE sessions SET last_action = UNIX_TIMESTAMP(NOW()) WHERE id_sess = {$s};";
      mysql_query($_querysql);
    
      return TRUE;
    }
    ok questo è il codice x il check molto semplice...veloce ma moltoooo efficace :P

    mmm che mi rimane da dirti??? bhe penso di aver detto tutto
    ah si...la Garbage Collecion l'ho inclusa nel DELETE che viene eseguito durante il login, cosi eviti di eseguire la query di GB sempre...tanto viene eseguita una volta ogni tanto ^_^

    ok

    adesso l'array $_SESSIONS_VARS deve essere cosi

    $_SESSIONS_VARS = array ( "session_time" => 300, "gc_time" => 900);

    ovviamente tutto in secondi. in questo modo la sessione scade dopo 5 minuti mentre la garbage collection avviene ogni 15. Se vuoi un consiglio personale la GC_TIME falla sempre superiore alla SESSION_TIME

    ah inoltre usando le sessioni nel DB hai 1 vantaggio notevole!!!

    1) Vuoi buttare fuori qualcuno? basta eliminargli la sessione!!!
    2) Vuoi vedere chi è loggato? cosa sta facendo? dov'è? e quando ha fatto l'ultima operazione? hai tutto nella tabella sessions!
    3) Sicurezza? bhe x prendere le info delle sessioni devono bucarti MySQL cosa...che si nota sicuramente

    bhe cosa dirti...io almeno fare cosi

    ciapzzzz :P

    e buona fortuna con le sessioni!

    PS: se il codice nn va dimmelo xche nn l'ho provato...controlla i ; magari me ne sono scordati :P
    PS2: se nn ti va tutto a prima botta nn ti arrendere...xche le sessioni su DB sono moltooooooooo meglio di quelle su file :P
    PS3: nn ti preoccupare di appesantire MySQL...neanche se ne accorge che stai eseguendo le query...a me impiega 0.006 secondi per gestirmi le sessioni ^_^ quindi sei al sicuro, basta fare le query in maniera inteliggente ed ottimizzarle!!!!!!! :P

    ciapzzzzzzzzzzzzzzzzz

  5. #5
    Utente di HTML.it L'avatar di blukarma
    Registrato dal
    Aug 2002
    Messaggi
    1,186


    mo me lo studio un pochino...

    ...tanto sai già che ti ridisturberò vero?

    tenchiu
    "viva la mucca, che dio la beneducca"
    (Diego Abatantuono - Eccezziunale... Veramente - 1982)

  6. #6
    Utente di HTML.it L'avatar di blukarma
    Registrato dal
    Aug 2002
    Messaggi
    1,186
    grazie mi leggo anche quello
    "viva la mucca, che dio la beneducca"
    (Diego Abatantuono - Eccezziunale... Veramente - 1982)

  7. #7
    vista la classe ma in questo modo le sessioni sono su filesystem...e come dicevo prima uno può fare mambassa...

    secondo me, e lo continuo a ripetere, le sessioni su filesystem sono le + pericolose...ti faccio 1 esempio

    tu hai 1 che ti vuole bucare il sito
    bene allora fa un whois, vede chi è il tuo hoster, si registra da lui pagando i 50€ all'anno (che nn sono nulla) un tonto script php si legge i vari file di sessioni (di solito stanno dentro /tmp) se li copia in blocco...tramite 1 classe se li zippa (c'è ne sono a bizeffe) e lui li ha i dati che poi ci stia 1 giorno, 1 minuto o 1 mese a decrittarli a i dati e può entrare...

    mmm cmq se vuoi un consiglio nella classe metti che ti salva la pass nella sessione e falla controllare ogni volta...senno uno si scarica il file...cambia il timestamp e può reutilizzare la sessione a vita senza avere problemi...essendo anche la sessione di admin su filesystem...se le scarica mentre l'admin è dentro...buona notte...è finita

    almeno questo è il mio consiglio...poi nn zo...vedi tu

    le sessioni su HD sono facili, ma pericolose...

  8. #8
    una volta che tu hai autenticato l'utente
    puoi scrivere questo(naturalmente prima devi aver fatt o partire una sessione):

    $_SESSION['logged']=1;


    in ogni pagina protetta vai a controllare se la variabile di sessione $_SESSION['logged'] è uguale ad 1 se non lo è non dai accesso.

  9. #9
    sono sul filesystem... ma non necessariamente le tieni in /tmp
    puoi fare un set_ini per il path dove salvi le sessioni
    anche perche' (speciamlemnte se sei in hosting) non mi pare il caso di mettere le sessioni tutti nello stesso posto... questo vale ancora di piu' se hai un cluster di macchine (dove la /tmp e' accessibile dalla singola macchina e quindi potresti perdere la sessione navigando)

    ad ogni modo tutte le tue obiezioni sono piu' che legittime, e utilissime per trovare soluzioni di sicurezza sul sistema;

    ho anche una classe simile che pero' non usa le sessione del php ma (con lo stesso sistema) se le salva sul db, questa oltre ad essere piu' lenta scrive comunque nel filesystem (nei files del db) che sono accessibili con lo stesso metodo che dicevi (spesso in /usr/local/mysql/data), se poi c'e' phpmyadmin allora e' veramente una pacchia

  10. #10
    Originariamente inviato da lenna
    sono sul filesystem... ma non necessariamente le tieni in /tmp
    puoi fare un set_ini per il path dove salvi le sessioni
    anche perche' (speciamlemnte se sei in hosting) non mi pare il caso di mettere le sessioni tutti nello stesso posto... questo vale ancora di piu' se hai un cluster di macchine (dove la /tmp e' accessibile dalla singola macchina e quindi potresti perdere la sessione navigando)

    ad ogni modo tutte le tue obiezioni sono piu' che legittime, e utilissime per trovare soluzioni di sicurezza sul sistema;

    ho anche una classe simile che pero' non usa le sessione del php ma (con lo stesso sistema) se le salva sul db, questa oltre ad essere piu' lenta scrive comunque nel filesystem (nei files del db) che sono accessibili con lo stesso metodo che dicevi (spesso in /usr/local/mysql/data), se poi c'e' phpmyadmin allora e' veramente una pacchia
    hum

    1) su un server web che nn è tuo nn puoi impostare la path...e "forse" la puoi leggere direttamente usando ini_get. e' vero nn sempre /tmp ma cmq stanno tutte insieme nella stessa dir

    2) confermo...nn è una bella idea usare le sessioni su macchine in hosting ^_^

    3) uhm...vorrei farti notare ad esempio il forum di HTML.it ti sembra lento? eppure usa MySQL + PHP e fa una cosa come un migliaio di richieste al secondo...(qui ci vorrebbe il grande saibal... :P)

    4) --> /usr/local/mysql/data è vero...ma su un sistema linux\unix mentre le sessioni devono essere dell'utente di APACHE x essere modificate da PHP, i file di mysql devono essere accessibili SOLO a MySQL...nessuno hoster su linuz da la possibilità di modificarli...neanche di leggerli...servono solo a mysql, quindi questo rischio neanchè c'è ^_^

    5) Con phpmyadmin è una pacchia si...ma solo se hai le pass...ma in quel caso devi bucare mysql...e nn è cosi lineare...soprattutto se usi un bruteforcing...se ne accorgono ... :P

    well

    ciapzzz

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.