Sobre Logins seguros

[cnavast]

Hola, estoy haciendo un login y normalmente siempre suelo hacer patatas del tipo pedir el usuario y la contraseña y el login básicamente es:
$user = $_POST["user"]; $pwd = $_POST["pwd"];
$query = "SELECT * FROM users WHERE user = '$user' AND pwd = '$pwd'";
$n = mysql_num_rows(mysql_query($query));
if($n == 1) {
//it's ok.
}

Y esto lo hago porque normalmente las páginas en las que trabajo sé que no van a ser atacadas.
El caso es que ahora estoy con una un poco más grande, y creo que ya es hora de aprender a hacer logins algo más serios. Y me han surgido algunas dudas.

1.- ¿Las SESIONES son modificables de alguna forma por el usuario? Es decir, si yo creo una sesión $_SESSION["user_id"] con la id. del usuario, ¿luego el usuario puede de alguna forma modificar el contenido de esta sesión con cualquier otra ID?

2.- Las sesiones pueden crear conflictos con otras webs? Es decir, si una Web utiliza la sesión "user_id" y yo también, ¿habrá problemas?

3.- ¿Qué información se ha de guardar en sesiones para logins seguros? ¿Con la ID ya vale, o mejor algo más (u otra cosa)?

4.- ¿Cuál es la mejor protección contra el SQL Injection? ¿Basta con filtrar los campos "quitando" caracteres raros?

5.- Me gustaría integrar el sistema de Login con Facebook, más o menos al igual que Forosdelweb, ¿requiere eso campos adicionales en la base de datos o algún tipo de seguridad aparte? ¿Cuál es la mejor forma de hacer esto?

Responded a las que queráis.

Muchas gracias!

[repara2]

http://blog.antioroku.com/archivo/69
http://www.forosdelweb.com/f18/segur...io-php-507174/
Salu2

[IEKK]

Bueno estos son mis consejos:

Podrías utilizar algunas funciones como p.e:

md5()
mysql_real_escape_string()
strip_tags()
stripslashes()
y validar tambien con expresiones regulares.

En los or die() de las consultas no pongas al subir la web el mysqlerror ya que provocando un error se consigue el nombre de lso campos y tablas.

Las sessiones... Bueno si en vez de poner cientos de ellas por cada campo sólo guardas la id del usuario es preferible. Si quieres obtener de nuevo esos datos te basta con hacer la consulta teniendo ya su id.

[vgonga1986]

$pwd = $_POST["pwd"];
AND pwd = '$pwd'" !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Lo pimero que te recomiendo es que metas algún cifrado para las paswords en la base de datos, eso de meter a pelo las contraseñas es un pelín inseguro. Mírate alguna función hash, md5... Hay muchas.

En cuanto a las sessions, otra buena idea es no poner nombres de campos triviales. Yo lo que suelo hacer es montar una pequeña función que devuelva una cadena aleatoria de números y letras, que asigno a cada usuario. A la hora de crear campos de sesión hago:
$_SESSION[getCadena() . '_id'] = $id;

De esta forma, getCadena() va a devolver siempre para el mismo usuario la misma cadena (sino, no podrías acceder al campo después), pero el nombre no queda trivial, sino que sería algo del tipo A67QWBQF97ASBDFQ9WEBFAS351_id, con lo que añades seguridad ante ataques por SESSION.

Un saludo.

[cnavast]

¡Hola! Gracias a los tres por contestar.

@vgonga1986: ¿Cuáles son los ataques por sesiones? Cuando escribí el mensaje pensaba que las sesiones eran un poco en plan cookies, vamos, que se guardan en el cliente, pero luego he leído que son server-side, por lo que lo que preguntaba en 1 y 2 queda resuelto. Pero si ahora me dices que existen ataques por sesiones, me vuelve a entrar la duda.

Y ya que estamos, ¿cómo sería la función getCadena()? Digo, en base a qué te va a devolver una cadena diferente por cada usuario, si precisamente no sabes qué usuario es? Si fuera la función getCadena($id), y luego en la función codificas por ejemplo md5("hola".$id), entonces vale, pero claro esto ya es sabiendo la ID del usuario que es lo que se supone que no sabes... :S ¿cómo lo haces? ¿por IP?

Lo del MD5 ya lo conocía y sí que suelo encriptar las contraseñas, pero aún así me da la sensación que eso es todavía poca seguridad (hay sistemas de login realmente largos, y comparados con el mío de 5 líneas...)

@repara2: El primer link que me has pasado está bien (me ha servido) pero sirve para proteger datos de formularios una vez la sesión ya está iniciada, yo busco protección sobre el inicio de la sesión. Y el segundo link tampoco es lo que busco.

@IEKK: Ok, me informaré sobre esas funciones, aunque alguna ya la conocía. ¡Gracias! :)

[vgonga1986]

4. Predicción de credenciales/sesión
La predicción de credenciales/sesión es un método de secuestro o suplantación de un usuario del sitio web.

Lo del MD5 ya lo conocía y sí que suelo encriptar las contraseñas, pero aún así me da la sensación que eso es todavía poca seguridad (hay sistemas de login realmente largos, y comparados con el mío de 5 líneas...)

Da poca seguridad... depende de por donde lo mires. Si tienes las contraseñas almacenadas en texto plano (sin encryptar) y te acceden a la base de datos, voilà, tienen acceso a todos tus usuarios. Más que seguridad por la propia contraseña, aporta seguridad a la base de datos. Y, el segundo gran motivo de guardar las pass encryptadas, es que tú tampoco tienes por qué saberlas y si las guardas sin encryptar con un simple select sabrías la pass de cualquiera de tus usuarios (ética informática, amigo).

