Detectar si están habilitadas las cookies en el navegador

[halizia]

hola!

Quisiera saber si hay alguna manera de saber si el cliente tiene habilitadas las cookies en su navegador, ya que al registrarse parece que nadie lee la última linea del formulario de login: ¿Problemas al registrarse? Pulse aquí
Le voy a poner unas luces de neón o algo asi.

Bueno pues lo dicho, si me podeis ayudar a detectar la habilitación de las cookies.

Saludos!

[Ñuño Martínez]

No lo he hecho nunca con PHP, pero hace tiempo, con JavaScript, para comprobar si las huellas están activadas creaba una, le asignaba un valor y luego lo leía. Si devolvía error o vacío entonces es que no las tiene activadas.

Con PHP creo que no se puede hacer lo mismo. Mira en esta sección del manual PHP.

[dec]

Hola,

El tema está en que con PHP no podrás saber si una Cookie ha sido establecida o no en la primera "petición HTTP" del usuario. Pero la forma de comprobarlo pasa por lo que dice Ñuño: establecer un valor en una Cookie "de prueba" y, ya en una sucesiva petición HTTP, comprobar si el valor de la Cookie es el esperado: justo el que anteriormente estableciste.

Con JavaScript, sin embargo, parece que puede accederse al valor de una Cookie luego de crearla, y de este modo la comprobación puede realizarse "en el acto". No sé. Creo que es cuestión de darle unas cuantas vueltas. Si se trata de advertir al usuario de que debe aceptar Cookies creo que yo usaría JavaScript, directamente.

[halizia]

Gracias a los dos

con php veo que no me sale, cómo se haría con javascript?

Saludos!

[dec]

Hola,

No sé si algo tan aparentemente sencillo como la siguiente función podría bastar:

Código PHP:

function IsCookiesEnabled(){
  document.cookie = 'testcookie';
  var result = (document.cookie.indexOf('testcookie') != -1);
  document.cookie = 'testcookie; expires=Thu, 01-Jan-70 00:00:01 GMT';
  return result;
} 


Un ejemplo de uso:

Código PHP:

if(IsCookiesEnabled()){
  alert('Cookies disponibles');
}else{
  alert('Cookies NO disponibles');      
} 


Actualización: Parece que también puede usarse algo así:

Código PHP:

if(navigator.cookieEnabled){
  alert('Cookies disponibles');
}else{
  alert('Cookies NO disponibles');      
} 


* Resalto el código como PHP, pero, en realidad es JavaScript.

[semptrion]

NO uses cookies. Usa sesiones.

[dec]

Hola,

NO uses cookies. Usa sesiones.

Hombre,... eso es muy drástico, por lo menos. Las cookies, aunque hay cookies seguras, que yo nunca usé aún, no tienen porqué comprometer la seguridad, puesto que de guardar en ellas algo como una contraseña de usuario, por poner un ejemplo, lo haríamos desde luego cifrando los datos antes de guardarlos en la cookie.

Por otro lado, el uso de sesiones tiene una desventaja, y es su caducidad. Las cookies pueden durar años (que se lo pregunten a los chicos de Google que incluyen cookies que caducan dentro de 20 años por lo menos) y esto puede ser importante, no que duren 20 años, pero sí que duren algo más de lo que puede durar una sesión de usuario.

[[egostar]]

Empezado por dec

Por otro lado, el uso de sesiones tiene una desventaja, y es su caducidad. Las cookies pueden durar años (que se lo pregunten a los chicos de Google que incluyen cookies que caducan dentro de 20 años por lo menos) y esto puede ser importante, no que duren 20 años, pero sí que duren algo más de lo que puede durar una sesión de usuario.

Yo no se nada de el manejo de cookies, pero me apoyo en el comentario de nuestro amigo David, de hecho Club Delphi avisa cuando finalizas tu sesión esto:

Empezado por Club Delphi

All cookies cleared!

• Return to the page you were previously viewing
• Go to forums index

Me parece lo más adecuado.

Salud OS.

[semptrion]

Al cookies que vas a almacenar? la sesión de trabajo? la fecha de última conexión del usuario? el lugar de conexión? ha votado la última vez?

Dependiendo de la pregunta, la respuesta oscilará irremediablemente entre un problema de seguridad o de accesibilidad.

Si es para manejar sesiones, datos reservados, autenticación, validación, entonces estamos hablando de un serio problema de seguridad.

Y el problema no es que la cookie desaparezca una vez terminada la sesión, es que es una medida de seguridad implementada en el cliente!

Y tu sabes cual es el cliente que está usando la cookie que le diste?

Es realmente un browser? es realmente lo que dice ser?

