¿Cómo proteger los servicios web RESTful?
Tengo que implementar secure RESTful web services. Ya hice algunas investigaciones usando Google, pero estoy atascado.
Opciones:
TLS (HTTPS) +
- HTTP Basic (pc1oad1etter)
- HTTP Digest
- de dos patas OAuth
- un enfoque basado en cookies
- certificados de cliente (Tom Ritter y aquí )
- Solicitudes firmadas utilizando HMAC y a limited vida útil
¿Hay más opciones posibles a considerar? Si OAuth entonces, ¿qué versión? ¿Acaso importa? Por lo que he leído hasta ahora OAuth 2.0 con tokens al portador (es decir, sin firmas) parece ser inseguro.
He encontrado otro artículo muy interesante sobre Autenticación basada en REST.
3 answers
Hay otro método muy seguro. Son certificados de cliente. ¿Sabe cómo los servidores presentan un certificado SSL cuando se pone en contacto con ellos en https? Los servidores Well pueden solicitar un cert de un cliente para que sepan que el cliente es quien dicen ser. Los clientes generan certificados y se los dan a través de un canal seguro (como entrar en su oficina con una llave USB, preferiblemente una llave USB sin troyanos).
Carga la clave pública de los certificados de cliente cert (y sus firmantes certificado (s), si es necesario) en su servidor web, y el servidor web no aceptará conexiones de nadie excepto las personas que tienen las claves privadas correspondientes para los certificados que conoce. Se ejecuta en la capa HTTPS, por lo que incluso puede omitir completamente la autenticación a nivel de aplicación como OAuth (dependiendo de sus requisitos). Puede abstraer una capa y crear una Autoridad de certificación local y firmar solicitudes de Cert de los clientes, lo que le permite omitir la opción ' make ellos entran en la oficina' y 'cargar certificados en el servidor' pasos.
¿Te duele el cuello? Absolutamente. Bueno para todo? No. Muy seguro? Sip.
Sin embargo, se basa en que los clientes mantengan seguros sus certificados (no pueden publicar sus claves privadas en línea), y generalmente se usa cuando vende un servicio a los clientes en lugar de permitir que alguien se registre y se conecte.
De todos modos, puede que no sea la solución que estás buscando( probablemente no lo sea para ser honesto), pero es otra opcion.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-01-27 17:04:01
HTTP Basic + HTTPS es un método común.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-01-27 16:46:21
Si elige entre las versiones de OAuth, vaya con OAuth 2.0.
Los tokens OAuth bearer solo deben usarse con un transporte seguro.
Los tokens OAuth bearer solo son tan seguros o inseguros como el transporte que cifra la conversación. HTTPS se encarga de proteger contra los ataques de repetición, por lo que no es necesario que el token portador también se proteja contra la repetición.
Si bien es cierto que si alguien intercepta su token de portador puede hacerse pasar por usted al llamar a la API, hay muchas maneras de mitigar ese riesgo. Si le da a sus tokens un período de caducidad largo y espera que sus clientes almacenen los tokens localmente, tiene un mayor riesgo de que los tokens sean interceptados y utilizados indebidamente que si le da a sus tokens un vencimiento corto, requiere que los clientes adquieran nuevos tokens para cada sesión y aconseja a los clientes que no persistan los tokens.
Si necesita proteger cargas útiles que pasan a través de múltiples participantes, entonces necesita algo más que HTTPS / SSL, ya que HTTPS / SSL solo encripta un enlace del gráfico. Esto no es culpa de OAuth.
Los tokens de portador son fáciles de obtener para los clientes, fáciles de usar para las llamadas a la API y se usan ampliamente (con HTTPS) para proteger las API públicas de Google, Facebook y muchos otros servicios.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-04-17 19:23:24