Con REST, las sesiones del cliente no se manejan manteniendo el estado del lado del servidor. Cualquier estado de este tipo necesario para llamadas posteriores se pasa al cliente y luego se devuelve al servidor como parte de esas llamadas.
Entonces, ¿cuál es el enfoque estándar para indicar que no desea que tenga el cliente?
Por ejemplo, Tengo un recurso X, las instancias internas de este recurso tienen nombres simples como "A", "B" y "C". Se pueden asociar varias instancias del recurso X con un usuario determinado, y en cada llamada REST quiero especificar en qué instancia específica de X se está operando actualmente.
En el caso simple, solo incluiría algo como esto en mis llamadas REST:
"xId" : "B"
Sin embargo, hay varias cosas que quiero prevenir ...
- Quiero evitar que el usuario busque otras instancias, por ejemplo. especificando IDs arbitrarios como "Z" en sus llamadas.
- No quiero que los nombres internos de los recursos terminen en las máquinas cliente (pueden ser útiles en ataques a través de vectores completamente diferentes).
- Si una instancia dada de X se reasigna a otro usuario, quiero evitar que el propietario anterior use su ID (que obtuvieron válidamente) en otras llamadas ahora que ya no está asignado a ellos.
Supongo que la gente responderá que hay dos problemas aquí:
- No estoy hablando del estado de la sesión aquí sino de la asignación de recursos a los usuarios y del lado del servidor, solo necesito validar que el recurso especificado en una llamada está realmente asociado con ese usuario.
- Aquí hay un problema de enmascaramiento de ID por separado: que si tengo ID internas que no quiero exponer al cliente, debería crear alias de larga duración.
¿Existe un buen conjunto de directrices que cubran los problemas de seguridad específicos que surgen con REST como resultado del almacenamiento del estado de la sesión en el lado del cliente (en lugar de mantenerlo en el lado del servidor)? P.ej. El problema del cliente de confianza no es específico de REST, pero quizás haya aspectos específicos de REST para este y otros problemas que generalmente se deben consciente de.
En la situación específica que he descrito, asignaría UUIDs aleatorios generados por un CSPRNG como alias a mis recursos subyacentes, valide que un recurso dado esté asociado con un usuario cuando se especifique en una llamada y asigne un nuevo alias al recurso subyacente cada vez que se reasigne a otro usuario (un paso que no debería ser necesario dado ese siempre valida la asociación actual de una identificación con un usuario). Sin embargo, con la seguridad, generalmente encuentro que cuando los no expertos piensan que tienen todos los ángulos cubiertos, generalmente se equivocan.