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. www.gfi.es
Seguridad en tus APIs
Soluciones a problemas habituales

2. Contenido
 APIs, el futuro de la Web
 Servicios REST
 Seguridad REST
 OAUTH 2.0
 ¿Cómo hacerlo?
 A tener en cuenta
 Servicios GFI
224/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 Arquitecturas REST para la implantación de estas APIs
324/04/2014 Seguridad en tus APIs
Cadenadevalor
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
424/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ític
as, 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)
524/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
624/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
724/04/2014 Seguridad en tus APIs

8. OAUTH 2.0. Características
824/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
924/04/2014 Seguridad en tus APIs
> 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
Agente2
3 Código Autorización
3
1
5 Access token

10. OAUTH 2.0. Implicit
1024/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
Agent2
7
1
Servidor con
script cliente
3 Redirección con Access Token
6

11. OAUTH 2.0. Password
Cliente
Servidor de
Autorización
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”
1124/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.
1224/04/2014 Seguridad en tus APIs

13. OAUTH 2.0. Otros
1324/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
1424/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)
1524/04/2014 Seguridad en tus APIs

16. Servicios GFI
Definición, des
arrollo 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
1624/04/2014 Seguridad en tus APIs
Buenas
practicas
para tus APIs

17. Más información:
www.gfi.es | marketing@gfi.es | @GFI_Informatica | facebook.com/gfiinformatica