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

Discussione: Login a modo mio

  1. #1

    Login a modo mio

    Salve,

    Ho sviluppato un metodo per l'area riservata di un sito a modo mio e vorrei sapere può essere abbastanza efficace.

    Prima spiego che il concetto base è quello di creare un metodo simile a quello che viane fatto quando ad una persona, dopo la verifica dell'identità, si lascia un pass magnetico che gli permette di accedere liberamente all'interno di un complesso... ecc.

    Nel sito si accede all'area riservata tramite un solo file che verifica la correttezza dell'user e la password:

    Ad ogni tentativo viene rigenerata la variabile di sessione, non spiego il motivo per non scrivere troppo; dopo 30 tentativi sbagliati non si potrà più provare ad entrare perché bypasserà la verifica e darà sempre il risultato di user o password non corretti, almeno che non si chiude il browser e poi lo si riapre ecc..

    Una volta che il controllo dei dati di login corrispondono genera un record in una tebella separata da quella che contiene i dati per l'accesso all'area riservata e vi memorizza:

    - l'id di sessione
    - L'username
    - Il valore non criptato della password che ha autogenerato lo script (valida solo per la sessione)
    - l'ivello dell'amministratore e il suo id record della tabella per il login
    - Data inizio login in valore intero tramite time()

    Poi genero le variabili di sessione con user, password (valida solo per la sessione) e altre cose secondarie, che servono per navigare liberamente nell'area riservata dato che una volta fatto il login ad ogni pagina dovranno corrispondere all'interrogazione del database:
    - id di sessione che si utilizza
    - user e valore criptato della password memorizzata nella sessione.

    Poi cancella qualsiasi record della tabella che al valore data login tramite time() supera le 25 ore in modo da ripulirla da tutti i login precedenti esauriti e ai qualli non si è fato il logout; ad ogni operazione e cambio pagina nell'area riservata questa data viene sempre riaggiornata

    Inoltre tutto avviene nella stessa pagina form e controllo dei dati senza nessun redirectory; in caso di refresh che può rigenerare l'accesso ho messo un campo nascosto che si prende i valorimicrotime che poi verranno memorizzati in un campo della tabella login, e se questi sono uguali o inferiori bypassa il controllo e da esito negativo.

    Questi sono gli script:

    Codice PHP:
    // ----------------------------------->LOGIN

    if(!isset($_SESSION['username'])){$username trim($_POST['username']);}
    if(!isset(
    $_SESSION['password'])){$password trim($_POST['password']);}
    $login trim($_POST['login']);

    if(isset(
    $_POST['checkLogin'])){
     
    $checkLogin_X explode(' ',$_POST['checkLogin']);
     
    $checkLogin "id_microtime-( ".$checkLogin_X[2].$checkLogin_X[1]." )"; unset($checkLogin_X); 
    }

    if(
    $login && $username && $password && $admin_condition != "ACCESSO-VALIDO"){ 
     if(!isset(
    $_SESSION['admin_condition'])){
      
    $tentativi $_SESSION['tentativi'] + 1;
      
    session_regenerate_id();
      
    $_SESSION['tentativi'] = $tentativi;
     }

     if(
    $tentativi 30){
      
    $password crypt($passwordsubstr($password0,3));
      
    ereg('[a-zA-Z0-9àòèéùìç @\*\$\#\£\€\+\=_\-]{6,25}',$username,$posix);
      
    $username $posix[0]; 

      
    $query "SELECT * FROM `admin` WHERE id!='' and user='$username' and password ='$password' and note_php != '$checkLogin'";
      
    $res mysql_query($query); $num mysql_num_rows($res);
     }
     else{ 
    $num 0; }
     
     if(
    $num>0){
      
    $_SESSION['tentativi'] = 0;
      while(
    $riga mysql_fetch_array($res)){
       
    $data_admin $riga['data'];
       
    $id_admin $riga['id'];
       
    $livello_admin $riga['livello'];
       
    $sql_checkLogin $riga['note_php'];
      }

      
    // evita di rifare il login con un refresh o ritorno alla pagina...
      
    if(substr($sql_checkLogin,0,14) == 'id_microtime-('){
       if(
    $sql_checkLogin $checkLogin){$num =0;}
      }     
      if(
    $num>0){
       
    $query "UPDATE admin SET note_php = '".$checkLogin."' WHERE  id = '".$id_admin."'";
       
    $res mysql_query($query); $num mysql_affected_rows();
       
    // fine evita di rifare il ...
      
       
    $view_date explode('-'$data_admin);
       
    $data_admin $view_date[2]."/".$view_date[1]."/".$view_date[0];
       
    $loginPassword generatePassword();
       
    $password crypt($loginPasswordsubstr($loginPassword0,3));
       
       
    //---*
       
    $sec time(); $sec $sec-((60*60)*25);//25 ore
       
    $query "DELETE FROM `admin_login` WHERE (`id_admin` = '".$id_admin."' AND `last_update` < '".$sec."') OR `last_update` =''".
       
    " OR `last_update` IS NULL";
       
    mysql_query($query); 
       
    $num mysql_affected_rows();
       
    //---*

        
    $query "INSERT INTO `admin_login` (`id` , `id_session` , `password` , `id_admin` , `last_update` , `note` , `note_php`)".
        
    "VALUES (NULL , '".session_id()."' , '".$password."' , '".$id_admin."', '".time()."' , '".$livello_admin."' , NULL)";
        
    mysql_query($query);
        
    $num mysql_affected_rows();
        if(
    $num>0){
         
    $messages[] = "Login avvenuto con successo.";
         
    $admin_condition "ACCESSO-VALIDO"$_SESSION['admin_condition'] = $admin_condition//formula per attivare password.
         
    $_SESSION['username'] = $username;
         
    $_SESSION['password'] = $loginPassword;
         
    $_SESSION['id_admin'] = $id_admin;
         
    $_SESSION['data_admin'] = $data_admin;
        }
        else{
    $messages[] = " - Attenzione! Problema interno nella verifica del login. Contattare il webmaster.";}
      }
     }

    Poi in qualsiasi pagina:
    Codice PHP:
    //CONTROLLO PERMESSI ---------------------------------------->
    if(
     
    $admin_condition == "ACCESSO-VALIDO" &&
     IsSet(
    $_SESSION['username']) && 
     IsSet(
    $_SESSION['password']) &&
     IsSet(
    $_SESSION['data_admin']) &&
     IsSet(
    $_SESSION['id_admin']) 
     ){
     
    $db_password crypt($passwordsubstr($password0,3));
     
    $query "SELECT * FROM `admin_login` WHERE  password ='$db_password' and  id_admin='$id_admin' and id_session ='".
               
    session_id()."'";
    $res mysql_query($query); $num mysql_num_rows($res);
     if(
    $num>0){
      while(
    $riga mysql_fetch_array($res)){$livello_admin $riga['note'];}
      
    $queryPsw crypt($passwordsubstr($password0,3));
      
    $query "UPDATE admin_login SET last_update ='".time()."' WHERE  `id_session` = '".session_id().
      
    "' AND  `password` = '".$queryPsw."' AND `id_admin` = '".$id_admin."' ";
      
    $res mysql_query($query);
     }
     else {unset(
    $admin_condition); unset($_SESSION['admin_condition']);}
    }
    // fine controllo permessi. 
    Per il logout da qualsiasi pagina link a quella del login e:
    Codice PHP:
    //LOGOUT----------------------------------------------------->
    if($logout){
     if(
    $admin_condition && $db && $id_admin){
      
    $queryPsw crypt($passwordsubstr($password0,3));
      
    $query "DELETE FROM admin_login WHERE  `id_session` = '".session_id()."' AND  `password` = '".$queryPsw.
      
    "' AND `id_admin` = '".$id_admin."' ";
      
    $res mysql_query($query);
     }
     unset(
    $_SESSION['admin_condition']); 
     unset(
    $admin_condition$username$password$data_admin$id_admin);
     
    session_destroy(); // Distruzione dati sessione su disco server.
     
    $_SESSION = array(); // Distruzione Array super globale session.
     
    setcookie(session_name(), ''time() - 3600); // Cancellare i cookie di sessione.

    Il tallone di achille di questo sistema è che se si riescie ad intercettare la sessione si potrebbe accedere nell'area riservata con gli stessi permessi finché lasessione è valida.
    Esempio pratico: http://www.creazione-web.it/siti-esempio.php

  2. #2

    Re: Login a modo mio

    Originariamente inviato da Corvus
    dopo 30 tentativi sbagliati non si potrà più provare ad entrare perché bypasserà la verifica e darà sempre il risultato di user o password non corretti, almeno che non si chiude il browser e poi lo si riapre ecc..
    Un po' inutile visto che gli attacchi a forza bruta solitamente non mantengono le sessioni.

    Originariamente inviato da Corvus
    Una volta che il controllo dei dati di login corrispondono genera un record in una tebella separata da quella che contiene i dati per l'accesso all'area riservata e vi memorizza:

    - l'id di sessione
    - L'username
    - Il valore non criptato della password che ha autogenerato lo script (valida solo per la sessione)
    - l'ivello dell'amministratore e il suo id record della tabella per il login
    - Data inizio login in valore intero tramite time()

    Poi genero le variabili di sessione con user, password (valida solo per la sessione) e altre cose secondarie, che servono per navigare liberamente nell'area riservata dato che una volta fatto il login ad ogni pagina dovranno corrispondere all'interrogazione del database:
    - id di sessione che si utilizza
    - user e valore criptato della password memorizzata nella sessione.
    A che scopo fare tutta questa fatica? Che giovamento pensi di ottenere?

    Originariamente inviato da Corvus
    Inoltre tutto avviene nella stessa pagina form e controllo dei dati senza nessun redirectory; in caso di refresh che può rigenerare l'accesso ho messo un campo nascosto che si prende i valorimicrotime che poi verranno memorizzati in un campo della tabella login, e se questi sono uguali o inferiori bypassa il controllo e da esito negativo.
    Idem come sopra.

    Originariamente inviato da Corvus
    Il tallone di achille di questo sistema è che se si riescie ad intercettare la sessione si potrebbe accedere nell'area riservata con gli stessi permessi finché lasessione è valida.
    Se quello è il problema, ti basta salvare in sessione l'IP dell'utente, il suo user agent ed eventuali altri dati che si presume non cambino nell'arco della sessione e verificarli ad ogni richiesta di accesso "privilegiato".

    In ogni caso, tutto il lavoro che "hai aggiunto" al tipico sistema di login, ha ben poca utilità ai fini pratici e di sicurezza.

  3. #3
    Grazie, non mi aspettavo una risposta così celere:

    Per ...dopo 30 tentativi sbagliati non si potrà più provare ad entrare perché bypasserà la verifica e darà sempre il risultato di user o password non corretti, almeno che non si chiude il browser e poi lo si riapre ecc..

    pensavo fosse in grado di ingannare proprio i tentativi di intrusione tramite forza bruta, non capisco cosa intendi per "mantengono le sessioni", comunque la rigenerazione della sessione non centra con i tentativi di attacco tramite forza bruta.

    Quale soluzione conosci altrimenti?

    Per ...Una volta che il controllo dei dati di login corrispondono genera un record in una tebella separata da quella che contiene i dati per l'accesso all'area riservata e vi memorizza:

    - l'id di sessione
    - L'username
    - Il valore non criptato della password che ha autogenerato lo script (valida solo per la sessione)
    - l'ivello dell'amministratore e il suo id record della tabella per il login
    - Data inizio login in valore intero tramite time()

    Poi genero le variabili di sessione con user, password (valida solo per la sessione) e altre cose secondarie, che servono per navigare liberamente nell'area riservata dato che una volta fatto il login ad ogni pagina dovranno corrispondere all'interrogazione del database:
    - id di sessione che si utilizza
    - user e valore criptato della password memorizzata nella sessione.


    Serve a non far girare dati utili nelle variabili di sessione.

    Per ... Inoltre tutto avviene nella stessa pagina form e controllo dei dati senza nessun redirectory; in caso di refresh che può rigenerare l'accesso ho messo un campo nascosto che si prende i valorimicrotime che poi verranno memorizzati in un campo della tabella login, e se questi sono uguali o inferiori bypassa il controllo e da esito negativo...

    Non volevo fare nulla che fosse meglio di redirect, ma visto che ho voluto fare tutto nello stesso file era un accorgimento inevitabile, più che altro mi piacerebbe essere certo se ha lo stesso valore di sicurezza di redirect.

    Per
    ...Citazione:
    Originariamente inviato da Corvus
    Il tallone di achille di questo sistema è che se si riescie ad intercettare la sessione si potrebbe accedere nell'area riservata con gli stessi permessi finché lasessione è valida.

    Se quello è il problema, ti basta salvare in sessione l'IP dell'utente, il suo user agent ed eventuali altri dati che si presume non cambino nell'arco della sessione e verificarli ad ogni richiesta di accesso "privilegiato".


    Grazie molto del consiglio, anche se già lo sapevo, poi ritengo che è meglio non usare l'IP e magari basta anche solo user agent o meglio un valore criptato di user agent, ma quello volevo dire solo era uno dei "tallone di achile" del complesso.

  4. #4
    Originariamente inviato da Corvus
    pensavo fosse in grado di ingannare proprio i tentativi di intrusione tramite forza bruta, non capisco cosa intendi per "mantengono le sessioni", comunque la rigenerazione della sessione non centra con i tentativi di attacco tramite forza bruta.
    Hai scritto: almeno che non si chiude il browser e poi lo si riapre. Ovvero, a meno che NON venga propagata la sessione tra un tentativo e quello successivo, cioè quello che solitamente fa un attacco a forza bruta (oltre a simulare diversi user agent, IP tramite proxy, etc.).

    Originariamente inviato da Corvus
    Quale soluzione conosci altrimenti?
    Salvi nel DB i tentativi di login falliti, dopo 5 fallimenti consecutivi blocchi l'account, avverti l'amministratore ed informi l'utente che il suo account è stato bloccato.

    Originariamente inviato da Corvus
    Serve a non far girare dati utili nelle variabili di sessione.
    Per la gestione dell'autenticazione, di norma in sessione va salvato l'ID dell'utente ed eventualmente il ruolo che ricopre (a seconda del tipo di sistema implementato). Tutto il resto non ha molto senso a meno che non lo spieghi più nel dettaglio.

    Originariamente inviato da Corvus
    Non volevo fare nulla che fosse meglio di redirect, ma visto che ho voluto fare tutto nello stesso file era un accorgimento inevitabile, più che altro mi piacerebbe essere certo se ha lo stesso valore di sicurezza di redirect.
    Quello che hai scritto non ha molto senso. Se le sessioni si propagano, la sicurezza non ha molto a che fare con eventuali "redirect".

    Originariamente inviato da Corvus
    Grazie molto del consiglio, anche se già lo sapevo, poi ritengo che è meglio non usare l'IP e magari basta anche solo user agent o meglio un valore criptato di user agent, ma quello volevo dire solo era uno dei "tallone di achile" del complesso.
    Se l'attaccante è in grado di intercettare la sessione, allora sarà in grado di intercettare e riprodurre anche l'user agent. Ben diverso è l'IP che richiederebbe tecniche ben più avanzate (man in the middle, IP spoof, etc.).

    Perchè hai questa mania di inserire contenuti criptati in sessione?
    Se il server è configurato correttamente, i dati in sessione sono inaccessibili a meno di conoscere il sid ed essere in grado di bypassare i livelli di sicurezza aggiuntivi (IP, etc.).

  5. #5
    Allora, comunque quello che ho fatto per prevenire gli attacchi "brute force", deve per forza funzionare per quelli che ci provano con programmi che riescono solo a svolgere molto più velocemente il lavoro che altrimenti si farebbe con il solo uso della tastiera provando tutte le combinazioni possibilidi users e passwords, senza altri accorgimenti, quindi meglio di nulla è; per non parlare dei tentativi manuali dopo aver seguito fisicamente alla sequenza della digitazione dei tasti da parte di una seconda persona presente fisicamente.

    La soluzione consigliatomi non è funzionale nel mio caso perché poi dovrebbe bloccare tutti gli amministratori, e pensa che non è pratico bloccare l'area riservata ogni 5 tentativi, rischi di creare una possibilità di sabotaggio intesa ome ostruzionismo e fastidio ai danni dell'amministratore o amministratori del sito.

    Nota anche, che finché non ha azzeccato i dati non si sa con quale dati amministratore vuole entrare nel sito.

    Lo stesso per l'accorgimento per non fare il redirect, che poi non servono a nulla le sessioni, pensa che dopo aver fatto il login e poi dopo il logout, senza quell'accorgimento si può andare indietro nella storia delle pagine con la semplice freccetta del browser fino alla pagina in cui si è fatto il login e un bel refresh e chiunque l'ha fatto si ritrova loggato.

    Per...Serve a non far girare dati utili nelle variabili di sessione.
    Scusa volevo dire dati sensibili, utili ai maleintenzionati, che siano riusciti ad ottenere lID di sessione valido.

    Per la criptazione dei dati user agent sono d'accordo con la tua risposta, volevo dire che qualcuno potrebbe provare comunque dei valori comuni delle stringhe user agent finché non trova quello giusto è meglio usare qualche accorgimento in più....

    Per l'IP purtroppo numerosi grandi provider di servizi Internet hanno utenti che condividono indirizzi IP e nomi dell'host pubblici; i server proxy potrebbero causare la modifica di un indirizzo IP di un utente tra le singole richieste.

  6. #6
    Originariamente inviato da Corvus
    Allora, comunque quello che ho fatto per prevenire gli attacchi "brute force"
    Puntualizziamo, quello che hai fatto NON previene gli attacchi "brute force", proprio perchè utilizza solo le sessioni che, solitamente, gli attacchi "brute force" EVITANO di usare per evitare di essere bloccati.

    Originariamente inviato da Corvus
    La soluzione consigliatomi non è funzionale nel mio caso perché poi dovrebbe bloccare tutti gli amministratori, e pensa che non è pratico bloccare l'area riservata ogni 5 tentativi, rischi di creare una possibilità di sabotaggio intesa ome ostruzionismo e fastidio ai danni dell'amministratore o amministratori del sito.
    Esistono molti modi per evitarlo (blocco IP, whitelist su certi IP, validazione del blocco via email, etc.).

    Originariamente inviato da Corvus
    Nota anche, che finché non ha azzeccato i dati non si sa con quale dati amministratore vuole entrare nel sito.
    Non capisco cosa significa.

    Originariamente inviato da Corvus
    Lo stesso per l'accorgimento per non fare il redirect, che poi non servono a nulla le sessioni, pensa che dopo aver fatto il login e poi dopo il logout, senza quell'accorgimento si può andare indietro nella storia delle pagine con la semplice freccetta del browser fino alla pagina in cui si è fatto il login e un bel refresh e chiunque l'ha fatto si ritrova loggato.
    Si, certo, a meno di usare correttamente le sessioni e gli header per evitare, ad esempio, l'inserimento in cache, oppure usare una tecnica di one time password (sempre basata sulle sessioni) che permette il login a partire da una specifica form solo una volta, etc. E tutto questo può essere fatto ed implementato in piena sicurezza sia che si utilizzino "redirect" o no.

    Originariamente inviato da Corvus
    Scusa volevo dire dati sensibili, utili ai maleintenzionati, che siano riusciti ad ottenere lID di sessione valido.
    Di questo se ne è già discusso.

    Originariamente inviato da Corvus
    Per la criptazione dei dati user agent sono d'accordo con la tua risposta, volevo dire che qualcuno potrebbe provare comunque dei valori comuni delle stringhe user agent finché non trova quello giusto è meglio usare qualche accorgimento in più....
    Come ho già scritto, se l'attaccante dispone del SID è molto probabile che disponga anche dell'user agent etc. etc.

    Originariamente inviato da Corvus
    Per l'IP purtroppo numerosi grandi provider di servizi Internet hanno utenti che condividono indirizzi IP e nomi dell'host pubblici;
    Questo potrebbe ridurre la sicurezza nel caso in cui l'attaccante utilizzi lo stesso provider dell'utente attaccato, ma garantisce un livello più elevato della sicurezza in caso contrario.

    Originariamente inviato da Corvus
    i server proxy potrebbero causare la modifica di un indirizzo IP di un utente tra le singole richieste.
    Anche a questo vi è rimedio (es. analisi degli header, etc.) e comunque limita il problema ai soli utenti che accedono attraverso proxy in round robin, etc.

  7. #7
    Per ...Nota anche, che finché non ha azzeccato i dati non si sa con quale dati amministratore vuole entrare nel sito. ...

    Volevo dire che in un attacco brute force finché non si sono azzeccati usernamne e password non si sa con quali dati amministratore si vuole entrare nel sito e quindi non si può sapere a quale amministratore bloccare tutto dopo i 5 tentativi mancati, la paggina di accesso (login) è in comune a tutti i livelli di amministratore, perche nel sito c'è un solo file "admin.php"; per accedere nell'area riservata bisogna passare tutti per il form di quel file.

    <form action="admin.php" method="post" name="login" id="login">
    <table width="300" border="0" align="center">
    <tr>
    <td colspan="3"></td>
    </tr>
    <tr>
    <td>User:</td>
    <td></td>
    <td><input name="username" type="text" id="username" value="<?php echo $_GET['vsuser']; ?>" /></td>
    </tr>
    <tr>
    <td>Password:</td>
    <td></td>
    <td><input name="password" type="password" id="password" value="<?php echo $_GET['vspassword']; ?>" size="21" /></td>
    </tr>
    <tr>
    <td colspan="3">
    <div align="center">
    <input type="submit" name="login" value="Login" />

    <?php
    if($admin_condition != "ACCESSO-VALIDO"){
    echo "<input type=\"submit\" name=\"view_mailforgot\" id=\"view_mailforgot\" value=\" ? \" />";
    }
    ?>
    <input name="checkLogin" type="hidden" id="checkLogin" value="<?php
    echo "id_microtime-( ".substr(microtime(), 0, 21)." ) ";?>" />
    </div> </td>
    </tr>
    </table>
    </form>


    Per il resto ok è evidente che ne sai veramente tanto sull'argomento, adesso mi sembra di avere chiaro che il sistema di protezione dell'area riservata è sufficiente per quel genere di sito e quei accorgimenti in più che ho messo sono superflui e se non poco efficaci comunque inutili.

    Quindi a me va bene: bastava sapere solo se poteva essere efficace.

    Grazie mille per l'attenzione e il tempo dedicatomi, poi se come deterrente agli attacchi brute force mi vuoi dare qualche consiglio che non sia quello di bloccare l'user ma che segui efficacemente la strategia di eludere o ingannare come ho provato, grazie ancora.

  8. #8
    Originariamente inviato da Corvus
    Per ...Nota anche, che finché non ha azzeccato i dati non si sa con quale dati amministratore vuole entrare nel sito. ...

    Volevo dire che in un attacco brute force finché non si sono azzeccati usernamne e password non si sa con quali dati amministratore si vuole entrare nel sito e quindi non si può sapere a quale amministratore bloccare tutto dopo i 5 tentativi mancati, la paggina di accesso (login) è in comune a tutti i livelli di amministratore, perche nel sito c'è un solo file "admin.php"; per accedere nell'area riservata bisogna passare tutti per il form di quel file.
    Ad una coppia username/password DEVE corrispondere una singola utenza. NON ci possono essere più utenti con la stessa username. Detto ciò, un attacco brute force tenterà l'accesso su username che conosce o su username che ritiene esistano (root, admin, administrator, etc.).

    Per cui, a partire da un username, è sempre possibile risalire a quale utenza ha tentato il login ed agire di conseguenza (es. bloccare l'account). Poi, ovviamente, esistono molti altri metodi per evitare abusi (ban di IP, ban di determinati user agent, ban di utenti tramite open proxy, etc. etc.)

  9. #9
    Ok chiarito.

  10. #10
    Prescindendo dal fatto che quoto quanto detto da filippo.toso, ho deciso di inserirmi per capire meglio alcune cose dette.

    filippo che intendi esattamente con:
    Si, certo, a meno di usare correttamente le sessioni e gli header per evitare, ad esempio, l'inserimento in cache, oppure usare una tecnica di one time password (sempre basata sulle sessioni) che permette il login a partire da una specifica form solo una volta, etc. E tutto questo può essere fatto ed implementato in piena sicurezza sia che si utilizzino "redirect" o no.
    e con:

    Anche a questo vi è rimedio (es. analisi degli header, etc.) e comunque limita il problema ai soli utenti che accedono attraverso proxy in round robin, etc.
    Quindi con "evitare l'inserimento in cache", "tecnica di one time password" e "analisi degli header" ?

    Mi hai incuriosito.
    Administrator of NAMDesign.Net

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.