seguridad al pasar un id

[roboty]

Que manera seria la correcta y más segura para pasar un identificador para modificar datos de la base de datos.
Enlace de ejemplo.

Código PHP:

echo'<a href="modificar.php? Id='.$ id.'"> modificar </a>';
;
 

Algún experto me dice como se hace esto de forma a segura?
Saludos.

[awik]

yo que tu mejor lo pando de manera oculta
osea por un formulario ...

Código HTML:

<form method="post" name="formu" action=modificar.php?modificarxd=1" >  <-- aqui puedes poner asi como para engañar a algun payaso , osea como para despistar nomas xd
 
<input type="hidden" name="id" value="<?php echo $ id; ?>">
<input type="submit"name="enviar" value="Enviar">
</form
 

[roboty]

Eso no es seguro debe haber alguna forma de hacerlo seguro independientemente por pistas o get

[awik]

Iniciado por roboty

Eso no es seguro debe haber alguna forma de hacerlo seguro independientemente por pistas o get

como asi ?

si es algo oculto q ni el usuario podra ver ...
si me explicas estaria agradecido

[pateketrueke]

Ya sea que pases el ID por URL o con un campo hidden siempre será visible si inspeccionas el código HTML generado en el navegador, eso cualquiera lo sabe.

Al fin y al cabo es tu programación la responsable de la seguridad, ¿un ID qué tiene que ver?

Que sea visible o no el ID no hace "inseguro" tu sistema por ninguna razón.

[Italico76]

La forma mas segura seria:

- Enviar por POST para CREATE / DELETE / UPDATE / SELECT

ó

- Enviar por POST para CREATE / DELETE / UPDATE y por GET para SELECT


Adicional.... podrias usar usar "urls amigables" para evitar enviar algun ID al hacer las peticiones (POST / GET) ..

En caso que pases variables por GET (?variable=valor&...) podrias no usar los nombres de los campos en las variables y ofuscar los IDs pero solo para las peticiones GET asi lograras que si logran "emular" una peticion POST no puedan hacete daño (ya no sabrian cuales son los IDs)

Te paso un ofuscador simple de IDs para que uses en tus gets que he hecho:

Código HTML:

<?php
/*
    @author: Pablo Bozzolo
*/
 
# auxiliar
function swapstr($s){   
    $endpos = strlen($s)-1;
    $last   = $s[$endpos];
    $first  = $s[0];
    $s = substr_replace ($s , $last ,0, 1); 
    $s = substr_replace ($s , $first ,$endpos, 1); 
    return $s;
}
 
# coding
function ofusca_key($n){
    return swapstr(strval(dechex(1000 + $n*$n)));
}   
    
#decoding
function desofusca_key($s){
    return sqrt(hexdec(swapstr($s)) -1000);
}   
 
 
// Ejemplo
/*
$n = 3500;
 
echo ofusca_key($n)."\n";
echo desofusca_key(ofusca_key($n)); 
*/
 

@pateketrueke: pues yo si creo las cosas se pueden complicar un poco...... (leer comentario final)

Iniciado por pateketrueke

Ya sea que pases el ID por URL o con un campo hidden siempre será visible si inspeccionas el código HTML generado en el navegador, eso cualquiera lo sabe.

Al fin y al cabo es tu programación la responsable de la seguridad, ¿un ID qué tiene que ver?

Que sea visible o no el ID no hace "inseguro" tu sistema por ninguna razón.

Obviamente la solucion que propongo solo requiere abrir la consola dell navegador e inspeccionar las peticiones HTTP, eso cualquiera lo sabe.

[roboty]

Iniciado por awik

como asi ?

si es algo oculto q ni el usuario podra ver ...
si me explicas estaria agradecido

Bueno ya te respondio pateketrueke.

Realmente pateketrueke tienes razon tratandose de un identificador no hay riesgos en el sistema, mi duda era que si el usuario intenta cambiar algun digito y encontrara un id en mi base de datos y modificara la base, pero entiendo que esto se soluciona creando id completamente difierentes uno de otros.

