Cómo garantizar la seguridad de la API REST

Las interfaces de programación de aplicaciones web (API) proporcionan el back-end para aplicaciones web y móviles modernas. Las llamadas a la API web representan más del 80% de todo el tráfico web y los ciberdelincuentes se dirigen cada vez más a las API, por lo que garantizar la seguridad de la API web es crucial. Las API REST son el tipo más común de API web para servicios web. Veamos qué puede hacer para garantizar la seguridad de la API REST.

¿Qué es una API REST?

REST (abreviatura de REpresentational State Transfer) es un estilo de arquitectura de software para el desarrollo web, generalmente utilizado con la comunicación HTTP. Las API RESTful (o simplemente API REST) son interfaces de programación de aplicaciones que siguen los principios REST, lo que permite a los clientes y servidores web interactuar con una gran variedad de recursos web. Las API REST utilizan verbos (métodos) HTTP estándar y códigos de estado para proporcionar cierto nivel de estandarización. Se accede a ellos a través de URL HTTP y se utilizan ampliamente para servicios web.

Nota: Las API REST son apátridas, como el propio protocolo HTTP, lo que significa que no almacenan información sobre conexiones o sesiones actuales. Los servicios web RESTful proporcionan formas de acceder y manipular recursos, mientras que la administración de sesiones debe ser manejada por la aplicación.

Dos niveles de seguridad de API REST

Antes de entrar en los detalles técnicos, hay una cosa importante a tener en cuenta. Una API web expone una interfaz a una aplicación web, por lo que debe pensar en la seguridad en dos niveles: el acceso a la API y, a continuación, el acceso a la aplicación.

En el nivel de API, necesita la autenticación, autorización, privilegios de acceso adecuados, etc., para garantizar que solo los clientes permitidos puedan usar la interfaz y ejecutar solo las operaciones permitidas. A nivel de aplicación, debe asegurarse de que los puntos finales de la aplicación (las direcciones URL utilizadas para acceder a la interfaz) no sean vulnerables a los ataques que atraviesan la interfaz o la eluden.

Veamos cómo puede garantizar la seguridad de la API REST en estos dos niveles. Para obtener una descripción detallada de las prácticas recomendadas de seguridad de API, consulte la Hoja de trucos de Seguridad REST de OWASP.

Garantizar un acceso seguro a las API

La mayoría de las API web están expuestas a Internet, por lo que necesitan mecanismos de seguridad adecuados para evitar abusos, proteger los datos confidenciales y garantizar que solo los usuarios autenticados y autorizados puedan acceder a ellas.

Seguridad de conexión

La seguridad comienza con la conexión HTTP en sí. Las API de REST seguras solo deben proporcionar puntos de conexión HTTPS para garantizar que toda la comunicación de la API esté cifrada mediante SSL / TLS. Esto permite a los clientes autenticar el servicio y protege las credenciales de API y los datos transmitidos.

Control de acceso de API

Muchas API web están disponibles solo para usuarios autenticados, por ejemplo, porque son privadas o requieren registro o pago. Debido a que las API REST no tienen estado, el control de acceso lo gestionan los endpoints locales. Los métodos de autenticación de API REST más comunes son:

• Autenticación básica HTTP: Las credenciales se envían directamente en encabezados HTTP en codificación Base64 sin cifrado. Este es el método de autenticación más simple y el más fácil de implementar. También es el menos seguro, ya que los datos confidenciales se transmiten como texto sin formato, por lo que solo se deben usar en combinación con HTTPS.
• Tokens web JSON (JWT): Las credenciales y otros parámetros de acceso se envían como estructuras de datos JSON. Estos tokens de acceso se pueden firmar criptográficamente y son la forma preferida de controlar el acceso a las API REST. Consulte la Hoja de trucos JWT de OWASP para obtener una descripción rápida de los tokens Web JSON, y RFC 7519 para obtener la especificación completa.
• OAuth: Se pueden usar mecanismos estándar OAuth 2.0 para autenticación y autorización. OpenID Connect permite la autenticación segura a través de OAuth 2.0. Por ejemplo, las API de Google utilizan OAuth 2.0 para la autenticación y la autorización.

La autorización de usuario con claves API

Las claves API proporcionan una forma de controlar el acceso a los servicios REST públicos. Los operadores de servicios web públicos pueden usar claves de API para imponer límites de velocidad para llamadas de API y mitigar los ataques de denegación de servicio. Para los servicios monetizados, las organizaciones pueden usar claves de API para proporcionar acceso en función del plan de acceso adquirido.

Restricciones de cliente de API

