El token de identificación contiene información confidencial enviada por el método GET

Question

El token de identificación contiene información confidencial enviada por el método GET

#1 de Geir Emblemsvag (2 votos)

1

Descubrí que mi sitio web usa id_token y contiene información del usuario. Uno de ellos es mi número de teléfono, que creo que podría ser una información confidencial. Porque, si los atacantes pueden capturar la solicitud, obtienen mi id_token y la descodifican. Tienen mi correo electrónico (obviamente) y mi número de teléfono que creo que no debería estar allí. Estoy confundido de que si se divulga mi número de teléfono, ¿se considera una vulnerabilidad?

email: "[email protected]",
 email_verified: false,
 phone_number: "+372591114xxx",
 firebase: {
  identities: {
   phone: [
    "+372591114xxx"
   ],
   email: [
    "[email protected]"
   ]
  },
  sign_in_provider: "custom"
 }
}.
[signature]

disclosure

pregunta Ender 14.12.2018 - 05:47

fuente

1 respuesta

Lea otras preguntas en las etiquetas disclosure

¿Qué tan seguro es usar el reenvío de puertos para VNC? ¿Inyección de comandos cuando se escapan todos los caracteres peligrosos?

score 2 · Answer 1

Pasar información confidencial o personal como parámetros de consulta generalmente se considera un problema, ya que se revela de muchas maneras que los datos de POST no lo son. Consulte, por ejemplo, la pregunta similar " Debe datos confidenciales ¿Alguna vez se pasó en la cadena de consulta? "OWASP tiene una breve descripción del problema: Exposición de la información a través de cadenas de consulta en url .

Los principales problemas generalmente se consideran

Marcadores e historial del navegador si alguien tiene acceso al navegador
Acceda a los registros en el destinatario deseado de la consulta (o cualquier proxy entre usted y el destinatario)
Que los parámetros de consulta se incluyan en el encabezado del "remitente" enviado a otros servidores.

Lo que hace que este caso sea particularmente interesante es que la información en cuestión es en realidad un token de identificación firmado. Posiblemente pueda usarse para autenticar a los usuarios en otros proveedores de servicios (aunque esto requiere una implementación defectuosa en un proveedor de servicios, un tipo de agente confuso problema).

La inclusión de tokens de ID de esta manera es realmente recomendada por el estándar OpenID Connect, como el id_token_hint . Se puede POSTAR, pero la mayoría de las implementaciones (pocas como son) que he visto, usan parámetros de consulta. Por lo tanto, hacer que los desarrolladores de tu servicio cambien esto podría ser un reto.