Skip to main content
Seguridad en tus APIs

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 artículo explico cuál es mi visión para enfrentarse a esta problemática de seguridad en tus APIs y cómo GFI puede ayudarte en esta delicada labor.

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.

Generan una cadena de valor de forma sencilla, como muestro a continuación:

cadena de valor de forma sencilla

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.

Ejemplos de casos de uso

En la siguiente figura muestro ejemplo de uso de APIs en diferentes sectores:

uso de APIs en diferentes sectores

Servicios REST

Si tuviera que recomendar un tipo de arquitectura para la creación de APIs, sería sin duda REST. REST es un estilo de arquitectura que abstrae los elementos de dicha arquitectura dentro de un sistema hypermedia distribuido.

Sus 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 de forma muy adecuada para la creación de APIs, siendo por ello la tecnología elegida habitualmente para su implantación:

  • Flexible en cuanto a formato
  • Facilita integración
  • Total desacoplamiento
  • Ligeros

Pero no todo son ventajas

  • La seguridad usada habitualmente WS-* no aplica
  • No existe la concepción de estado
  • La respuesta no está estandarizada
  • Tiene soporte a operaciones consideradas peligrosas como DELETE

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, cometiéndose muchos fallos (sistemas personalizados, reinventando la rueda, etc.). Durante mi experiencia he visto auténticas barbaridades, en sistemas críticos y muy importantes, la falta de madurez, de conocimiento o prisas suelen ser mal consejero.

Habitualmente, si te planteas cómo proteger tus APIs a nivel de autenticación/autorización, te encontrarás con el siguiente dilema:

proteger tus APIs - dilema

En un mundo ideal, la autenticación mutua con SSL sería el marco ideal, pero los problemas que acarrea la gestión de certificados hacen que sea muy difícil su utilización. Quizás para APIs internas y entornos muy controlados y limitados pueda ser la mejor solución.

Sin embargo a nivel global y sobre todo para exponer APIs en Internet, creo que OAuth 2.0 es lo más equilibrado.

OAuth 2.0

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 centrando el foco en el cliente.

Define los siguientes 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

El flujo habitual de trabajo es el siguiente:

flujo habitual de trabajo

En una próxima entrada del blog, profundizaremos en este estándar explicando más a fondo sus características.

Cómo proteger tus APIs con OAuth

Desde mi punto de vista, existen básicamente dos 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)

Para ello, puedes encontrar documentación muy interesante en http://oauth.net/2/.

He trabajado con varios frameworks, algunos 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). Si quieres un buen sitio por donde empezar existe un buen ejemplo en http://projects.spring.io/spring-security-oauth.

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 ello a veces las soluciones “caseras” pueden ser peligrosas).

Existen varios productos tanto Open Source como comerciales que cubren la funcionalidades básicas. En particular he tenido buenas experiencias con WSO2 API Manager.

Cosas a tener en cuenta

Ya tenemos un sistema de autorización adecuado, pero la seguridad va mucho más allá.

Se han de tener en cuenta otros aspectos:

Ataques DOS

Tanto el servidor del recurso como el servidor de autorización pueden ser víctimas con llamadas masivas, pudiendo colapsar el servicio.

El concepto de “throttling” establece umbrales de llamadas por consumidor, ayudando a evitar este tipo de ataques y facilitando estadísticas de uso.

Secuestro de sesión

Por supuesto, es obligatorio el uso de HTTPS, ya que los “Acces Token” se envían en claro. Si no puedes usar HTTPS se puede plantear OAuth 1.0a, pero su implantación es mucho más complicada.

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.

Buenas prácticas en la creación de APIs

Aplicar un procedimiento de buenas prácticas es básico para no caer en errores de novatos y seguir una misma directriz a nivel de empresa. Creo que es así, pero no siempre me encuentro con ellas, y más en tecnologías emergentes.

Por ello, es muy recomendable:

  • Separar los recursos en el API de forma adecuada
  • Usar los verbos adecuadamente, minimizando el uso de verbos peligrosos (DELETE, POST)

Hay artículos muy interesantes sobre buenas prácticas en el desarrollo de APIs, por ejemplo: http://www.restapitutorial.com/lessons/restquicktips.html

 

GFI

Desde GFI, con nuestra experiencia, te podemos apoyar con una gran variedad de servicios sobre APIs.

GFI - servicios sobre APIs

Martín Suárez Méndez

Consultor Senior en Arquitectura e Integración orientado a Seguridad en GFI. Ingeniero en Informática y Master de Seguridad informática. Especialista en Gestión de Identidades, PKI, securización de servicios Web y productos WSO2

Martín Suárez Méndez ha escrito 3 entradas


Martín Suárez Méndez

Consultor Senior en Arquitectura e Integración orientado a Seguridad en GFI. Ingeniero en Informática y Master de Seguridad informática. Especialista en Gestión de Identidades, PKI, securización de servicios Web y productos WSO2

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *