Pasar variables en forma segura

[robervcp]

Hola, quizas esto le pase a mas de uno.

Muchas veces tenemos que hacer cosas como un ABM (alta-baja-modificacion) de noticias. Ademas las mismas estan agrupadas en secciones a las cuales tienen acceso un usuario que pertenece a un grupo...

El tema de los permisos de usuarios-grupos-secciones estaria definido.

El sistema seguramente chequea la condicion del usuario y simplemente nos genera una tabla donde en cada renglon hay una noticia. Listando asi las noticias que le corresponde.

En cada renglon vemos en celdas separadas, el ID, el titulo Fecha etc. Pero ademas enlaces del tipo "editar" "borrar". por ej:
editar.asp?id=15
borrar.asp?id=15
o incluso en una sola pagina
abm.asp?accion=editar&id=15
abm.asp?accion=borrar&id=15

Sea como sea.
La pagina.asp que recibe por URL los valores se encarga de llevar a cabo la accion. Pues las paginas que llevan a cabo las acciones usan el request.querystring("id")...



Muchas veces para hacer mas rapido, si sabemos que la noticia que queremos "borrar" tiene el ID (digamos 20) ponemos tiprando en el URL:
abm.asp?accion=borrar&id=20
Y Listo!


Esto no es para nada un ejemplo de confiabilidad pues, si la noticia con ID 20, pertenece a otro grupo, no estaremos haciendo bien las cosas.

Por lo general se comprueban los permisos a fin de mostrar una lista de noticias (con los links para el ABM) , ya que el usuario promedio ni idea de la vida....


1) Mi pregunta es, como encaran este problema, particularmente?

2) Como el sistema ya esta hecho por otro, y no hay mucho tiempo para mucho mas, Pensaba que en lugar de poner enlaces que envien por URL las variables, seria mejor poner miniFormularios con un boton y las variables y sus valores ponerlos en INPUTs con readonly y ocultos (hidden) de manera que no lo puedan ver a simple vista y evitar la modificacion.

Queria su opcion al respecto para estos dos puntos. Graicas Rober

[3pies]

Se supone que esa noticia tiene un autor o grupo al que pertenece, asociado en un campo ¿no?.

Ej: noticia - autor - fecha

Pues lo normal sería que cuando se ha seleccionado una id (tipeada o no), que al efectuar la modificación/baja, haga una consulta a la BD para saber si esa id de la noticia está escrita por ese autor o grupo con permisos, y permitir o no su modificación/baja.

Ej. Si a mi me sale que tengo 3 noticias en el listado, con las id: 4, 55, y 75, y selecciono la modificación de la id 55, tendrás algo así en la página siguiente:

www.loquesea.com/modificarnoticia.asp?id=55

Al cargarse la página modificarnoticia.asp, comprueba si tiene permisos para modificar la noticia (igual que en el listado que le has presentado con sus noticias), y listo. Si tipea la id 43, ...un mensaje de que esa noticia no puede borrarla/modificarla, y listos.

[robervcp]

Gracias por responder.
Es lo que uno deberia hacer.
El tema esta en que el sistema es un despelote de codigo repartido por todos lados.
El tiempo que me llevaria controlar todo seria inmenso. Por eso la solucion de usar <form>.

Es mejor pasar mediante POST, que mediante GET o URL , no?

[3pies]

Eso va a gustos, porque en cualquier caso, lo ideal es que en la página que recibes (editar.asp, baja.asp, etc), hagas esa segunda comprobación.

Enviandolo a través de un form, puede solucionarse, exceptoooooooo que se de el caso de que algún espabilado haga esto:

Imagina: Yo no tengo permisos para borrar la id 43. Lo mandas por post, y me bajo la página a mi pc (en forma local), cambio la ruta de tu sitio poniéndola completa (nada de action=baja.asp?id=XX, sino action=http://tuweb.com/baja.asp?id=43), te da igual, ...se borraría esa id, pues no has hecho la comprobación en la página receptora baja.asp

Yo siempre haría la comprobación en la página que recibe. Si está tan liado el código, casi sería mejor empezar de cero.

[robervcp]

Bien lo dices, tambien se me ha ocurrido claro, ! :)

Pero como comente es tal kilombo, que perderia el laburo.

Si logro que la pagina receptora se asegure que el FORM que le llega, procede una pagina situada en http://tuweb.com/abm.asp?us=rober

entonces con eso y el envio mediante FORM (method=post) podria dar un poco mas de seguridad a lo que hay ahora.????????????

Estoy de acuerdo que deberia comprar permisis en ambas instancias (ABM y pagina receptora), pero ahora no puedo.

[u_goldman]

