GFI - Seguridad en tus APIs

El desarrollo de APIs en las empresas es muy importante hoy en día. Poder exponer estas APIs no solo de forma interna sino al exterior puede generar a las empresas un gran valor añadido. A veces las tecnologías usadas y la falta de buenas prácticas hacen que no se tomen las medidas de seguridad más adecuadas. En este documento se explica cómo enfrentarse a esta problemática en tus APIs y como GFI puede ayudarte en esta delicada labor

1. Seguridad en tus APIs Soluciones a problemas habituales

2. APIs , el futuro de la Web Servicios REST Seguridad REST OAUTH 2.0 ¿Cómo hacerlo? A tener en cuenta Servicios GFI 2 24/04/2014 Seguridad en tus APIs

3. APIs , el futuro de la Web Un API define unas funciones (iniciar sesión, ver a tus amigos y escribir comentarios, por ejemplo) y sirve para usarse internamente o para permitir que la usen otros. Las APIs abren una parte de la tecnología de una compañía para que pueda ser utilizada por terceros en el desarrollo de nuevos productos Esta cadena de valor, las mejoras que terceros consiguen y la movilidad , hacen que sea prácticamente obligatorio exponer APIs para las grandes empresas. Tecnologías sin estado, menos pesadas hacen que Arquitecturas SOAP vayan dejando paso a A rquitecturas REST para la implantación de estas APIs 3 24/04/2014 Seguridad en tus APIs Cadena de valor Integrador de aplicaciones Proveedor del servicio Consumidor Nuevo canal de relación y venta Posicionamiento de marca Integración rápida con 3º Movilización rápida de servicios Satisfacción del consumidor Ingresos por porcentaje de ventas Ingresos por publicidad Ingresos por descargas Servicio movilizado Servicio personalizado Reconocimiento de marca

4. APIs , el futuro de la Web 4 24/04/2014 Seguridad en tus APIs Los gobiernos y administraciones ofrecen APIs de tipo Open Government con información de la gestión pública y estadísticas. En España algunas CCAA ya ofrecen estos servicios mucho antes de la elaboración del primer borrador de inminente Ley de Transparencia El número de funcionalidades en forma de APIs en el sector turístico es igual de abrumador que el número de aplicaciones móviles disponibles en las stores : seguimiento de vuelos, booking , comparadores, planificadores, guías, bases de datos de hoteles, brokering , checking , críticas y recomendaciones... Los operadores de logística abrieron sus servicios paralelamente a la explosión del comercio electrónico. Todos ofrecen APIs de seguimiento de envíos, validación de direcciones e incluso estimación de precios de tasas e impuestos para envíos internacionales. En banca hay movimientos incipientes para ofrecer APIs básicos para gestión de servicios esenciales como cuentas y tarjetas, por ahora restringidos a la consulta de posición global, saldo y movimientos. Las operadoras de telco están abriendo los servicios de sus redes de telefonía para mensajería y localización principalmente. Algunas operadoras proporcionan un servicio de pagos que se adjuntan a la factura mensual del contrato del cliente. El sector inmobiliario ofrece sus productos más allá de los portales especializados, ahora como APIs públicos. Los retailers abren al público sus catálogos de productos, directorios y ofertas. Alrededor del eCommerce surgen APIs para pagos, recomendaciones, fidelización, críticas, comparadores, subastas y publicidad. Las grandes empresas de internet como Google, facebook , Twitter , LinkeIn y demás ofrecen todo tipo de APIs para convertir en social cualquier experiencia en la web.

5. Servicios REST REST es un estilo de arquitectura que abstrae los elementos de dicha arquitectura dentro de un sistema hypermedia distribuido Principios Básicos: Arquitectura cliente-servidor Utiliza los métodos HTTP de manera explícita No mantiene estado pero si cacheable Interfaz uniforme. Expone URIs con forma de directorios Transfiere XML, JavaScript Object Notation (JSON), o ambos Sus beneficios se ajustan para la creación de APIs Flexible en cuanto a formato Facilita integración Total desacoplamiento Ligeros No todo son ventajas Seguridad ( WS-* y sin estado ) ¡Seguridad personalizada! Respuesta no estandar Soporte HTTP como DELETE (peligroso) 5 24/04/2014 Seguridad en tus APIs

