pasar variables entre paginas (sin GET)

[sfx4ever]

Hola a todos.

Tengo un problema con mi web y es que los usuarios modifican los parámetros que se pasan en la URL con GET, lo cual es un gran inconveniente para la web.

Había pensado pasar las variables con POST, es decir, hacer un formulario, poner las variables en campos HIDDEN y enviar el formulario al pulsar el enlace, pero creo que para cualquier usuario avanzado esto también es modificable.

Así que creo que me voy a decidir por las variables de session, pues, creo, que no hay forma de modificarlas.
Mi pregunta es si conocéis alguna clase, librería, función o lo que sea que me ayude a esto, a pasar variables entre páginas, o simplemente si me dais algún consejo para construir yo mismo una rutina que gestione todo esto.

GRACIAS ANTICIPADAS

[DarkJ]

¿Cual es el inconveniente de que modifiquen los parametros GET? Con un buen filtrado de los parametros puedes evitar que te metan cosas peligrosas.

[sfx4ever]

ufff, te lo aseguro DarkJ, tengo un GRAN problema con este tema..

Mi web es como una especie de juego, así que algunos usuarios solo piensan en encontrar bugs (aumentar su vida, etc.) modificando los parámetros de la URL, y eso que tengo algunas protecciones, como por ejemplo encriptar antes los parámetros por md5 y luego desencriptarlos y comprobar que coinciden, etc, pero siempre se me escapa algo (algunas urls son muy complejas con muchos parametros), así que lo más seguro que se me ha ocurrido es por variables de sesión.
Por cierto, ¿a que te refieres con un buen filtrado?

[DarkJ]

Con filtrado me refiero a que si un parametro solo puede ser un entero positivo, pues solo tomar el valor si es un entero positivo; escapar las comillas en los parametros que van a formar consultas sql, etc.

Pero creo que en tu caso lo que necesitas es otro planteamiento, porque es un juego. Quizas deberias plantearlo para que lo que llege desde el navegador no sea un cambio de estado, sino una accion. Y en el servidor hacer 2 cosas: comprobar que la accion es posible; y ejecutar la accion que cambia el estado.

Por ejemplo, si tienes un link "comer manzana", en tu servidor primero tienes que comprobar que puede comer una manzana (comprobar que la tiene en el inventario), y si puede, cambiar el estado (eliminar la manzana del inventario, aumentar la vida del jugador).

El tema es que siempre vas a tener links distintos para cada accion distinta. La sesion te sirve para almacenar el estado, pero siempre vas a necesitar algo en los enlaces para distinguir la accion.

Por ejemplo, en la sesion puedes tener la lista del inventario, pero en la pagina que muestras el inventario tendras una accion "usar objeto". Tendras para cada objeto un link usar_objeto.php?id=id_objeto. Porque con un solo enlace usar_objeto.php, ¿como sabes a que objeto hace referencia el jugador?

Puedes usar "firmas" para descartar rapidamente links creados a mano por los usuarios (añadir un campo extra que es el resultado de md5 la concatenacion de los parametros y una palabra secreta que solo esta en el servidor).

[Kamae]

Qué peligro tiene pasar parámetros por POST?
Yo siempre he usado POST y campos ocultos...
Y luego almacenarlo en SESSIONes los más repetitivos o importantes.

Un truquillo que he visto hacer en webs de juegos es también pasar por parámetros GET, pero limpiando la dirección de arriba el navegador para que no se vea el paso de variables (aunque evidentemente, mirando en propiedades de cada link se ve.. pero bueno, es un pequeño obstáculo más para usuarios medio tontos).

Aunque puedes conseguir seguridad con GET si filtras bien como te dice DarkJ, por ejemplo interactuando con la BBDD (que ahí sí que no te meterán mano) y comprobando siempre que todo sea coherente entre ellos.

[DarkJ]

Qué peligro tiene pasar parámetros por POST?
Yo siempre he usado POST y campos ocultos...

No es "peligro", sino que simplemente tal como esta pensado HTTP, no hay forma de garantizar que esos parametros ocultos sean los que tu generaste. No es nada dificil crear peticiones HTTP POST que el servidor no diferencia del que pueda venir del navegador.

Por eso una maxima de seguridad es sospechar de todo contenido enviado desde el cliente, ya sea GET, POST o COOKIES. Todo el mundo es culpable hasta que se demuestre lo contrario. Por eso el register_globals esta a punto de desparecer.

[Kamae]

Pero para ello deben conocer con qué nombre se guarda un parámetro POST para simular que lo envían no? De todas formas, mezclando POST+BBDD+Filtros no creo que haya más peligro que con GET+BBDD+Filtros, al contrario. Creo eh? No sé xD

[DarkJ]

Mira el codigo HTML de cualqier pagina, ahi esta toda la informacion de los nombres de los campos del formulario.

La unica diferencia entre el get y el post, es que con get puedes hacer pruebas directamente en cualquier navegador, y para el post tienes que buscarte un poco mas la vida (no se si habra para firefox alguna extension para enviar post creados por ti, no seria dificil).

[sfx4ever]

claro, Kamae, imagina que miras el codigo de una web y tiene algo parecido a esto:

<form action='entrada_datos.php' method='post'>
<input type='hidden' name='vida' value='1000'>
<inpyt type='submit' value='enviar'>
</form>

Cualquier usuario algo avanzado puede:
1. Crearse su pagina en su propio servidor.
2. Modificar el action para que envie los datos al servidor real (por ejemplo con url absoluta)
3. Cambiar los datos del formulario (<input type='hidden' name='vida' value='100000000'>)
4. enviar el formulario

Ahi esta el problema, que con las variables de sesion no lo tienes...

[Kamae]

Vaalep merci a los 2, me va bien esto de venir por aquí, y se aprenden cositas :D jaja