Ya tenia conciencia de que por medio de las url's se pueden definir variables php (dependiendo si tu configuración php decidiste que no lo permita) pero en los casos donde se necesita crear paginas "dinámicas", por ejemplo un perfil (profile?id=3) digamos nos mostraría el perfil del usuario con el id 3, toda su información... avatar, nombre, apellido, etcétera. Pero digamos que en otro caso tenemos lo siguiente...

Este código lo saque de la pagina desde donde tome la información a esta vulnerabilidad. (Te explican otras vulnerabilidades, muy interesante.. No se si se permite publicar el link)

<?php
if ($_GET['password'] == 'secreto') {
$admin = true;
}
 
[...]
 
if ($admin) {
// Acciones que solo puede realizar el administrador conociendo la contraseña
[...]
}
?>
 

Bueno en este código bastaría con que x usuario entre a la pagina que tiene este script, digamos que esta pagina se llama "page" entonces el "atacante" pondría "page?admin=1" y podría ingresar como un administrador.

La solución sería

<?php
$admin = false;
 
if ($_GET['password'] == 'secreto') {
$admin = true;
}
 
[...]
 
if ($admin) {
// Acciones que solo puede realizar el administrador conociendo la contraseña
[...]
}
?>
 

Definir la variable de una forma más global.

Bueno la idea no era hacer una guía, pero acá va mi problema...
mi duda viene de si se pueden hacer lo mismo con sessiones, ya probé en mi script y no veo cambios pero no estoy totalmente seguro. En la misma pagina desde donde vi esta información dice...

"Transferir parámetros en direcciones URL (por ejemplo http://domain.tld/script.php?id=1) es una forma común de pasar argumentos a scripts. Sin embargo, siempre debe ser consciente de que estos argumentos pueden ser establecidos a voluntad por el usuario. Esto significa que su contenido no debe considerarse digno de confianza. Lo mismo se aplica a los datos transmitidos a través de HTTP-post y cookies.

Esto es importante cuando se redirige de un script a otro y se transmiten parámetros en el URL o como cookie. El nuevo script no puede considerar estos parámetros como fiables y tiene que comprobarlos de nuevo. A menudo es más fácil usar las funciones de sesión de PHP. Los datos que se han comprobado y almacenado en la sesión ahora se pueden clasificar y utilizar como seguros. El usuario no tiene la posibilidad de cambiar el contenido de la sesión directamente.
El identificador de sesión se transmite como parámetro con el URL. Dado que se trata de una cadena generada aleatoriamente, la probabilidad de que un atacante pueda adivinar el identificador de una sesión ajena es extremadamente baja.

Dice "la probabilidad de que un atacante pueda adivinar el identificador de una sesión ajena es extremadamente baja" es decir, probabilidades hay....

Quería saber si esto es así y no tendré que preocuparme en que alguien edite sus sessiones o todo lo contrario.

Ah y ya que estoy... quería saber que es "Lo mismo se aplica a los datos transmitidos a través de HTTP-post y cookies" Me imagino que sería en el caso de las cookies "page?$_COOKIE['cualquier_cosa']=1"

¡Gracias!

---

Mod: Temas sobre PHP van al subforo de PHP.

El problema es con la directiva register_globals, php incluso tiene una página dedicada a este mismo problema:

https://www.php.net/manual/es/security.globals.php

No es mucho problema hoy en día, porque viene desactivada por defecto.

En cuanto a seguridad relacionado con las sesiones, todo va a depender de como las usas. Las sesiones usan cookies por defecto. Basicamente, tienes un identificador de la sesión guardado en la cookie y en base a este identificador de la sessión tu servidor PHP puede almacenar y desplegar información relacionada a esa sesión. La información está almacenada en el servidor.

No es necesario inclusive poner una cookie para sostener la sesión, puedes estar pasando el identificador de la sesión en la URL también. Claro que si la pones en una cookie, tu usuario no se da cuenta de la sesión a menos que se ponga a ver que más está enviando en las peticiones al servidor mientras que en la URL, el usuario puede ver claramente que estás pasando un identificador y si quiere navegar a otra parte del sitio y conservar la misma sesión tiene que reusar parte de la URL. La cookie obstruye menos al usuario regular.

Imaginate que tu script en PHP hace algo como:

if($_COOKIE['admin']){ /* código de admin */ }

Yo puedo enviar una cookie admin a la página web (no es difícil, los navegadores seguro te dejan cambiar valores de las cookies y/o crear nuevas) y listo, me salto la seguridad de tu página.

Pero si yo uso una sesión:

if($_SESSION['admin']){ /*codigo de admin */ }

El único que puede poner valores en la sesión eres tú. Tendrías que permitirle al usuario establecer el valor de alguna otra forma (otro hoyo de seguridad en algún lado por ejemplo) o el usuario tendría que robar una sesión de una persona que tiene el valor establecido (por ejemplo, a través de un MITM).

PHP por defecto usa session ids de 128 bits. No creo que te encuentres a alguien haciendo brute force para obtener la sesión. En primer lugar, el atacante no sabe si en ese momento existe una sesión con el valor puesto. Primero te truena el server antes de que  llegue a la id de la sesión. Y si los planetas se alinearan, los cerdos volaran y de alguna forma el atacante haya conseguido el identificador de una sesión que tiene puesto ese valor, todavía puedes agregar validaciones extras para cerciorarte que el identificador solo pueda ser usado por esa persona.


Esa página muestra valores más seguros para la configuración de las sesiones, no son los valores por defecto.