Para minimizar los riesgos de seguridad, los operadores de servicio REST deben restringir la conexión de los clientes a las capacidades mínimas requeridas para el servicio. Esto comienza restringiendo los métodos HTTP compatibles para asegurarse de que los clientes mal configurados o maliciosos no puedan realizar ninguna acción más allá de la especificación de la API y el nivel de acceso permitido. Por ejemplo, si la API solo permite solicitudes GET, los tipos de solicitudes POST y otros deben rechazarse con el método código de respuesta 405 no permitido.

Protección de aplicaciones que exponen API

Una vez que el cliente tiene acceso legítimo, debe proteger la aplicación web subyacente de entradas mal formadas y maliciosas. Las llamadas y respuestas a la API REST también pueden incluir datos confidenciales que deben controlarse.

Datos confidenciales en la comunicación de API

Las llamadas a API a menudo incluyen credenciales, claves de API, tokens de sesión y otra información confidencial. Si se incluyen directamente en las URL, estos detalles podrían almacenarse en los registros del servidor web y filtrarse si los ciberdelincuentes acceden a los registros. Para evitar filtrar información confidencial, los servicios web RESTful siempre deben enviarla en encabezados de solicitud HTTP o en el cuerpo de la solicitud (para solicitudes POST y PUT).

Validación de tipo de contenido

Continuando con el tema de restricciones de cliente API, los servicios REST deben definir con precisión los tipos de contenido permitidos y rechazar las solicitudes que no tengan las declaraciones correctas en sus encabezados HTTP. Esto significa especificar cuidadosamente los tipos permitidos tanto en el encabezado Content-Type como en el Accept, junto con el conjunto de caracteres (cuando sea posible). Si el servicio incluye JavaScript (u otro código de script), debe asegurarse de que el tipo de contenido en el encabezado sea el mismo que en el cuerpo de la solicitud, por ejemplo application/javascript. Esto ayuda a prevenir ataques de inyección de encabezado.

Encabezados de seguridad de respuesta

Se pueden configurar encabezados de seguridad HTTP adicionales para restringir aún más el tipo y el alcance de las solicitudes. Estos incluyen X-Content-Type-Options: nosniff para evitar ataques XSS basados en la detección de MIME y X-Frame-Options: deny para evitar intentos de clickjacking en navegadores antiguos.

Si el servicio no admite llamadas entre dominios, debe deshabilitar CORS (intercambio de recursos entre orígenes) en sus encabezados de respuesta. Si se esperan tales llamadas, los encabezados CORS deben especificar con precisión los orígenes permitidos.

Validación de entrada

Las API están diseñadas para el acceso automatizado sin interacción del usuario, por lo que es especialmente importante asegurarse de que todas las entradas sean válidas y esperadas. Cualquier solicitud que no se ajuste a la especificación de la API debe rechazarse. Se aplican las directrices de mejores prácticas típicas para la validación de entradas:

• Trate todos los parámetros, objetos y otros datos de entrada como no confiables.
• Utilice la funcionalidad de validación incorporada cuando esté disponible.
• Compruebe el tamaño de la solicitud, la longitud del contenido y el tipo.
• Utilice la escritura fuerte para los parámetros de la API (si es compatible).
• Para evitar la inyección SQL, evite crear consultas manualmente: utilice consultas parametrizadas en su lugar.
• Incluir en la lista blanca valores de parámetros e entradas de cadena siempre que sea posible.
• Registre todos los errores de validación de entrada para detectar intentos de relleno de credenciales.

Por qué es importante la seguridad de la API REST

Las API web son la columna vertebral del desarrollo web y móvil moderno. Permiten que las aplicaciones y los servicios se comuniquen e intercambien datos entre plataformas de hardware y software. Mientras que otros formatos de API también están en uso (por ejemplo, SOAP), las API REST son ahora el tipo dominante, representando más del 80% de todas las API web públicas. Proporcionan el back-end para la mayoría de las aplicaciones móviles y dispositivos IoT y permiten una fácil integración entre sistemas y aplicaciones.

Debido a que utilizan las mismas tecnologías que las aplicaciones web, las API REST pueden ser vulnerables a los mismos ataques. Al mismo tiempo, las API no están diseñadas para el acceso manual, por lo que pueden ser difíciles de probar, especialmente si algunos endpoints y características no están documentados. Las pruebas de seguridad de API requieren herramientas automatizadas precisas para garantizar una cobertura completa. Netsparker proporciona soporte completo para el análisis de vulnerabilidades de la API REST con una variedad de métodos de autenticación y reescritura automática de URL.

Consulte la documentación del sitio de prueba de la API REST de Netsparker para obtener detalles técnicos completos y lea nuestro artículo completo sobre análisis de las API REST en busca de vulnerabilidades con Netsparker.

Sobre el autor

Zbigniew Banach

Escritor de contenido técnico en Netsparker. Basándose en su experiencia como periodista de TI y traductor técnico, hace todo lo posible para llevar la seguridad web a un público más amplio en el blog y el sitio web de Netsparker.