Por otra parte, en el caso de que por políticas institucionales o del firewall organizacional no se puedan usar cookies, ese usuario será excluido del sistema?

Entonces se convierte en un problema de accesibilidad. Impedimos el acceso a los usuarios que no pueden o no quieren manejar cookies.

Y si el usuario no quiere que le coloquen cookies, actuamos como el Internet Explorer y no le consultamos y le obligamos a aceptarlas?

Yo uso mozilla y he configurado mi browser para que que no reciba cookies sin mi autorización. (Ahora hablo de la privacidad de los usuarios por si acaso.) Y cuando un sitio me pide permiso para colocar una cookie, me pongo muy curioso y juguetón.

Y más de una vez me he encontrado con sorpresitas.

Mejor leamos lo que dicen los que más saben del tema de las cookies y que las quieren como a sus propios hijos, pero... tampoco confían y esperan que se cambie y se limite el protocolo para las cookies.

http://www.cookiecentral.com/

En fin no hay mucha tela que cortar. Hay preceptos más sólidos que la simple facilidad o que "todo el mundo utiliza".

Esos son: seguridad y accesibilidad.

Saludos.

[dec]

Hola,

Pero todo es rebatible. Las cookies sirven para lo que sirven: mantener, precisamente, en el cliente, cierta información, que luego podremos recoger de ese mismo cliente para usarla en nuestra aplicación. Para eso sirven las cookies: para hacer persistente cierta información del usuario entre sesiones y sesiones de este en nuestra aplicación. Y parece ser que van bien y se utilizan en no pocas circunstancias y en muchos sitios y empresas Web "de prestigio".

En cuanto a la accesibilidad... bueno. Pero es que también existen los requisitos. Una aplicación puede usar cookies opcionalmente, o puede tener como requisito que estas estén disponibles. Es un requisito. El cliente ha de cumplir con este requisito para trabajar con la aplicación. No diré que se usen para todo, sin pensar en las consecuencias, pero, para ciertas cosas son muy útiles, desde luego, y si hay que hacer uso de ellas... hay que hacer uso de ellas.

Ahora bien, vamos con la seguridad de las cookies. ¿En qué comprometen la seguridad y de qué seguridad estamos hablando? Si una aplicación guarda en cookies los datos necesarios para autentificar a un usuario (para algo tan útil como no tener que "hacer login" cada vez que visitas ciertas páginas Web), lo que está claro es que la aplicación no debe guardar en las cookies datos del usuario en claro, si estos pueden resultar comprometedores.

Y ahí iba yo más arriba con lo de guardar en una cookie la contraseña de un usuario, por ejemplo, previo cifrado de la misma. ¿Qué tiene el cliente? El cliente (ojo, sea quien sea el cliente, siempre que acepte cookies) como mucho va a tener una cookie que contiene una "clave", por ejemplo una cadena alfanumérica resultado del cifrado de la contraseña del usuario. Se me hace complicado que de esa cadena alfanumérica se pueda obtener la contraseña del usuario...

¿Entonces en qué se compromete la seguridad con las cookies? Hombre, si un usuario visita una aplicación y esta le coloca en una cookie el número de la tarjeta de crédito del usuario (en "claro") y en otra cookie le coloca el número secreto de su cuenta corriente o qué sé yo (siempre en claro)... ¡no es que las cookies sean inseguras, es que se está haciendo un uso fatal de ellas! Pero no es culpa de las cookies, desde luego.

Ahora, lo mismo es que me estoy perdiendo algo... advierto que estoy dispuesto a aprender.

[semptrion]

El tema es que una cookie se puede copiar y reutilizar y preservar más allá de lo que el desarrollador quiere. Es decir, por ejemplo, creas una cookie de sesión para determinar la sesión del usuario conectado y así continuar con "el hilo" de la conexión.

Sin embargo, si el cliente no es un browser, no destruirá la cookie al terminar la sesión del browser, y podrá seguir utilizando la sesión para enmascarar al usuario. Resultado: rompieron tu seguridad en base a esa cadena cifrada ya que no necesitan descifrar lo que significa esa cadena, sólo se requiere la cadena para enviarla al servidor y hacerse pasar por el usuario previamente autenticado.

Copiar el archivo de una cookie no es tecnología de la NASA. Se puede hacer y se hace. En red mientras un usuario está conectado otro puede copiar su cookie y luego utilizarla.

Otra forma es enviar la cookie del usuario utilizando código html dinámico y javascript. Las puertas del infierno están abiertas y el que no lo sepamos no las cierra.

Así, vive feliz con las cookies, yo vivo feliz sin ellas.

[dec]

Hola,

