Cómo implementar un límite de "intentos de acceso"

[dec]

Hola,

Antes de nada, te agradezco el interés Román, doblemente, por la posible solución. Digo posible, porque, aunque todavía no lo he probado tal como dices, me entran dudas sobre el uso de las sesiones, puesto que es lo que había intentado anteriormente. ¿No se supone que las variables de sesión son únicas para cada sesión? Pero, si el "script" cambia dicha variable de sesión... ¿no estamos como al principio? Pero, igual es que no he leído bien tus mensajes Román.

Echaré un vistazo, haré las pruebas oportunas, y comentaré aquí los resultados. Gracias de nuevo Román.

[roman]

Empezado por dec

Pero, si el "script" cambia dicha variable de sesión... ¿no estamos como al principio?

No podemos evitar que nos cambien la sesión. El punto aquí es que si lo hacen, nosotros lo detectamos y los mandamos a volar. Dicho de otra forma, la única manera de que puedan autenticarse en nuestro sistema es no cambiando la sesión, con lo cual tenemos un ambiente controlado.

Olvídate un poco de los tokens (son útiles pero no se requiere tanto) y fíjate en el ejemplo que puse:

1. Es imposible llamar directamente a login.php pues no habrá ninguna sesión y por tanto ninguna variable $_SESSION['intentos']

2. Esta variable se establece en login-form.php

3. Si en el paso de login-form.php a login.php cambia el ID de sesión, entonces login.php ya no reconocerá la variable intentos.

1 y 3 vienen a ser lo mismo. El caso es que ni siquiera se llega a verificar usuario y contraseña, y por tanto el atacante no tiene forma de decidir si eran datos correctos o no.

// Saludos

[dec]

Hola,

Bueno. Ahora mismo lo que más me llama la atención, es que, en el caso de Gesbit, existe un "user-login.php", donde se realiza la autenticación. No hay dos "scripts", sino uno solamente. Pero, perdona que insista Román (porque igual lo de los "tokens" resulte más conveniente), precisamente, porque no contamos con una sesión "estable", es que no podemos basarnos en ella para este caso.

1º Establezco la variable de sesión "contador"

2º Reviso si existe la variable contador (para incrementarla, si es preciso) ¡Error!

No existe la variable "contador"... no se ha establecido para la sesión "actual"... porque el "script" (Snoopy) siempre juega con una nueva sesión, la variable "contador" ya no existe..., dicho de otro modo, siempre estaríamos estableciendo una variable "contador", pero, no podríamos incrementar esa misma variable contador: de ahí la necesidad de usar una base de datos... para hacer persistir sí o sí esa información, para desligarla de la sesión de usuario.

¿No?

[roman]

Por un sólo script, me imagino que te refieres a que el mismo presenta el formulario y el mismo procesa los datos. Pero aún así son dos scripts distintos: el mismo a dos tiempos.

Sería algo así:

user-login.php

Código PHP:

<?php
session_start();

if ($_SERVER['REQUEST_METHOD'] == 'POST')
{
    // Aquí el "segundo" script

    if (!isset($_SESSION['intentos']))
    {
      die('Petición no válida');
    }

    /*
      Verificamos los datos de inicio
    */

    ...

    /*
      Si son incorrectos, marcamos un intento más
    */

    $_SESSION['intentos']++;

    /*
      Y lo mandamos a volar si ya rebasó el máximo permitido
    */
    if ($_SESSION['intentos'] > 3)
    {
      die('Demasiados intentos');
    }

    exit;
}

$_SESSION['intentos'] = 0;
?>
<form method='post' action='login.php'>
    <div>
        <label for='user'>User</label>
        <input type='text' name='user' id='user'>
    </div>

    <div>
        <label for='password'>Pwd</label>
        <input type='text' name='password' id='password'>
    </div>

    <div>
        <input type='submit'>
    </div>
</form>

Empezado por dec

2º Reviso si existe la variable contador (para incrementarla, si es preciso) ¡Error!

¡Exacto! Ése es el punto. Si no existe la variable contador, es un error. No es que haya que volverla a inicializar, es un error y le mandamos el

Código PHP:

die('Petición no válida'); 


La única forma en que no se dé ese error es teniendo definida esa variable de sesión y eso lo hacemos al presentar el formulario. Si el listillo nos cambia la sesión pues el afectado es él porqué recibira el error.

// Saludos

[dec]

Hola,

A ver, que, quiero cogerle el punto (atentos argentinos queridos, cogerle el punto aquí significa lo que significa, ¡y nada más!).

Empezado por Román

La única forma en que no se dé ese error es teniendo definida esa variable de sesión y eso lo hacemos al presentar el formulario. Si el listillo nos cambia la sesión pues el afectado es él porqué recibira el error.