Un saludo.

[cnavast]

No, si eso está claro, yo las encripto en MD5, lo que digo es que aún así hay webs que además del md5 en su proceso de login tienen mucha más seguridad, y me gustaría saber cuál es, porque yo por mucho que piense solo se me ocurre encriptar en MD5 y filtrar lo obtenido por POST para que no se pueda hacer SQLInjection.

[jotaincubus]

He visto paginas que están utilizando captcha en el login para evitar robots. Talvez podría ser una forma de seguridad.

[IEKK]

Iniciado por vgonga1986

4. Predicción de credenciales/sesión
La predicción de credenciales/sesión es un método de secuestro o suplantación de un usuario del sitio web.
Un saludo.

Pero una Predicción de credenciales o suplantación requiere que se haya logueado.
Se supone que la session no empieza hasta que el usuario se loguea.
Si la seguridad del login es correcta y evita el SQLinjection este método no debería poder ser válido ya que le es imposible saber su id u otros datos (salvo que el usuario ya sepa los datos del otro) pero eso ya es otro tipo de vulnerabilidad xD.

[IEKK]

Iniciado por jotaincubus

He visto paginas que están utilizando captcha en el login para evitar robots. Talvez podría ser una forma de seguridad.

Bueno ni siquiera un capcha es 100% perfecto, aunque casi, pero sin duda ayuda, el problema es que muchas veces se le hace pesado al usuario tener que estar añadiendo aparte de su clave números y letras aleatorias en una imagen.

Sigo pensando que para un login lo mejor es evitar la inyección en SQL

[Nemutagk]

Puedes seguir los siguientes puntos:

1. Sanitizar las variables POST (Forzoso)
2. Verificar la procedencia de la petición POST via REFERER (ver nota final)
3. Incluir un captcha en el formulario
4. Usar sesiones

Con respecto al referer, puede ser un arma de dos filos, ya que no todos los navegadores lo definen, y en algunos casos puede ser modificado manualmente, pero no esta demás verificarlo.

Un comentario mas, en uno de las respuestas anteriores se habla de ataques a sesiones:

"De esta forma, getCadena() va a devolver siempre para el mismo usuario la misma cadena (sino, no podrías acceder al campo después), pero el nombre no queda trivial, sino que sería algo del tipo A67QWBQF97ASBDFQ9WEBFAS351_id, con lo que añades seguridad ante ataques por SESSION."

De ninguna forma podrás ser victima de un ataque por sesión, ya que toda la información permanece dentro del servidor, lo único que se crea fuera del servidor es la cookie en la que se almacena la PHPSESSID, pero esta no le sirve de nada al usuario final para intentar algún ataque, al final, si alguien vulnera tu sesión es que ah tenido acceso al servidor, y llegando a este punto, de nada sirve modificar/alterar/atacar las sesiones activas ya que tendrán acceso directo al contenido que deseen sustraer/modificar/borrar

[cnavast]

OK! Gracias por contestar! Lo del captcha por ahora no lo haré, porque imagino que eso es para evitar fuerza bruta y que alguien consiga la contraseña de otro, ¿no? Yo por ahora me voy a centrar en evitar injections y cosas en ese plan.
Entonces, ya en definitiva, debería de:
1) Filtrar lo que llega por $_POST quitando cosas raras
2) Comprobar que el REFERER es la página del Login*
3) Iniciar una $_SESSION*

Duda sobre el 2: Me dices que algunos navegadores no lo definen, ¿significa esto que si yo hago if($referer!="mi_web") { /* ok */ } else { /* no ok*/ }, aquellos navegadores que no lo definen irán al else?

Duda sobre el 3: ¿Qué sesiones crearíais? ¿Una que guarde la ID del usuario y ya? Si es así, ¿luego en el resto de páginas sería seguro poner if($_SESSION["id"]) { /*ok*/ } else { /*no ok*/ } para validar?

Gracias de nuevo.

[vgonga1986]

A tu duda sobre el 3, creo que no has entendido del todo el tema de sesiones, no es que tú crees una sesión para guardar cada dato, creas una sesión por usuario y guardas ahí lo que tú consideres. Yo suelo guardar dos datos, id y user_type. Es verdad que con una buena configuración, lo suyo es guardar sólo el id y realizar consultas para cualquier otro dato que se quiera, pero como el user_type lo utilizo continuamente, para comprobar permisos de usuario, para cerrar páginas a unos y otros... me parece más cómodo guardarlo en la sesión también, así tengo acceso directo, sin tener que hacer consulta.

Al final todo depende de gustos y formas de ver las cosas, siempre y cuando no descuides la seguridad, da igual que guardes más o menos cosas en session.

Un saludo.

[cnavast]

@vgonga1986: Ok, perfecto. Ahora ya entiendo. Abres una sesión con el session_start(); y luego lo de $_SESSION["nombre"] es para ir almacenando datos dentro de esa sesión.

Bien, entonces ya solo queda la duda sobre REFERER.

Y si alguien quiere comentar algo sobre los logins usando Facebook también es bienvenido :P aunque por ahora me voy a centrar en lo otro.

¡Gracias a todos!

[Nemutagk]

"Duda sobre el 2: Me dices que algunos navegadores no lo definen, ¿significa esto que si yo hago if($referer!="mi_web") { /* ok */ } else { /* no ok*/ }, aquellos navegadores que no lo definen irán al else?"

No, en este caso tendrías que arriesgarte a tomar dicha petición como legitima, recordemos que no todos los usuarios usan los navegadores mas "famosos" y ni que hablar de navegadores para móviles, si tu metes los referer no definidos en el else puedes estarle negando el iniciar sesión a un usuario valido