¿Es necesaria la firma de la solicitud (digerir el cuerpo de la solicitud) en una API REST?

Navega tus respuestas
14

Actualmente estoy participando en un debate y me pregunté cuál fue la opinión de la comunidad sobre esto.

  1. Vemos API REST que solo requieren autenticación básica (quizás HTTP) u OAuth.

  2. Vemos las API REST que también requieren una firma; Contiene secreto (s), sello de tiempo, tal vez un nonce.

  3. Ocasionalmente vemos API REST que también requieren que los parámetros de solicitud (ensamblados de una manera específica) se incluyan en la firma.

El número 3 ofrece seguridad completa (aunque en la práctica y en la práctica, ¿hay muchos problemas con el primero?), sin embargo, agrega una mayor complejidad de implementación: reunir los parámetros de solicitud de una manera específica crea una gran oportunidad para estropear las cosas , y puedes decir adiós a "probar rápidamente" la API.

Mi jefe de seguridad diría 've con el número 3, idiota', pero mi jefe de usabilidad dice 'eso es un PITA completo, el número 2 es suficiente en el mundo real y si se usa correctamente, es decir, sobre https, no hay nada que hacer. salga mal '.

    
pregunta Jamie Edwards 15.03.2013 - 17:46
fuente

2 respuestas

7

Desde el servidor, es posible que desee dos cosas:

  1. para asegurarse de que el cliente que envía la solicitud sea efectivamente quien reclama;
  2. para poder demostrar a terceros que quien haya enviado una solicitud determinada sea una entidad cliente específica.

Las firmas digitales son más o menos necesarias para lograr el segundo objetivo. Para el primer objetivo, la autenticación simple es suficiente; HTTP "Autenticación básica", jugado dentro de SSL (HTTPS), es suficiente. Su método "tipo 2" es un tipo de autenticación que se basa en un certificado de cliente; Otro método igualmente bueno, y más sencillo de activar, es utilizar certificados de cliente en el nivel SSL (las bibliotecas SSL luego manejan el negocio de firmas de marcas de tiempo distintas).

Ni el método 1 ni el 2 proporcionan una prueba que podría usarse durante un litigio. La autenticación convence al servidor de que el cliente correcto está en el otro extremo de la línea, pero el servidor no obtiene nada que pueda convencer a un juez. Para eso, realmente necesita una firma en la solicitud, es decir, su "método 3". No es que el método 3 sea "más seguro"; más bien, el método 3 proporciona una funcionalidad adicional que puede o no ser útil para su caso específico.

Además, tenga en cuenta que tener una solicitud firmada no reemplaza completamente la autenticación, aunque solo sea por los ataques de repetición .

    
respondido por el Thomas Pornin 15.03.2013 - 18:26
fuente
1

Si se habla con el servidor usando HTTPS (¡solo con certificados de confianza!), no hay ninguna razón directa para usar ninguno de los métodos más complejos. Una autenticación básica de contraseña simple de texto sin formato es suficiente y segura.

Si no se confía en el canal de comunicación no , por ejemplo, si se permiten los proxies SSL o los certificados no fiables de la empresa, se incluirán todas las partes de la solicitud en la "firma ", incluyendo alguna forma de protección de repetición. Además, la "firma" no debe revelar el secreto de autenticación.

El punto que Thomas plantea sobre la capacidad de respuesta de las solicitudes de los clientes es bueno. Sin embargo, la "firma" en la mayoría de las API de REST que he encontrado no es una firma en absoluto, es un autenticador simétrico que no se presta a la probabilidad (el autenticador puede y debe ser computable por el servidor).

Por lo tanto, a menos que realmente tenga certificados de cliente para los clientes, el método para asegurarse de que el cliente sea el que afirma es de poca relevancia.

    
respondido por el Nakedible 18.03.2013 - 11:47
fuente

Lea otras preguntas en las etiquetas

¿Detectando intentos de atacar un sitio web? ¿Cuáles son las implicaciones del robo de huellas dactilares de 5 millones de personas del Gobierno de los Estados Unidos?