Hum... o sea, tratar de aprovechar, precisamente, que no se puede mantener la sesión en condiciones. Pero, ¿esto cómo lo hacemos? Pongámonos en el caso.

El "script" (Snoopy) enviará, directamente, el formulario. Luego siempre estaremos "como en un principio". Siempre será "la primera vez" que se trata de envíar nuestro formulario. Si establecemos una variable de sesión ahí, de nada nos serviría, porque, no la tendríamos a nuestra disposición la siguiente vez. Pero, no sabríamos si es que es la siguiente vez (después de haberla establecido) o no, porque, como el "script" inicia una sesión nueva cada vez... siempre será como la primera vez (argentinos, que os veo con el cachondeíto).

No termino de verlo claro Román. El "script" (Snoopy) no quiere entrar en nuestro sistema, sólo quiere saber si el formulario se procesa bien o mal, si consigue autenticarse con unos datos de usuario, o no lo consigue. No es posible que mantenga (de hecho, ni querrá hacerlo) una sesión de usuario, luego nosotros no podemos basarnos en sesiones de usuario... simplemente es que no podemos... yo lo ví tan claro (que podía hacerse) que hasta me precipité en implementarlo, pero, en cuanto probé con Snoopy... caí en la cuenta de que no podía basarse algo así en variables de sesión: porque no podemos contar con una sesión de usuario.

[dec]

¿Te convenciste?

[roman]

Haz la prueba David, no me digas nada más que no se puede. Sigue el flujo de lo que pasaría con el tal snoopy intentando acceder (#$@&%! perro, ¡cómo da lata! )

Caso A) Snoopy intenta acceder directamente a login.php. No importa si es la primera vez o la chorrocientas. Como el condenado perro cambia la sesión, para login.php será como si fuera la primera vez. Por tanto le da una patada.

Caso B) Snoopy intenta acceder primero a login-form.php. Ahí se establece la sesión, pero, como el condenado perro la cambia, al acceder a login.php estamos como en el caso (a) y le damos una patada.

La única posibilidad que tiene el animal, es preservando la sesión.

pd: Las patadas al perro son simuladas. En el desarrollo de este código no se ha lastimado a ningún cachorrito .

// Saludos

[dec]

Hola,

Jodó con el perrito.

¡Pero no digas que no lo probé! Inicié este mismo hilo porque lo había probado y, para mi sorpresa, no funcionaba...

Empezado por Román

Caso A) Snoopy intenta acceder directamente a login.php. No importa si es la primera vez o la chorrocientas. Como el condenado perro cambia la sesión, para login.php será como si fuera la primera vez. Por tanto le da una patada.

El punto está en que "Como el condenado perro cambia la sesión, para login.php será como si fuera la primera vez". No es que el condenado chucho cambie la sesión, sino que no la inicia nunca, o, dicho de otra forma (pero igual resultado), siempre inicia una nueva. Y no podemos darle la patada a alguien que llega por primera vez a nuestro sitio... ¡ni aunque sea un chucho, que los hay podencos!

Empezado por Román

Caso B) Snoopy intenta acceder primero a login-form.php. Ahí se establece la sesión, pero, como el condenado perro la cambia, al acceder a login.php estamos como en el caso (a) y le damos una patada.

En el caso de Gesbit existe un formulario, un "script", que, junto con la clase GbUser (y GbDb, entre otras, pero, es otra historia) se encargan de la autenticación del usuario. Pero, a todos los efectos, es como si fuera un solo "script". Creo que esto puede confundirte Román.

En efecto, si hubiese que pasar por dos "script", incluso si hubiera que pasar por el mismo, dos veces, el asunto pintaría de otra forma, podríamos usar la sesión de usuario, y, en caso de no encontrarla en el segundo "script", denegar el acceso al can. Esto sería una solución ideal, acaso, pero, recuerda que el perrito rellena y envía el formulario en un mismo punto.

No ha de pasar por dos lugares, por tanto, no puede usarse el primero para establecer la variable de sesión que comprobar en el segundo. En realidad sólo ha de pasar por un lugar. Y podemos establecer la variable de sesión que queramos, porque, como cuando vuelva a pasar, lo hará con otra sesión de usuario diferente, dicha variable no existirá, no podremos usarla, no nos servirá de nada.

Ya digo. vBulletin lo implementa apoyándose en la base de datos. PhpBB ni siquiera lo implementa... si pudiera hacerse usando sesiones de usuario, de alguna manera, sería bastante sencillo de implementar, y, sin embargo, no se hace, porque no funciona. Funciona para personas, pero, con los cánidos parece que no pueden usarse sesiones de usuario, al menos no para lo que nos ocupa ahora.