Pero quizas si en vez de un identificador quiero pasar una contraseña que alternativas tengo con php para que sea segura en el caso de iniciar sesion?

[Italico76]

Iniciado por roboty

Pero quizas si en vez de un identificador quiero pasar una contraseña que alternativas tengo con php para que sea segura en el caso de iniciar sesion?

Aunque ignoras lo que te he escrito, quizas porque no te supiste explicar bien (te falto el contexto: logueo de usuarios), te vuelvo a contestar:

Las contraseña para iniciar session la puedes enviar por POST o GET, da igual porque de todas formas no estas "creando" un recurso ni borrandolo ni actualizandolo sino accediendolo y para lograr el acceso se necesita la contraseña que entre otras cosas me imagino no guardaras en la DB sin hacerle un HASH

[roboty]

Iniciado por Italico76

Aunque ignoras lo que te he escrito, quizas porque no te supiste explicar bien (te falto el contexto: logueo de usuarios), te vuelvo a contestar:

Las contraseña para iniciar session la puedes enviar por POST o GET, da igual porque de todas formas no estas "creando" un recurso ni borrandolo ni actualizandolo sino accediendolo y para lograr el acceso se necesita la contraseña que entre otras cosas me imagino no guardaras en la DB sin hacerle un HASH

Hola no es que te ignore lo que pusistes pero tu solucion son las mismas posibilidades que lo que propuso awik, entonces entendi que realmente no era un problema de visibilidad el id pero como pensaba solucionar lo de pasar un id de la misma forma que pasar una contraseña, por eso ahora puse ayuda para la contraseña.

Sobre tu respuesta de contraseña te agradezco tu ayuda, te comento la contraseña la guardo con un hash en la base de datos es mas con un hash solo de ida.
Pero mi duda es si con esto ya es completamente seguro o no?
Saludos.

[Italico76]

Iniciado por roboty

Hola no es que te ignore lo que pusistes pero tu solucion son las mismas posibilidades que lo que propuso awik, entonces entendi que realmente no era un problema de visibilidad el id

Estas totalmente equivocado

En algun momento dije de ocultarlo dentro de un elemento de formulario ? sabes lo que son las urls amigables ? sabes, por otro lado, que es la ofuscacion ?


Lo que dije es:

- Por POST: CREATE / UPDATE / DELETE de recursos

- Por GET : o usas URLs amigables (para no mostrar ni variables ni IDs en las urls) o bien ofuscas el ID (lo manipulas numericamente) y entre otras cosas lo haces no-consecutivo, sumamente "espaciado" y por supuesto haces esto ultimo solo en los GET para que no puedan recuperar esos numeros y aplicarlos en los CREATE / UPDATE / DELETE de recursos

Ya que no lo entiendas..... es otra cuestion

Pero mi duda es si con esto ya es completamente seguro o no?

Ningun sistema es seguro.... o mejor dicho es seguro que la embarras por otro lado, de todas formas es mejor que tu web no sea un colador: menos agujeros, mejor :)

[nup_]

Iniciado por roboty

... te comento la contraseña la guardo con un hash en la base de datos es mas con un hash solo de ida.
Pero mi duda es si con esto ya es completamente seguro o no?

No, no es suficiente:
http://www.php.net/manual/es/faq.passwords.php
http://www.php.net/manual/es/function.crypt.php
http://www.php.net/manual/es/function.password-hash.php
http://www.michael-pratt.com/blog/8/...dsContrasenas/

slds;

nup_

[roboty]

Iniciado por Italico76

Estas totalmente equivocado

En algun momento dije de ocultarlo dentro de un elemento de formulario ? sabes lo que son las urls amigables ? sabes, por otro lado, que es la ofuscacion ?


Lo que dije es:

- Por POST: CREATE / UPDATE / DELETE de recursos

- Por GET : o usas URLs amigables (para no mostrar ni variables ni IDs en las urls) o bien ofuscas el ID (lo manipulas numericamente) y entre otras cosas lo haces no-consecutivo, sumamente "espaciado" y por supuesto haces esto ultimo solo en los GET para que no puedan recuperar esos numeros y aplicarlos en los CREATE / UPDATE / DELETE de recursos

