Cita: WOW entonces el tema no va por seguridad sino por validar el dato que se pasa por la URL, te comentaba que no es seguro por k hay veces que se puede adulterar los valores de las variables al pasarlos via URL, claro que si hay una validación la cosa cambia.
Si, eso es cierto .. todo dato que pueda "entrar" a un script tuyo ha de ser validado y desconfiar de el totalmente. Por eso no se trata de "ocultarlo" sino "validarlo" por què tú (tu aplicaciòn) sabe que dato esperar: si espero un número .. no me aceptes "caracteres" .. si hay un rango .. validalo .. si se trata de un registro X de una BBDD .. valida que exista antes de hacer nada .. etc.
Cita: Entonces hay algo k no me keda claro, sorry por la ignorancia en el tema de trabajar con register_globals en off y es que siempre trabaje en On, pero por ejemplo tengo este codigo:
Realmente el uso o concepto de "register globals" no es el problema de "validaciòn" .. El uso de "register_globals" sòlo te presta una seguridad extra en el aspecto que -obliga- a tomar los valores de las variables que puedan llegar a tu script en forma externa (que no genera este) por su array superglobal asociado:
$_GET -> Links, redireccionamientos por el URL (javascirpt, HTML . etc)
$_POST -> Formularios HTML en method=POST (por què puede ser tambièn GET).
Cita: Ahora lo inseguro de este codigo es k si pongo en la barra de direcciones esto, por ejemplo
http://www.pagina2.php?nuevo=valoradulterado , lo que muestra en la pagina2.php es valoradulterado y ya no valororiginal, entonces algo similar pienso k puede pasar con mi link.
Si, .. eso nos sucede siempre .. por eso se trata de "validar" ese dato. En otras ocasiones tambièn te interesa que el dato se origine en tu script1.php y no en otro .. para ese tipo de casos es más seguro usar sesiones:
En script1.php registras tu variable de sesiòn -> redireccionas sin màs variables en el URL que indicar y en script2.php tomas tus variables de sesión.
Un saludo,