6. Seguridad REST Existen muchas recomendaciones sobre seguridad en servicios SOAP pero nada de ello aplica directamente sobre REST Debido a este problema, cada desarrollador investiga una forma EL DILEMA FUENTE : Blog Intel. http ://blogs.intel.com/application-security/2012/05/11/enterprise-apis-and-oauth-have-it-all / Autenticación mutua SSL Seguridad: Alta Impacto: Muy alto Gestión: Muy alto Desarrollador: “Odio mi vida” Resultado: No se usa y no da valor a la empresa HTTP Básico con SSL Seguridad: Media-baja Impacto: Alto Gestión: Alto Desarrollador: “¿Realmente, hacemos esto?” Resultado: Sospechosa seguridad OAuth Seguridad: Media Impacto: Media baja Gestión: Media Desarrollador: “Amo mi trabajo. ¡ Es como Facebook!” Resultado: Se usa rápidamente y evita impactos con contraseñas Custom Seguridad: Media-baja Impacto: Media Gestión: Medio-alto Desarrollador: “No es Oauth, pero por lo menos no es X509” Resultado: Uso razonable, no estandard 6 24/04/2014 Seguridad en tus APIs

7. OAUTH 2.0. Básico El marco de autorización OAuth 2.0 permite a aplicaciones de terceros solicitar acceso limitado a un servicio HTTP. Basado en RFC6749 aprobado por IETF Evoluciona OAuth 1.0 y 1.0a, simplificándolo y centrado el foco en el cliente Roles: Propietario del recurso . Entidad capaz de conceder acceso a un recurso protegido (usuario) Servidor de recurso . Almacena los recursos protegidos Cliente . Aplicación que accede al recurso protegido Servidor de Autorización . Servidor que emite “Access token ” al cliente Funcionamiento Básico: Cliente Servidor de recurso Servidor de Autorización 1 Petición de autorización 2 Concesión 3 Concesión 4 Access token 5 Access token 6 Acceso al recurso protegido 7 24/04/2014 Seguridad en tus APIs

8. OAUTH 2.0. Características 8 24/04/2014 Seguridad en tus APIs Cuando usarlo Aplicaciones de terceros Aplicaciones nativas Aplicaciones móviles No es necesario en: API solo son consumidas en entornos servidor-servidor (usar seguridad perimetral, certificados, etc ) API siempre consumida desde la misma aplicación Beneficios No se comparten contraseñas entre consumidores No existen contraseñas en almacenes de móviles Minimiza o limita los impactos de seguridad Perdida o robo de dispositivo móvil, el usuario puede revocar el acceso Si el cliente es “pirateado”, el usuario puede revocar el acceso Si el API es “pirateada”, el usuario puede cambiar su contraseña en el servidor de autorizaicón y/o revocar acceso A continuación se explica como obtener el “Access token ”, en diferentes escenarios que contempla OAUTH2.0, en función del cliente y/o el entorno Habitualmente existe una fase de registro de clientes para su identificación

9. OAUTH 2.0. Autorization Code Cliente Servidor de Autorización 1 Identifica cliente y redirecciona 2 Autenticación usuario 4 Credenciales cliente , Código Autorización, y URL 9 24/04/2014 Seguridad en tus APIs U n código de autorización es obtenido del servidor de autorización y usado entre el cliente y el usuario. En vez de solicitar acceso directamente, el cliente redirecciona al usuario al Servidor de Autorización (mediante un Agente normalmente navegador) El usuario autentica y autoriza el acceso, obteniendo así el código de autorizaci ón . Con este código se puede obtener el “Access Token ” Este tipo de autorización tiene grandes beneficios y es el más recomendado, ya que nunca se comparte las credenciales con el cliente, pero requiere de la capacidad de redirección. Muy recomendado para Aplicaciones Web Agente 2 3 Código Autorización 3 1 5 Access token

10. OAUTH 2.0. Implicit 10 24/04/2014 Seguridad en tus APIs Este tipo de concesión simplifica el flujo de “ Authorization Code ”, ajustándose a clientes implementados en un navegador tipo script . En esta caso el “Access Token ” es emitido directamente después de la autenticación. El cliente no es autenticado, debido a que no es confidencial , pero se puede validar la redirección de la URL y campos adicionales Debe usarse de forma cuidadosa, debido a que el “Access Token ” es transmitido en la URI, y por posibles manipulaciones de los campos de comprobación. Cliente Servidor de Autorización 1 Identifica cliente y redirecciona 2 Autenticación usuario User Agent 2 7 1 Servidor con script cliente 3 Redirección con Access Token 4 Redirección 5 Script 6

