Proteger login contra bruteforcers

Iniciado por pedrox@, 27 Febrero 2009, 00:22 AM

0 Miembros y 2 Visitantes están viendo este tema.

pedrox@

Hola buenas!

Bueno estaba haciendo un login para mi web con php, mysql.
Bueno por ejemplo:

Código (html4strict) [Seleccionar]

<form action="/index.php" method="post">
<p>
  <input type="text" name="usuario" value="Nombre usuario" onClick="this.value=''">
    </p>
<p><br>
      <input type="password" name="clave" value="Password" onClick="this.value=''">
  <br>
  <br>
      <input type="submit" name="enviar" value="Enviar">
 
    </p>
</form>


compruebo que si $_POST['enviar'] tiene valor, cogo $_POST['usuario'] y $_POST['clave'], envio la consulta a la db, si me devuelve algun resultado, creo una session, sino muestro el típico error.

Entonces cualquier persona malintencionada que vería el login de mi web, podría ver los nombres de los campos que uso para enviar el usuario, password (en el fuente html), el error que muestra al no hacer login, hacerse un pequeño script en perl o en lo que sea y enviar valores mediante peticiones POST a los campos hasta obtener usuario, password...

Soluciones??
pues sí, se podría usar captcha, una tabla en la db que guarde los logins fallidos por ip, si hace 3 o los que sea bloquee la ip y tal...

Alguien sabe hacerlo de otra forma y que sea seguro?

Un saludo y gracias de antemano...

[u]nsigned

Hola, bueno la solucoion mas facil es usar una imagen generada con php, como en el sistema de registro de cualquier foro o web.

imagen_anti_ataque.php


<?php
  $ancho
=100;
  
$alto=30;
  
$imagen=imageCreate($ancho,$alto);
  
$amarillo=ImageColorAllocate($imagen,255,255,0);
  
ImageFill($imagen,0,0,$amarillo);
  
$rojo=ImageColorAllocate($imagen,255,0,0);
  
$valoraleatorio=rand(100000,999999);
  
session_start();
  
$_SESSION['numeroaleatorio']=$valoraleatorio;
  
ImageString($imagen,5,25,5,$valoraleatorio,$rojo);
  for(
$c=0;$c<=5;$c++)
  {
    
$x1=rand(0,$ancho);
    
$y1=rand(0,$alto);
    
$x2=rand(0,$ancho);
    
$y2=rand(0,$alto);
    
ImageLine($imagen,$x1,$y1,$x2,$y2,$rojo);
  }
  
Header ("Content-type: image/jpeg");
  
ImageJPEG ($imagen);
  
ImageDestroy($imagen);
?>



Luego desde la pagina del formulario (debe ser en php no html plano) comprobas si el codigo ingresado por el usuario en el campo corresponde al de la imagen (almacenado en  $_SESSION['numeroaleatorio']).

Para insertar la imagen en una pagina:

<img src="imagen_anti_ataque.php" />

Cyaz

No hay atajo ante la duda, el misterio se hace aquí...
Se hace carne en cada uno, el misterio es existir!

pedrox@

Sí, captcha ya he usado. Pero es algo engorroso que los usuarios tengan que estar escribiendo letrillas. Me dijeron que con un input hidden se podría hacer, estuve haciendo pruebas y no consegui nada jeje.

Un saludo, gracias

HardieVon

yu lo as dicho, guarda la ip con muchos logins fallidos, no seria optimo tu sistema pero si seguro.

otra cosa seria con sesiones.

pedrox@

Si, lo del bloqueo IP ya lo hize para la administración  ;D
Quiero aprender más metodos para no tener que hacerlo en cualquier formulario...

Nose si alguien conoce lo que digo del <input type="hidden" value="algo aleatorio">
Si me pueden echar una mano, gracias!

Spider-Net

#5
Puedes crear una cookie que incremente su valor en cada logeo, si detectas un número alto de intentos de logeo fallidos entonces bloqueas la cuenta o baneas la ip o lo que sea. En caso de que el logeo sea correcto destruyes la cookie y ya está. Es un método...

Lo del campo oculto o (hidden) es sencillo. Creas un campo oculto en tu formulario de logeo con cualquier valor. Por ejemplo "ImPrEsCInDiBlE". Luego cuando envíes el formulario lo primero que tienes que hacer con los datos recibidos es comprobar si has recibido el contenido del campo oculto, si lo has recibido es que ha sido un logeo desde tu web, si no lo has recibido ha sido un script remoto.

El problema de este método es que es fácil de saltar, si usas un sniffer y capturas lo que envía el formulario o simplemente investigas el código fuente de tu página en busca de campos ocultos, aunque no se vean en el navegador, en el código fuente canta el: <input type="hidden"> así que no te lo recomiendo.

Saludos

[u]nsigned

Cita de: Spider-Net en 28 Febrero 2009, 00:23 AM
El problema de este método es que es fácil de saltar, si usas un sniffer y capturas lo que envía el formulario o simplemente investigas el código fuente de tu página en busca de campos ocultos, aunque no se vean en el navegador, en el código fuente canta el: <input type="hidden"> así que no te lo recomiendo.

Lo de sniffers es todo un tema, en cuanto a lo del campo hidden lo puedes crear con DHTML accediendo al DOM, y asi no aparecera en el codigo fuente de tu web. Pero si en el  archivo .js.

Para mi lo mas factibles es lo de captcha debido a que el control se realiza en el server, y no gasta recusos como usar una base de datos, en cuanto o lo de cookies y sessiones se pueden manejar desde el cliente, es decir que con solo re abrir el navegador se borra la session.

No hay atajo ante la duda, el misterio se hace aquí...
Se hace carne en cada uno, el misterio es existir!

HardieVon

lo mas viable es un campo oculto creado con una sesion por que lo de las cookies jajaja nada mas le dejas la cabecera congelada y es como si nada pasara.

Spider-Net

Obviamente cualquier cosa que funcione desde el lado del cliente se lo van a poder saltar. Pero eso no sólo pasa con las aplicaciones web. Cualquier programa que se encuentre de forma local en mi ordenador puedo acceder a sus variables en memoria y modificarlas a mi gusto.

La única solución segura es trabajar siempre del lado del servidor, con una base de datos o un fichero o lo que sea pero que el usuario no tenga acceso.

naderST

Cita de: Spider-Net en 28 Febrero 2009, 12:43 PM
Obviamente cualquier cosa que funcione desde el lado del cliente se lo van a poder saltar. Pero eso no sólo pasa con las aplicaciones web. Cualquier programa que se encuentre de forma local en mi ordenador puedo acceder a sus variables en memoria y modificarlas a mi gusto.

La única solución segura es trabajar siempre del lado del servidor, con una base de datos o un fichero o lo que sea pero que el usuario no tenga acceso.

Y tiene razon Spider-Net, amigo lo que te recomendaria seria usar una base de datos, todo lo que sea del lado del cliente sera "violable" por decirlo asi.