Ya que no lo entiendas..... es otra cuestion



Ningun sistema es seguro.... o mejor dicho es seguro que la embarras por otro lado, de todas formas es mejor que tu web no sea un colador: menos agujeros, mejor :)

Claro que te entendi, como tu mismo dijistes:

Obviamente la solucion que propongo solo requiere abrir la consola dell navegador e inspeccionar las peticiones HTTP, eso cualquiera lo sabe.

para mi esto no es una solucion porque cualquier usuario lo puede inspecionar.


Referente a lo de la contraseña, evidentemente ninguna web acaba nunca de ser segura pero si lo mas seguro posible hasta el dia de hoy, es decir ahi algo mas seguro que un hash solo de ida?

saludos.

[roboty]

Iniciado por nup_

No, no es suficiente:
http://www.php.net/manual/es/faq.passwords.php
http://www.php.net/manual/es/function.crypt.php
http://www.php.net/manual/es/function.password-hash.php
http://www.michael-pratt.com/blog/8/...dsContrasenas/

slds;

nup_

Hola gracias por tu interes, voy a mirar esos enlaces que me pones y comento.
Saludos.

[Italico76]

Iniciado por roboty

Obviamente la solucion que propongo solo requiere abrir la consola dell navegador e inspeccionar las peticiones HTTP, eso cualquiera lo sabe.

para mi esto no es una solucion porque cualquier usuario lo puede inspecionar.

Fue una irnoia: porque recuperas un ID de los SELECT que no te sirve para nada en operaciones CREATE / UPDATE / DELETE

Intenta implementar lo que te digo.... piensalo un poquito al menos, haz el esfuerzo

[roboty]

Ahora si, muchas gracias nup_, saludos.

[roboty]

Iniciado por Italico76

Fue una irnoia: porque recuperas un ID de los SELECT que no te sirve para nada en operaciones CREATE / UPDATE / DELETE

Intenta implementar lo que te digo.... piensalo un poquito al menos, haz el esfuerzo

Amigo ya lo hice, te comento una cosa en php existe por ejemplo esta funcion base64_encode tiene la inversa tambien es decir que por mucho que codifique cualquier usuario puede decodificar solo necesita la funcion inversa, es similar a lo tuyo verdad ,
un saludo y gracias.

[webankenovi]

Hola amigos , como dijo @pateketrueke sea o no visible el id no hace inseguro tu sistema , mas bien la verificacion de dicho id si puede hacer tu sistema inseguro , sea visible o no deberas de verificar y validar el id yege mediante post / get .. , un ejemplo sencillo es si tu id siempre es un numero verificar que dicho id es numerico y por lo tanto si lo es es un id valido.

Ahora bien para ocultarlo ya sea mediante get o post con campo hidden y demas siempre se podra alterar dicho id , para ocultarlo ya te dijieron de ofuscarlo tambien tienes otras medidas encriptacion y una que yo te recomiendo es usar sesiones, si te interesa usar sesiones para esconder el id original dimelo y te pongo un ejemplo sencillo.

saludos

[Italico76]

Iniciado por roboty

Amigo ya lo hice, te comento una cosa en php existe por ejemplo esta funcion base64_encode tiene la inversa tambien es decir que por mucho que codifique cualquier usuario puede decodificar solo necesita la funcion inversa, es similar a lo tuyo verdad ,
un saludo y gracias.

JE.. si se que existen "funciones nativas" pero recomeneria no usarlas solas, sino si puedes usa algun algoritmo propio encima porque los hackers tambien las conocen

La idea es que con un algoritmo nuevo excepto estes protegiendo la web de un banco, no vale la pena descifrarlo... ademas porque seguro existe otra vulenrabilidad explotable ja!

[webankenovi]

ejemplo de uso con sesiones , la idea es enviar un id falso aleatoriamente en cada peticion para cad accion , el ejemplo es muy simple para que tengas una idea.