Si, podría ser un poco más seguro, no óptimo, pero mejor si, hay varias cosas que puedes implementar, como te recomedaron ya, aunque la mejor solución para la seguridad, es pensar e implementar todas las opciones disponibles y aún así te quedarás corto, si es un lio y creo que a todos nos parte la cabeza hacerlo, muchas veces te tardas más tratando de hacer tu aplicación medianamente segura, que lo que te tardas en desarrollar ese módulo, pero pues no hay de otra, y si está tan mal, también lo comentaron ya, sería mejor que pensaras en hacerlo todo nuevamente en cuanto tengas un poco de tiempo.

Salú!

[AlZuwaga]

robervcp, yo no sé si perderás el laburo o si, por el contrario, y argumentándole bien las cosas a tu cliente (jefe o lo que sea), vas a poder cobrar un dinero extra al mejorar la seguridad de la aplicación desarrollada por el "palurdo ese" que la hizo (al menos que ese palurdo haya sido tu jefe jajaja)

Me pá que la única solución (o por lo menos la mejor de todas) es la que 3Pies dice.
Suerte

[robervcp]

gracias por las respuestas.
ya veo si hago los FORMs para cada enlace
o
Hago una clase o funcion (modulito) que consulte a partir del grupo del usuario los permisos que tiene en la seccion de la noticia a modificar.
saludos

[trasgukabi]

dices que las noticias tienen cada uno un grupo asignado. el grupo me imagino que lo mantendrás en una session. Porque no haces ésto:

en vez de delete from noticias where id=loquesea

delete from noticias where id="&request.querystring("id")&" and grupo="&session("grupo")

controlas el error que te devuelva OLEDB (si no encuentra el registro) y ya está.

así el borrado es completamente seguro (creo, vaya. igual se me escapa algo)

[Neuron_376]

Mira, si ya vas a cambiar cada pagina que envia la informacion para usar FORM y tambien la pagina que captura la informacion, entonces no importa el tipo de cambio que hagas... puedes hacer esto...

1. Paginas que envian la informacion... ponlo todo en session.

Session("NoticiaID")

2. Pagina que recibe info...

where NoticiaID = Session("NoticiaID")

Por otra parte, lo del FORM, en tu caso puede ser muy muy seguro, si estas en un sistema de administracion usando https, el form va muy bien y no tiene problemas, pero si no usas https, entonces session es lo mas seguro.

Ojala te sirva para lo que estas haciendo, suerte... Suerte!!

[robervcp]

Primero voy a poner en claro el contexto.
Hay dos paginas:
- Pagina de datos: contiene el ID, la accion a desarrollar etc,y es donde el usurio debe hacer click para ejecutar.
ej: datos.php
- Pafina del proceso: se encarga de recibir los datos de la primer pagina y ejecuta las sentencias SQL...
ej: proceso.php

Mi noticia tiene id=20
La noticia ajena tiene id=100 (la cual no deberia poder manipular)

La situacion actual es que en datos.php , hay una serie de links del tipo href=proceso.php?accion=borrar&id=XX
siendo XX los id de las noticias, a las que tengo acceso, gracias a una comprobacion con la DB (en la realidad es mas complicado, pero para el caso nos sirve).
Como cualquiera puede escribir en el URL de una ventana: proceso.php?accion=borrar&id=100 ahi la embarramos mal.

Como hacer nuevamente la comprobacion de si la id de la noticia me corresponde, es en el caso real un kilombo. Dejemos de lado esa posibilidad.

La solucion original, era usar el <form> para cada enlace, de cada noticia. De esta manera nadie puede tener atacar poniendo en el URL proceso.php?accion=borrar&id=100 ya que proceso.php acepta variable/valor pasados por el metodo post del form. Con esa idea, el tema se cerraba a que nadie pudiera generar un clon del <form> que existia en datos.php ... de ahi todo este hilo.

Ahora bien, esta propuesta, de generar un algoritmo tal que genere un codigo a partir del id, de la accion, del usuario, para añadir a los enlaces ya existentes; simplemente me parece genial (lo simple es siempre mejor) :D ya que seria imposible para el usuario lograr generar ese codigo para un id (de la noticia que no le corresponde) determinado.

Para mi el algoritmo deberia estar basado en el "id" de la noticia, la "accion" a llevar a cabo, la "pass" del usuario, una "clave" propia del algoritmo, un timespam que viajaria solo si esta en un input oculto, para que proceso.php pueda usarlo, y unos cuantos numeros primos :)


El Timestamp tiene sentido solo para establecer un vencimiento a la MAC

Quizas mejor que el password del usuario usa el nombre de usuario. Este ultimo es unico mientras que la password no. Ademas, el nombre de usuario es publico y la contraseña no debe serlo. El efecto que obtendras es el mismo y no andas divulgando informacion privada por alli.

saludos