Seguridad al usar GWT RPC

Question

Tengo un POJO en Google Web Toolkit como este que puedo recuperar del servidor.

class Person implements Serializable { 
    String name; 
    Date creationDate; 
} 

Cuando el cliente realiza cambios, volver a guardarlo en el servidor mediante el GWT RemoteServiceServlet así:

rpcService.saveObject(myPerson,...) 

El problema es que el usuario no debe ser capaz de cambiar la creationDate. Como el método RPC es realmente solo un HTTP POST para el servidor, sería posible modificar el creationDate cambiando la solicitud POST.

Una solución simple sería crear una serie de funciones RPC como changeName(String newName), etc., pero una clase con muchos campos requeriría muchos métodos para cada campo y sería ineficaz al cambiar muchos campos a la vez.

Me gusta la simplicidad de tener un único POJO que pueda usar tanto en el servidor como en el cliente GWT, pero necesito una forma de hacerlo de forma segura. ¿Algunas ideas?

EDITAR

que estoy de volver a presentar con una recompensa para tratar de ver si hay alguna otra idea. Tal vez mi pregunta original se centró demasiado en los detalles de GWT. Realmente creo que esta es una pregunta genérica para cualquier sistema que use JavaBeans para pasar datos entre un entorno seguro (contenedor de servlets) y un entorno inseguro (navegador web).

EDIT 2

También, para ser claros, I utilizado el campo creationDate como un ejemplo del problema. En realidad, el código con el que estoy trabajando es más complicado con muchos campos diferentes.

Answer 1

Te recomiendo que mantengas tu único método RPC, y utilices un mapeador POJO/bean como Dozer o Gilead.

• Con dormilón, se crea un class-mapping que se utiliza para copiar las propiedades de un objeto a otro. Si no especifica una propiedad en el mapeo de clase, no se copiará.
• Con Gilead, el @ReadOnly transport annotation debería ser suficiente.

El beneficio colateral es que usted no necesita cambiar su capa de acceso de datos (suponiendo que tiene uno). No importa si usa un ORM o no, con una base de datos relacional o no.

Answer 2

Bueno ... una solución académica (es decir, teóricamente posible, pero bastante impráctica) podría ser ajustar el estado del objeto utilizando una clave pública descartada cuya clave privada está en el servidor. Podría ser algo como esto:

1. el servidor genera un par de claves pública-privada
2. el servidor envía la clave pública junto con los datos reales para el cliente
3. el cliente calcula un hash del objeto de plena estado junto con la clave pública
4. el cliente envía el objeto y el hash al servidor
5. el servidor vuelve a calcular el hash para confirmar la integridad del paquete

Suponiendo que el par de claves se cambia en cada requset y que el usuario no puede interferir con el proceso de hashing (que puede, pero puede ser lo suficientemente difícil como para hacerlo útil en algunos casos de uso), el servidor podría detectar cualquier cambio en el estado de los objetos hecho después de que se haya calculado el hash en el cliente.

De nuevo, consideren esto como algo más que un experimento mental ... No recomendaría que implementen tal enfoque. En general, debe poder garantizar que la lógica en el cliente no haya sido manipulada antes de llegar a proteger los datos.

Answer 3

Si el cliente no puede cambiar el creationDate y hacer que se adhiera, cambie su serialización (p.su instrucción SQL UPDATE) para no guardar ese campo específico. Solo se debe configurar desde INSERT (donde vendrá desde el servidor de punto final RPC o su servidor de base de datos si establece un valor predeterminado automático).

Answer 4

que haría uso de un enfoque basado en los permisos:

• asignar funciones a los usuarios (por ejemplo, usuario administrador, usuario conectado, el usuario invitado, ...), y
• asociado con esas funciones permisos (por ejemplo, puede leer el nombre de la persona, puede modificar el nombre de la persona, quizás limitando aún más a ciertas personas, etc.)

En cada solicitud del cliente, realice una comprobación en el servidor, si el usuario puede realizar esa acción En el caso de las "fechas de creación", esto probablemente nunca esté permitido para nadie. Así

• si la solicitud contiene una fecha de creación, puede mostrar un mensaje de error o ignorar la petición ...
• si la solicitud no contiene una fecha de creación (caso habitual), se crea la fecha en el servidor - o si la persona ya tiene una fecha de creación, reutilícela.

El cliente generalmente especificará a la persona mediante algún tipo de ID (puede ser nulo para una persona recién creada), que el servidor puede usar para buscar personas existentes. La alteración del ID no debería importar, ya que el usuario solo puede modificar los datos especificados por sus permisos de todos modos.

Caso especial:

Si realmente tiene que utilizar una fecha de creación suministra el cliente, porque quiere saber un poco más exactamente cuando el usuario ha hecho clic, lo único que puede hacer es para verificar que la fecha de creación suministrada se encuentre entre la solicitud anterior y la solicitud actual. Sin embargo, debe tener en cuenta la diferencia horaria entre el servidor y el cliente. Y no puedes garantizar la precisión.

Answer 5

¿Por qué no hacer que los campos sean privados y solo proporcionan un getCreationDate() y ningún setCreationDate()?

Answer 6

Simplemente puede ignorar los valores para los campos inmutables.
Si eso no es posible debido a la configuración de su mecanismo de persistencia en el servidor, cuando la solicitud llegue al servidor, recupere otra instancia del POJO del almacén persistente y llene los campos que son inmutables con los que acaba de crear tiene.De esa manera alguien manipuló algunos de los campos que no te importan.

Por supuesto, el cifrado también puede ser una solución para ayudar a evitar la manipulación.

Answer 7

Divida sus objetos en dos partes. Uno contiene solo los campos que el cliente puede editar. Envíe ambos objetos al cliente, pero solo guarde el objeto editable cuando el cliente lo devuelva. Puedes usar herencia aquí para hacer tu vida más simple.

Si su herramienta de mapeo no se dobla como usted desea, implemente un método copy() que copie todos los campos de un objeto a otro. Luego puede cargar una nueva instancia del objeto desde su base de datos, copiar los campos editables en él y luego guardar el objeto modificado.