A ver. No diré yo que no se puedan copiar cookies... pero también se puede (en teoría) copiar cualquier otro archivo de un ordenador... y no por eso hemos dejado de usar ordenadores. Pero sigo sin ver que las cookies comprometan la seguridad por sí mismas.

El que alguien pueda copiar las cookies que tú tienes en tu ordenador y las utilize para suplantar tu persona en una aplicación, ¿es problema de la aplicación o es tu problema? Yo aventuro que es problema tuyo y no de la aplicación. Y por otro lado la aplicación no se ha de ver comprometida...

Al fin y al cabo quien suplante tu persona en la aplicación tendrá como mucho tus "permisos" de usuario, pero, ni uno más. Y no sólo esto, sino que, para llevar a cabo ciertas tareas como usuario de la aplicación, por ejemplo darte de baja de la misma, la aplicación puede forzarte a autentificarte: borrando las cookies u obviándolas.

Yo no soy ningún experto en seguridad Web, ni muchísimo menos, empero, nadie podrá negar que las cookies son cosa muy utilizada, como he dicho más arriba, por sitios Web y empresas de las más prestigiosas. Debe ser que son muy útiles, porque de otro modo no me explico su utilización por tantos y tantos sitios en Internet.

E insisto: por sí solas las cookies no son buenas ni malas. Y sin son algo son buenas, puesto que se pensaron para suplir una necesidad, para ser útiles. ¿Que alguien puede aprovecharse de las cookies para hacer algo que hieda y no huela? Pues claro que sí, pero, con todo pasa igual: un cuchillo puede servir para cortar carne y para cortar carne también... no sé si me explico.

Otra cosa es que la aplicación pueda tomar ciertas medidas con el fin de evitar determinadas circunstancias. Ya he puesto un ejemplo: ¿que quieres de darte de baja como usuario? Pues no me bastan tus cookies, necesitas autentificarte de nuevo o de otro modo no te doy de baja. O tal vez la aplicación puede caducar las cookies cada cierto tiempo, y otras muchas más cosas que se me escapan porque como ya he dicho no soy ningún experto.

[semptrion]

El que muchos utilicen algo no significa que sea bueno. En realidad no significa nada. Si muchos sitios importantes usan cookies, hay que determinar en que aspectos lo usan.

Por ejemplo, para autenticación de usuarios que administran información financiera, no sólo NO usan cookies, sino que se deben colocar sistemas adicionales de seguridad que impidan que las usen.

Que hotmail.com por ejemplo utilice cookies no significa que el mundo entero está seguro. Vean por ejemplo este artículo de como hackear el hotmail (que me encantó por cierto el ingenio utilizado) http://www.net-force.nl/files/articles/hotmail_xss/

Ahora, el uso de cookies envenenados es una técnica conocida para hacerse pasar por un usuario (impersonalización o suplantación) que, dependiendo de los roles y los accesos que tenga el usuario podrían representar serios problemas para una aplicación (en cuanto a seguridad se refiere). Vemoas por ejemplo, http://www.windowsecurity.com/uplart...ningByline.pdf que explica una técnica para hacerlo.

La pregunta es, voy a utilizar la brecha de seguridad que emplean las cookies para rescatar el estado de cuentas de la carnicería de la esquina? o lo haré para rescatar las cuentas de Angelina Jolie?

Dependiendo de donde se encuentra el tesoro. Carne y carne .

Pero si me voy a hacer pasar por alguien, o si alguien se hará pasar por alguien no será para autodañarse, sino para lograr acceso, vía web, a lugares prohibidos o delicados.

[dec]

Hola,

Si me lo permites voy a hacerte una pregunta. Si, como dices, no es bien utilizar cookies, ¿qué se supone que hay que utilizar para hacer persistir determinada información entre clientes y servidores? ¿Qué solución propones al uso de las cookies? Porque es evidente que las cookies vinieron a cubrir un hueco, ahora bien, ¿cómo rellenamos ese hueco sin ellas? Habría que inventar algo. ¿Pero está ya inventado, aceptado y extendido como lo está el uso de las cookies?

No vale decir "no uses cookies en modo alguno", porque, como digo, no estoy diciendo que haya que usarlas en todo momento y sin ton ni son, sino cuando se hacen necesarias, para guardar información en el cliente que luego podamos recuperar desde el Servidor, entonces, puesto que esto puede resultar necesario en ocasiones, ¿qué se supone que hay que usar que no sean las cookies? ¿Acaso existe otra solución viable? No me extrañaría... por eso lo pregunto.

[semptrion]

Esta información la extraje del manual de php http://us2.php.net/session

Hay dos formas de propagar un "session id":

• Cookies
• Parámetro en la URL

