¿ Usar Cookies, Url ó Variables de sesión ?

[ma9488]

Saludos. Después de leer varios artículos me he quedado con lo siguiente:

COOKIES:
no todos los usuarios las aceptan
poco seguras (usuarios maliciosos podrían modificarlas)

URL:
poco estéticas
la cantidad de valores a pasar está limitado
¿ qué pasaría si un usuario malintencionado cambia algún valor de las variables y llama a la página ?

VARIABLES DE SESIÓN:
parece ser la única alternativa válida y segura
¿ pero cómo hago para pasar session_id() ?
¿ cómo envío una variable a otra página para discriminar un código u otro ?

En fín, ¿ qué es lo más seguro ?
¿ Obligar al usuario a habilitar las cookies ?
¿ Llenar la URL con variables de página a página ?
¿ Cómo evitar que un usuario modifique las variables de la URL ?

Estoy leyendo artículos de seguridad. Pero, a menudo, me producen más dudas aún.

Saludos a todos los phperos.

[jam1138]

Iniciado por ma9488

1. ¿ pero cómo hago para pasar session_id()?
2. ¿ cómo envío una variable a otra página para discriminar un código u otro ?
3. ¿ qué es lo más seguro ?
4. ¿ Obligar al usuario a habilitar las cookies ?
5. ¿ Llenar la URL con variables de página a página ?
6. ¿ Cómo evitar que un usuario modifique las variables de la URL ?

1) Aunque no debieras preocuparte en principio por ello, puedes asegurar la propagación del SID vía URL. FAQ.

2) Simplemente asignale un valor y recuperalo en el otro archivo; de eso se tratan las sesiones. FAQ.

1 y 2) FAQ.

3) Dentro de lo que planteas, Sesiones; los argumentos bien los entendiste y mencionaste.

4) No puedes.

5) Si quieres y se puede...

6) No puedes... ... quizá con JavaScript podrías abrir una ventana sin la barra de dirección . No corresponde a PHP.


No sé qué es lo que tengas en mente, pero no porque las variables vía URI estén visibles significa que no deban usarse; pueden simplificar bastante tu programación y por ende optimizar tu aplicación (todo esta en programar bien), ¿ó por qué grandes aplicaciones como foros y sitios completos las usan?? (mira arriba ). No porque las cookies puedan estar bloqueadas significa que no son un recurso importante, pueden simplificar la interacción entre aplicación y el usuario. No porque las sesiones sean "privadas" deban ocuparse siempre; su uso puede complicar la programación, además ocupan espacio... los datos que necesitan ser pasados por sesiones usualmente son los mínimos. Todo es relativo, nada es absoluto... todo depende de lo que quieras y necesites hacer.

Si tu pregunta es mera "curiosidad" sobre seguridad, creo ese tema tiene que empezar desde antes; desde el mismo servidor... de lo cuál no puedo hablar mucho pero hay un Foro de Seguridad y Redes... aunque no creo sea este el caso.

Un saludo!

[ma9488]

Gracias por tu paciencia Jam.

Creo que no me expliqué bien del todo.

1) Me refería a cómo pasar la SID de página a página sin usar cookies ni la url.
Me temo que sería imposible sin usar la URL.
Yo tengo configurado el paso automático de la SID. Funciona perfectamente menos cuando quiero redireccionar la página con <meta>. En este caso me veo obligado a hacerlo manualmente, con lo que la SID queda a la vista en el url.

2) Me refería a cómo pasar una variable a otra página sin usar cookies ni url.
Usando las sesiones tendría que llenarlas antes de pasar a otra página e inmediatamente después vaciarlas para que no se mezclen (si es que el usuario vuelve a abrir una nueva ventana de la misma página).

4) No puedo obligar al usuario a habilitar las cookies, pero sí se podría poner como requisito fundamental para poder acceder a los servicios de la página. (Aún así, me parece algo cutre esta opción).

5) Llenar la url con variables me parece la opción más sencilla, pero....
- ¿ no hay límite para pasar valores y valores y valores y valores.... ?
- si uso este método tendría que tener mucho cuidado si los usuarios los cambian, tendría que hacer código para saber si el valor es cierto o no... creo que es un gran agujero.
Por ejemplo, si llamo a la página.php?var=8 hace una cosa. Si me cambian al 9, hace otra. No puedo arriesgarme a que esto ocurra.

