gfi - seguridad en tus apis

www.gfi.es

Seguridad en tus APIsSoluciones a problemas habituales

Contenido

12/04/2023

APIs, el futuro de la Web Servicios REST Seguridad REST OAUTH 2.0 ¿Cómo hacerlo? A tener en cuenta Servicios GFI

2Seguridad en tus APIs

12/04/2023

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 Arquitecturas REST para la implantación de estas APIs


Cade

na d

e va

lor

Integrador de aplicaciones

Proveedor del servicio Consumidor

Nuevo canal de relación y ventaPosicionamiento de marcaIntegración rápida con 3ºMovilización rápida de serviciosSatisfacción del consumidor

Ingresos por porcentaje de ventasIngresos por publicidadIngresos por descargas

Servicio movilizadoServicio personalizadoReconocimiento de marca

12/04/2023

APIs, el futuro de la Web


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.

12/04/2023

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)


12/04/2023

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 SSLSeguridad: AltaImpacto: Muy altoGestión: Muy altoDesarrollador: “Odio mi vida”Resultado: No se usa y no da valor a la empresa

HTTP Básico con SSLSeguridad: Media-bajaImpacto: AltoGestión: AltoDesarrollador: “¿Realmente, hacemos esto?”Resultado: Sospechosa seguridad

OAuthSeguridad: MediaImpacto: Media bajaGestión: MediaDesarrollador: “Amo mi trabajo. ¡Es como Facebook!”Resultado: Se usa rápidamente y evita impactos con contraseñas

CustomSeguridad: Media-bajaImpacto: MediaGestión: Medio-altoDesarrollador: “No es Oauth, pero por lo menos no es X509”Resultado: Uso razonable, no estandard


12/04/2023

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


12/04/2023

OAUTH 2.0. Características


> 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

12/04/2023

OAUTH 2.0. Autorization Code

Cliente


1 Identifica cliente y redirecciona

2 Autenticación usuario

4 Credenciales cliente, Código Autorización, y URL


> Un 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

Agente23 Código Autorización

31

5 Access token

12/04/2023

OAUTH 2.0. Implicit


> 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


1 Identifica cliente y redirecciona

2 Autenticación usuarioUser

Agent2

71

Servidor con script cliente

3 Redirección con Access Token

4 Redirección5 Script

6

12/04/2023

OAUTH 2.0. Password

ClienteServidor 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 se 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”


12/04/2023

OAUTH 2.0. Client Credentials

ClienteServidor 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/04/2023

OAUTH 2.0. Otros


> 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.

• SAMLMediante 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.

12/04/2023

¿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


http://wso2.com/products/api-manager/

12/04/2023

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)


12/04/2023

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

APIsDefinición,

desarrollo de APIs


Buenas practicas

para tus APIs

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

gfi - seguridad en tus apis

Technology