El módulo de sesiones admite ambas formas. Las Cookies son la mejor opción, pero como no son fiables (los clientes no están obligados a aceptarlas), no podemos confiar en ellas. El segundo método incrusta el "session id" directamente en las URLs.
PHP es capaz de hacerlo de forma transparente al usuario cuando se compila con --enable-trans-sid. Si activa esta opción, las URIs relativas serán modificadas de forma que contengan el session id automáticamente. Alternativamente, puede usar la constante SID que está definida, si el cliente no envía la cookie adecuada. El SID puede tener la forma de nombre_de_sesion=session_id o ser una cadena vacía.

Otra forma de implmentar session tracking es mediante URL Rewriting. (Aunque hay quienes confunden url rewriting con enviar el id de sesión mediante GET, no es este el caso.) Esta técnica permite incorporar el id de session dentro el path (no del query como hace GET).

Por ejemplo, sea el número de sesión el 12333444555 y el recurso al que invocamos es http://www.example.com/test1.php.

Colocar en el query sería algo así como:
http://www.example.com/test1.php?ID_SESSION=12333444555

Colocar en el path sería:
http://www.example.com/12333444555/test1.php

(En el Apache, revisen el mod_rewrite para implementar esto.)

Los cookies son utilizados para almacenar información en el disco duro del cliente. Qué se puede colocar ahí? tenemos 4k por cookie de "cosas".

Eso depende de la iniciativa del desarrollador acerca de lo que se debe colocar ahí. Se puede colocar un identificador del usuario para ir mejorando sus preferencias en cuanto a navegación por un sitio. Por ejemplo, en un periódico, podemos registrar el tipo de noticias que ha navegado el cliente y luego dar una clasificación que permita al software, la siguiente vez que el usuario visite el sitio, las noticias de su elección.

Se puede, se puede, se pueden hacer muchas cosas. Pero no estar informados acerca de lo que existe es cometer un error severo que puede costar al contratante más que al usuario.

Por ejemplo, alguna vez entré a la Agencia Federal para el Manejo de Emergencias de los Estados Unidos y en la parte de Privacidad del Usuario y Aviso de Seguridad mienten descaradamente cuando dicen:

Empezado por http://www.fema.gov/spanish/help/privacy_spa.shtm

• Éste es el estado de la tecnología en Web. En la actualidad no existen aplicaciones que no usen cookies para esta función de pedidos múltiples.

Puede tener la absoluta seguridad de que el uso de la tecnología de cookies por parte de FEMA NO constituye un intento encubierto para recopilar o analizar información sobre usuarios de Internet.

Hay caramba! No creo que los técnicos de FEMA nos mientan descaradamente! Podrá ser que una institución seria como el FEMA se haya equivocado? Tan grande ! Tan estatal ! Tan técnica ! Se habrá equivocado? Les habrán hackeado la página para poner mentiras y hacerles quedar mal?

Aquí es donde las cosas se ponen viscozas. Cuando afirman que ES EL ESTADO DE LA TECNOLOGíA EN WEB cuando deberían decir (por verguenza deportiva al menos) ES EL ESTADO DE LA TECNOLOGíA EN WEB que conocemos.

Mensajes como éste han hecho que mucha gente piense que no existe nada más allá de los cookies. Y los que no los tienen o no los quieren: $@#!$. Así que, hay que usar nomás cookies sin ver lo que son o lo que hacen?.

Mucha de la tecnología de cookies está sustentada en mentiras (como la del FEMA) o en verdades a medias.

Hay algunas cosas buenas que hay que decir de los cookies: son seguros; son soportados por la mayoría de los browsers; no contagian virus ni los transportan(?); no son intrusivos y tampoco ocupan mucho espacio.

Entonces, quitando el tema de sesiones y seguridad, en qué se pueden utilizar cookies que:
- No viole la privacidad del usuario
- Si el usuario no quiere usarlos, no sea excluido

Hay todavía espacio para los cookies después de responder esa pregunta. Por ejemplo, en amazon.com, cuando un usuario visita una de sus páginas, son registradas sus preferencias, de tal manera que la siguiente vez que se conecta le muestran las novedades que, corresponden a sus preferencias. Pero, utilizar cookies para pedir la tarjeta de crédito del usuario? NUNCA!!! para eso existen el https y el uri rewrite. Finalmente, si el cliente no recibe cookies, no importa, no se perderá la conexión con un usuario por ello. Será tratado como un usuario nuevo y se le mostrarán las preferencias por defecto.

Empezado por dec

No vale decir "no uses cookies en modo alguno",

No uses cookies en modo alguno... para temas de seguridad. Para los demás temas, valdrá la pena esforzarse en usarlas?

Saludos