6) Si no puedo evitar que modifiquen las variables de url, entonces no me queda otro remedio que usar las variables de sesión. Crear las variables, llenarlas. Pasar de página. Leerlas y destruirlas. ¿ Seria eso no ?

Pues lo que tengo en mente es:
tengo una pagina1 (formulario)
pagina2 (recibo los datos del formulario)
los comprueba
CORRECTOS --> los graba
INCORRECTOS --> debe regresar a la pagina1 (formulario) pero necesito enviar los valores para que el usuario no tenga que escribir todo de nuevo, sino sólo modificar sobre lo que ya escribió en un principio.

Gracias por tu atención Jam.

[jam1138]

1) ... ... no tendría porque haber ese comportamiento... ¿no tienes un thread abierto con ese tema ??; si eres tú, se mencionó sería bueno mostrarás exáctamente lo que haces... si no eres tú... serían dos los casos , habria que investigarlo bien .

2) ... no entendí, pero los datos de las sesiones se guardan en el servidor. No empleas ni cookies ni la URI para pasarlos.

4) Claro... todo es cuestión de valuar las cosas: tanto para tí de qué tanto depender de las cookies como del usuario el ver sí le conviene aceptarlas (hablando con la realidad, son la minoria quienes las tienen desactivadas).

5) El límite es de 250-255 carácteres (mas menos, no recuerdo bien ).... el que represente un agujero de seguridad dependerá de los datos que pases y de tu programación. Puedes aceptar valores de "var" específicos, incluso restringir algunos ó como lo requieras. Puedes hacer que si el usuario cambia el valor de la variable te mande a una página específica (404, index...) si no se encuentra ese valor, esto no tiene por qué representar un problema para tí salvo quieras verdaderamente evitar esa manipulación por cuestiones de... ... .. ¿por qué? . El paso de vaores por URI se usa básicamente para consultas y asignarle valores que son obtenidos por JavaScript, nada extenso, nada "super secreto".

6) ... tendrás que hacer eso ó emplear JavaScript; con un botón/enlace que te regrese una página según el historial, esto conservará los datos del formulario.



Edito: Ahora entiendo el punto 2; sí, tendrías que destruirlas.
He probado el refresh y no tube problema: 1.php

Código PHP:

  <?php 
session_start(); 
echo "<a href=\"2.php\">Enlace</a><br>"; 
echo session_id(); // se conserva 
?>   

2.php

Código PHP:

  <?php 
session_start(); 
?> 
<html><head> 
<meta http-equiv="Refresh" content="5, 1.php"> 
</head><body> 
<?php 
echo session_id(); // se conserva 
?> 
</body></html>  

[ma9488]

Gracias Jam. Probaré de nuevo a ver si pasa la sid sin necesidad de hacerlo manualmente. Aunque me ha contestado Cluster que no lo hace automáticamente.
En cuanto tenga un rato libre lo miro.
Tengo otra duda, pero mejor la pongo en un tema nuevo. Gracias.

[Cluster]

1) .. Si usas por ejemplo formularios .. el SID se pasa como un campo oculto (hidden) añadido a tu formulario .. si a eso añades que usas POST como método nunca verías el SID por ningún lado (pero si que está viajando en esa variable y sería "scaneada" si examinas tus cabeceras HTTP que genera tu página).

2) .. No hay otra forma de propagar el SID .. El SID es tu "lazo" con el cliente que originó tu sesión .. de alguna forma hay que identificarlo y saber que está ahí vigente .. por eso existe el SID y como trabajamos bajo "cliente-servidor" .. ese dato ha de viajar de uno a otro sentido para que se "asocien" ..

4) Lo más seguro es propagar el SID en cookies .. Para nada es "cutre" si argumentas que es por su bien (de los usuarios) que permitan las cookies que genera tu sitio. Alguien que sea usuario de internet debe saber que cookies aceptar .. no denegar todo por qué "le dijeron" que toda cookie es con fines maliciosos!!!. Y si tu tienes tu sitio certificado, tu avisas de este hecho .. nadie debería cuestionar la aceptación de esa cookie.

5) Ya no es que quede "estéticamente" mejor o peor pasar un motón de variables .. o que exista un límite .. sino que si tu pasas algun valor de alguna variable "sensible" como por ejemplo el "Ususario" autentificado en tu sistema .. como veras es cómodamente alterable (mucho más que una cookie).

6) si ..


Un saludo,