Código PHP:

<?php
 
// modificar.php
 
session_start();
 
 
// tambien podemos verificar que dicho id sea numerico
 
if( ! isset($_GET['id']) || ! ctype_digit($_GET['id']))
{
    exit('id no valido');
}
 
 
// verificamos el id.
 
if(isset($_SESSION['ids']['modificar']) and $_GET['id'] == $_SESSION['ids']['modificar'])
{
 
 
// acciones a realizar
 
 
}
else
{
    exit('id no valido');
}
 
 
// archivo donde se crea el link 
 
session_start();
 
 $_SESSION['ids'] = array(
         
            'modificar' => rand(1,9999999999) //ejemplo con un rand aleatorio simple
 
            // mas acciones
 
            );
  
 
 
echo'<a href="modificar.php?id='. $_SESSION['ids']['modificar'].'"> modificar</a>';
 
 
?>
 

[Italico76]

@webankenovi : no me gusta nada la parte de "en cada peticion", ya que automaticamente estas diciendo al atacante que ese ID es falso

Por otro lado si estas logueado, al menos el ID de tu identificacion como usuario en la base de datos no es crtiica, ya que te identifica solo a ti : incluso puedes no hacerle ningun tipo de manipulacion.

Por otro lado.. si son IDs de otros usuarios, aplica el primer parrafo... no tiene sentido porque es demasiado obvio y mantener un ID falso por session para cada perfil visitado (por ejemplo) de otros usuarios seria llenar de cosas para recordar en variables de session, tampoco le veo mucho sentido.

En todo caso:

Ofuscar lo que no le compete al usuario (IDs de otros usuarios por ejemplo, IDs de productos en una base de datos, etc..) y mostrarle transparentemente SU ID

[webankenovi]

Iniciado por Italico76

@webankenovi : no me gusta nada la parte de "en cada peticion", ya que automaticamente estas diciendo al atacante que ese ID es falso

¿Por? no entiendo por que el tuviera que saber que ese id es falso por el simple hecho de que cada peticion se renueve , al modificar ese id en la url ya no seria valido , por lo que le estarias diciendo que solo ese id sea falso o no es el unico con el que se puede acceder a realizar la accion , mas bien no es falso tan solo es un identificador de una session donde se almacena el id original.

Iniciado por Italico76

Por otro lado si estas logueado, al menos el ID de tu identificacion como usuario en la base de datos no es crtiica, ya que te identifica solo a ti : incluso puedes no hacerle ningun tipo de manipulacion.

Por otro lado.. si son IDs de otros usuarios, aplica el primer parrafo... no tiene sentido porque es demasiado obvio y mantener un ID falso por session para cada perfil visitado (por ejemplo) de otros usuarios seria llenar de cosas para recordar en variables de session, tampoco le veo mucho sentido.

En todo caso:

Ofuscar lo que no le compete al usuario (IDs de otros usuarios por ejemplo, IDs de productos en una base de datos, etc..) y mostrarle transparentemente SU ID

mas bien mi posible solucion es mas destinada a realizar acciones tal como se puede ver en el ejemplo , modificar eliminar etc...

[Italico76]

Iniciado por webankenovi

¿Por? no entiendo por que el tuviera que saber que ese id es falso por el simple hecho de que cada peticion se renueve , al modificar ese id en la url ya no seria valido , por lo que le estarias diciendo que solo ese id sea falso o no es el unico con el que se puede acceder a realizar la accion , mas bien no es falso tan solo es un identificador de una session donde se almacena el id original.



mas bien mi posible solucion es mas destinada a realizar acciones tal como se puede ver en el ejemplo , modificar eliminar etc...

Ya le entendí compa.... una, URL que expira ..... yo habia hecho algo parecido para otro post con la opcion de configurar el tiempo de validez (en vez de usar sesiones) y tambien era mediante ofuscacion : ofuscaba el ID con el timestamp y pues se podria ofuscar con la operacion (controlador) y demas parametros