11. OAUTH 2.0. Password Cliente Servidor de Autorización 1 Credenciales usuario 2 Credenciales usuario y cliente 3 Access token “ Resource Owner Password Credentials ” ( Password ), es un tipo de autorización que se ajusta donde el propietario del recurso y el cliente tiene una relación de confianza . Gracias a las credenciales del usuario y las claves del cliente se puede obtener un “Access token ” Es peligroso porque las credenciales pasan por el cliente (podría hacer con ellas lo que quisiera) Debería ser usado en clientes de absoluta confianza (gestionados por el propio proveedor). Aunque a veces s e usa a veces en móviles (peligroso , aunque los grandes distribuidores de software dan cierta confianza Google Play o Apple Store), mejor usar el escenario “ Autorization code ” 11 24/04/2014 Seguridad en tus APIs

12. OAUTH 2.0. Client Credentials Cliente Servidor de Autorización 1 Credenciales cliente 2 Access token “ Client credentials ”, es un tipo de autorización que se ajusta en clientes de absoluta confianza (aplicaciones internas o externas pero confidenciales, propia aplicación del proveedor ) donde el usuario no importa. Solo con las credenciales del cliente se puede obtener un “Access token ” Es peligroso porque las credenciales pueden estar expuestas (de ahí solo usar entornos de confianza) En este contexto el usuario desaparece del protocolo. 12 24/04/2014 Seguridad en tus APIs

13. OAUTH 2.0. Otros 13 24/04/2014 Seguridad en tus APIs Se definen extensiones en el estándar con otras opciones para el intercambio de “Access token ” Las más destacables son: Refresco de “Access token ” Habitualmente cuando se obtiene un “Access token ” se suele obtener un objeto formateado como JSON, uno de los campos es validez del objeto y otro “ Refresh token ”, con el cual un cliente podría recuperar otro “Access token ” valido transcurrido el tiempo de validez. Este escenario puede ser peligroso, y debería limitarse su utilización ya que se podría refrescar indefinidamente sin realizar el flujo de autorización completo. SAML Mediante aserciones SAML, se puede recuperar un “Access token ”, habilitando de una forma sencilla y estandarizada la cualidad de “Single Sign On ” De esta forma se puede combinar SAML y OAUTH. Este escenario es muy interesante y potente, pero un poco complejo, por ello es importante plantearse si los requerimiento de seguridad lo necesitan. Sobre todo teniendo en cuenta que en entornos de movilidad SAML (debido al peso del protocolo) no es recomendable.

14. ¿Como hacerlo? Existen varias alternativas para implantar una solución de securización de APIs : Hazlo tú mismo : Delegar el servicio de Autorización a un tercero (Google, Facebook, etc ) y hacer filtros para tus APIs Impleméntalo tú mismo, con frameworks validados para ello (Spring Security, PHP OAuth 2.0) Existe documentación interesante en http://oauth.net/2/ Algunos frameworks están más maduros que otros, en general aún están verdes, salvo librerías con terceros (Google por ejemplo es un muy buen ejemplo) Gestión de APIs Esta solución además de securizar tus APIs introduce el concepto de gobierno de APIs y de consumidores A la hora de exponer APIs en Internet es importante tener un sistema con un servicio muy fuerte en seguridad y mínima latencia (por ellos a veces las soluciones “caseras” pueden ser peligrosas ) Existen varios productos tanto Open Source como comerciales que cubren la funcionalidades básicas. Ejemplo WSO2 API Manager 14 24/04/2014 Seguridad en tus APIs

15. A tener en cuenta… Ataques DOS Tanto el servidor del recurso como el servidor de autorización pueden ser victimas con llamadas masivas, pudiendo colapsar el servicio. El concepto de “ throttling ” , establece umbrales de llamadas por consumidor, ayudando a evitar ataques y/o estadísticas de uso. Secuestro de sesión Obligatorio uso de HTTPS (envío de cookies solo por SSL) Ataques CSRF Con redirecciones del navegador se pueden conseguir ataques CSRF http ://tools.ietf.org/html/rfc6749#page-43 Existen campos adicionales definidos en OAUTH, para validar acciones y evitar así ataques de este tipo, los clientes deben tener en cuenta estas validaciones. Restringir llamadas peligrosas ( buenas practicas creación APIs ): Minimizar uso de POST, identificado muy bien “verbos” Cuidado con uso de Ajax (https :// developer.chrome.com/extensions/xhr) Limitar tipos validos de peticiones (DELETE especialmente) 15 24/04/2014 Seguridad en tus APIs

16. Servicios GFI Definición, desarrollo y securización de APIs Asesoramiento en desarrollo REST Medición y evaluación del retorno de APIs Asesoramiento en seguridad REST Prospección de candidatos a API Soluciones de gestión APIs Definición, desarrollo de APIs 16 24/04/2014 Seguridad en tus APIs Buenas practicas para tus APIs

17. Más información: www.gfi.es | [email protected] | @ GFI_Informatica | facebook.com/ gfiinformatica