¿Me podeis decir hasta que punto es seguro este sistema de login?

[miwelillo]

Buscando un poco por la red un sistema para autenticación de usuarios he encontrado he encontrado un ejemplo bastante fácil y completo en su implementación pero que no se hasta que punto puede ser seguro. Ya se que ningún sistema es seguro al 100% pero me gustaría saber si este al menos cumpliría su función ante los ataques mas comunes:

http://www.ineedtutorials.com/code/p...m-php-tutorial

La primera duda que me asalta es su manera de autenticar a los usuarios. Únicamente usa una función que comprueba 2 variables registradas mediante $_SESSION tal que así:

Código PHP:

  function isLoggedIn(){ 
    if($_SESSION['loginid'] == true && $_SESSION['username'] == true){ 
        return true; 
    } 
    else{ 
        return false; 
    } 
}  
   

y protege las paginas comprobando el valor que devuelve esta función, ¿podría un atacante registrar esas 2 variables manualmente y de esta manera, conociendo el userid y el username autenticarse en el sistema sin conocer la contraseña?

Ya de paso me gustaría abusar un poco de vuestra confianza y preguntaros que otros sistemas de login seguros conocéis ya que los que he visto son bastante simples y tampoco me atrevo a crear uno por mi mismo.

Un saludo!

[AlvaroG]

Para hacer un sistema seguro necesitas:

- no enviar al cliente más información que la necesaria
Las variables de sesión cumplen esto, ya que al cliente se le envía nada más un identificador. Ninguno de los demás datos almacenados en la sesión llega al cliente.

- no confiar nunca en los datos recibidos del usuario
siempre, siempre hay que filtrar lo que se recibe, y nunca se lo debe pasar a una consulta SQL sin filtrar.

- se debe revisar que la carpeta donde PHP crea los archivos de sesión sea escrita únicamente por los archivos de tu sitio web, en vez de que sea compartida, para evitar "envenenamiento de sesión". Lamentablemente no es algo que puedas manejar si tu plan de alojamiento no es dedicado, ya que es parte de la configuración de PHP.

- No propagar sesiones vía URL, a menos que se regenere el SESSID frecuentemente (en cada carga de página). Las cookies son más seguras en este sentido.

Creo que son las reglas básicas. El código que pusiste es seguro, siempre y cuando el resto del sistema lo sea (ese par de líneas son inútiles por si solas)


Saludos.

[VirtualWork]

Hola !!!

Tambien utiliza proteccion contra inyeccion sql. Php tiene una funcion para esto, no recuerdo en este momento su nombre. Tambien podrias verificar los valores de la session contra una base de datos.

La seguridad va hasta donde tu quieras, pero entre mas "trabas" coloques a los piratas, mejor.

[miwelillo]

Hola! muchas gracias por las respuestas. Lo de escapar los datos es algo que ya tengo en cuenta (ya estoy escarmentado de un pequeño XSS que me hicieron) y siempre uso funciones como mysql_real_escape_string(), htmlespecialchars() y stripslashes() para filtrar cualquier dato que envie el usuario.

Basicamente lo preguntaba porque el codigo que he puesto unicamente comprueba 2 valores que podrian ser facilmente modificables por un atacante aunque aun no tengo claro el nivel de dificultad que pueda entrañar (no se hasta que punto se puede falsear una variable creada por una sesion o una cookie).

Supongo que lo de no enviar mas datos de los necesarios os referis a no enviar por ejemplo la contraseña aunque esta venga cifrada con algun algoritmo ya que siempre existe forma de romperlos...es asi?

[AlvaroG]

Iniciado por miwelillo

(no se hasta que punto se puede falsear una variable creada por una sesion o una cookie).

No son la misma cosa. Una cookie es una cadena que se envía al usuario, y que por lo tanto puede ser modificada con cualquier valor.
Una sesión es un conjunto de datos que se guardan en el servidor, y que se corresponden a un usuario mediante un identificador de sesión.
Usando sesiones el usuario recibe solamente el identificador, no el resto de los datos. Esto resulta en que una variable vía cookie es muy simple de modificar, pero una variable de sesión es en la práctica imposible (con las precauciones que debe uno tomar al utilizar esa palabra) de modificar por un usuario: solamente podría jugar un poco con el ID de sesión, pero eso no le da acceso al resto de los datos. E incluso si "juega" demasiado, probablemente se encontrará con una sesión caducada por el servidor.
Es aquí donde entran las autentificaciones de dos factores: tu sistema puede comprobar si el usuario que inicia la sesión tiene siempre la misma IP, y en caso de que otra IP intente conectarse con el mismo ID de sesión, lo obligas a identificarse de nuevo. Tiene sus problemas, pero puede ser efectivo.

Iniciado por miwelillo

Supongo que lo de no enviar mas datos de los necesarios os referis a no enviar por ejemplo la contraseña aunque esta venga cifrada con algun algoritmo ya que siempre existe forma de romperlos...es asi?

Exacto. Usando sesiones solamente se le envía el ID de sesión, así que el problema se mitiga en cierta forma. Si te decantás por usar cookies, asegurate de estar enviando solamente datos sin importancia, y SIEMPRE valídalos. Ten en cuenta también que aunque tu usuario sea bienintencionado, al pasar datos sensibles vía cookies estás obligándolo a que sus datos viajen por servidores ajenos (el proxy de un cibercafé, por ejemplo, o algún troyano instalado en la máquina)

Con datos que vienen del usuario la regla de oro es asumir que son maliciosos.


Saludos.

[miwelillo]

Excelente explicacion AlvaroG, ahora ya me ha quedado mucho mas claro. Muchisimas gracias!!