Es seguro para todos los esquemas de autenticación no basados en cookies (por ejemplo, OAuth).

1

Estoy creando una API con puntos finales tanto protegidos como públicos, y la estoy protegiendo con los diversos flujos de OAuth 2. Quiero que esta API esté abierta al mundo: el sitio web principal del consumidor ni siquiera tendrá el mismo origen que el servidor de la API. Así que estoy planeando implementar CORS.

Muchos textos advierten sobre terceros malintencionados que "envían solicitudes como el usuario ", pero no estoy seguro de lo que significan. Supongo que esto es similar a cómo funciona CSRF, ya que las solicitudes se envían con las cookies del usuario.

Si este es el caso, ya que mi esquema de autenticación OAuth 2 usa tokens que se pasan a través del encabezado HTTP o un parámetro GET, ¿no sería esto un problema? Mi servicio ni siquiera toca las cookies.

Cualquier tercero que intente realizar una operación protegida en nombre del usuario no tendrá acceso a un token válido (que se almacena en el almacenamiento local o en la memoria). O a menos que el usuario invoque explícitamente un flujo de OAuth 2, le dé al tercero un token válido y lo use (funcionando como se esperaba) - o no es una operación que requiera el usuario se autenticará, lo que funcionaría (también funcionaría según lo previsto).

Por supuesto, como todos sabemos, cuando asumo que hago una mierda con oh, Dios, estamos comprometidos, hay gatitos en todas partes , así que podría estar equivocado y hay una brecha de seguridad mayor que solo las cookies. Gracias!

    
pregunta bananapeel 28.06.2014 - 11:29
fuente

1 respuesta

1
  

"enviar solicitudes como usuario", pero no estoy seguro de qué quieren decir con eso. Supongo que esto es similar a cómo funciona CSRF

Exactamente.

  

como en, las solicitudes se envían con las cookies del usuario.

CSRF no necesariamente requiere cookies. Es más fácil con las cookies porque se adjuntan automáticamente a cualquier solicitud a un origen en particular.

Si las credenciales de autorización son adivinables o estables, entonces un iframe de terceros puede falsificar una solicitud con ellos. CORS hace que sea más fácil falsificar una solicitud con encabezados que generalmente no son parte de un GET o POST iniciado por el navegador.

Si está realizando la autorización a través de los secretos en la URL, me aseguraría de que su servicio CORS incluya los encabezados apropiados para que no seas vulnerable a rastreo de historial y ataques de canales laterales similares. Los parámetros incorporados de OAuth deben tener suficiente entropía para que estén a salvo de la detección, pero siempre hay una fuga de remitentes de su lado para cuidar, por lo que esos encabezados son una buena idea.

  

Cualquier tercero que intente realizar una operación protegida en nombre del usuario no tendrá acceso a un token válido (que se almacena en el almacenamiento local o en la memoria).

Parece que tienes un control sobre los principales vectores de ataque.

Si se almacena en el almacenamiento local, entonces un XSS en cualquier página con acceso a ese almacenamiento local podría perder el token.

Si no puede mantener el token en un origen que no incluya HTML con contenido de terceros, es posible que haya trucos que pueda hacer con document.domain para limitar la ventana de exposición a los scripts inyectados en cualquier página. que está en el mismo origen que el token.

  1. cargar JS que recupera y secuestra el token utilizando integridad de cierre para proporcionar una API a otros JS en la página sin exponer el valor del token en sí.
  2. cambie el origen de la página para que ya no tenga acceso al almacenamiento local
  3. proceda a ejecutar el resto del script de la página que podría haber inyectado contenido

Además, el CSP puede proporcionar defensa en profundidad en el camino.

    
respondido por el Mike Samuel 28.06.2014 - 14:24
fuente

Lea otras preguntas en las etiquetas