2010-08-05 23 views
6

Pensé: no sé si soy lento.Aplicaciones web: ¿Almacenar la identificación en campos ocultos es seguro?

Normalmente guardo el ID del ítem que estoy editando en un campo oculto. Luego en back-end (estoy usando PHP/Zend Framework por cierto), lo consigo para determinar qué elemento se edita. Pero luego pensé, en algo más seguro, por ejemplo. editar perfil, el usuario puede de alguna manera editar un campo oculto ¿no? Luego puede editar el perfil de otra persona. Sé por el perfil de edición, puedo obtener la id de la variable de sesión, pero ¿qué ocurre si obtengo algo que me obligue a almacenar el id en algún lugar?

Recibí ACL (Zend_Acl) Hago esto. Básicamente, tome la identificación de los parámetros de solicitud

$id = $req->getParam('id'); 

y luego verifique si el usuario registrado tiene permiso para editar el elemento. Pero la cosa es que me pregunto si la url es algo así como /users/edit/1 donde 1 es la identificación. Pero de alguna manera, el campo oculto se cambia a 2, ¿cuál será el parámetro de solicitud?

¿Cómo lidiarías con esto?

Respuesta

10

Debe almacenar algún tipo de identificación en el cliente; de ​​lo contrario, ¿cómo sabría qué artículo editar?
Esto no lo libera de obligatorio compruebe en el servidor que el usuario actual tiene privilegios para editar/ver el elemento editado.
Aparte de eso, ¿por qué le importaría cómo llegó a editar el elemento (ya sea por el uso legal de la herramienta web, o editando el campo oculto/lo que sea).

+0

me pregunto, ¿qué valor obtendré si el ID param isset en ambos GET & POST? cuál será utilizado? –

+0

se define en php.ini –

+0

Bueno, seguramente eso dependerá de lo que realmente llame. $ _POST o $ _GET. A continuación, puede elegir cuál se utiliza y, por lo que a mí respecta, usar vars globales de esa manera no es una buena idea. – webnoob

1

El almacenamiento de la identificación en un valor oculto no es del todo seguro. En general, almacenamos ID en la variable de sesión.

+1

No es necesario utilizar la variable de sesión. Se trata de un sonido más semántico (y más fácil) para verificar que los datos de publicación del usuario tengan permiso para editar el registro para el que están publicando datos. – meagar

+0

ah. meagar, expresaste lo que pensé muy bien! tener 2 variables que supuestamente almacenan el mismo valor, es desordenado y tal vez propenso a errores –

+0

El OP pregunta cómo determinar cuál es el registro que se está editando sin cambiarlo, es decir, cómo almacenan la ID para luego enviarla al servidor para consultar el registro con, por lo tanto, la declaración de ppshein es correcta. Debería guardar el ID en una sesión para que no se pueda modificar y, a CONTINUACIÓN, verificar los permisos para ese registro. No puede verificar los permisos si no sabe qué documento se está editando. – webnoob

0

No debe basarse en nada enviado por el usuario. Siempre debe verificar los permisos de usuario en el lado del servidor. Un atacante puede preparar cualquier solicitud a su servidor.

1

como dijo ppshein, almacenar identificaciones sensibles en una var oculta no es seguro. ¿Almacenarías una contraseña en una varilla escondida? Es realmente fácil incluso para un pirata novato obtener esos datos.

Debe asegurarse de que el servidor impone todos los controles de acceso.

En su caso, debe asegurarse de que el usuario que está conectado (el de la sesión) es el propietario del perfil que se está editando. O que el usuario que realiza las ediciones tiene permisos para editar ese perfil (por ejemplo, es un administrador)

0

De acuerdo con todos los puntos anteriores, pero si realmente necesita almacenar algo en el lado del cliente por cualquier razón, siempre puede encriptar el datos y descifrar cuando necesita usarlo, pero una vez más, el uso de sesiones sería la mejor manera de manejarlo, ya que no son accesibles desde el lado del cliente.

+0

que no cambia el hecho de que el usuario puede cambiar el valor tho. –

+0

Por supuesto, y ahí es donde entra en juego la validación del lado del servidor. Si un hacker cambia un valor en un ID cifrado, ya no se descifraría correctamente y, por lo tanto, sabría que algo andaba mal. – webnoob

+0

, entonces creo que el cifrado puede no ser demasiado útil en este caso, ya que la identificación no es un secreto. Encriptar o no, aún necesitaré verificar si el usuario tiene acceso al recurso solicitado. –

Cuestiones relacionadas