Lista de Verificación de Seguridad de API REST

Las pruebas de seguridad de API REST son la práctica de demostrar que un usuario que ha iniciado sesión no puede alcanzar lo que no le pertenece. Importan porque la mayoría de los ataques llegan exactamente desde esa posición, y no desde una irrupción. Su pantalla de inicio de sesión puede ser impecable mientras el endpoint que está detrás entrega a un cliente de pago la factura de otra persona.

Encontrar ese tipo de brecha no necesita nada especializado, solo dos cuentas corrientes y una herramienta capaz de enviar solicitudes. La parte difícil es repetir ese trabajo antes de cada versión, sin faltar ninguna. Muchos equipos lo consiguen durante unos meses y luego lo dejan en silencio, y por eso vale la pena tener un socio de QA dedicado. Nuestros servicios de pruebas de penetración van aún más lejos cuando lo que está en juego exige un experto externo.

Cómo probar la autenticación y la autorización en cada endpoint

La autenticación pregunta quién es usted. La autorización pregunta qué se le permite hacer una vez que el sistema lo sabe. Todos los usuarios se encuentran con la pantalla de inicio de sesión, así que la primera se construye con cuidado y suele funcionar. La segunda se comprueba en los endpoints en los que alguien pensó y se omite en aquellos en los que nadie pensó.

Salt Labs siguió un año de ataques reales y descubrió que el 95% procedía de fuentes autenticadas, así que quienes deben preocuparle ya están dentro.

La lista de verificación de seguridad de API REST empieza aquí, donde cada comprobación tiene la misma forma: enviar una solicitud que debería ser rechazada, desde alguien que no tiene derecho a hacerla.

• Llame a cada endpoint sin ninguna credencial. Todo lo que responda con datos en lugar de un rechazo es un hallazgo.
• Repita con una credencial caducada y después con una que pertenezca a otra cuenta.
• Inicie sesión como usuario corriente y solicite un endpoint reservado al administrador directamente por su dirección, sin acercarse a la interfaz.
• Confirme que una credencial deja de funcionar en el momento en que alguien cierra sesión o un administrador desactiva la cuenta.
• Compruebe la ruta de restablecimiento de contraseña por ambos extremos. Un enlace que sigue siendo válido después de usarse, o que puede solicitarse para una dirección que no es suya, echa por tierra todo lo demás de esta lista.

El patrón que conviene recordar es que una API correcta rechaza. No devuelve una lista vacía, un registro parcial ni un mensaje amable que explique lo que casi obtuvo. Esos fallos por poco le dicen a un atacante que la dirección era real y que merece otro intento.

Vulnerabilidad BOLA: cuando un identificador devuelve los datos de otra persona

Aquí está la vulnerabilidad de API REST más común, y tiene un nombre feo: autorización rota a nivel de objeto, abreviada normalmente como BOLA.

La idea es más simple que el término. Las direcciones web de una API REST suelen nombrar el registro que usted pidió, así que una factura puede estar en /invoices/8812. Existe una vulnerabilidad BOLA cuando un cliente con sesión iniciada cambia ese número a 8813 y lee el extracto de otra empresa. El inicio de sesión funcionó exactamente como se diseñó. Lo que nunca ocurrió fue una segunda comprobación, la que pregunta si ese cliente era el dueño de ese registro.

BOLA es la versión API de un problema más amplio, que tratamos en nuestro artículo sobre el control de acceso defectuoso. Salt Labs lo cuenta junto a los fallos de inyección, donde un atacante esconde una orden dentro de un campo de formulario corriente. Entre los dos sumaron el 37% de todos los problemas reportados, la mayor proporción individual.

Probar BOLA es poco vistoso y rápido:

• Cree dos cuentas corrientes. Inicie sesión con la primera y anote los identificadores que le pertenecen legítimamente.
• Solicite los identificadores de la segunda cuenta sin dejar de estar dentro de la primera. Hágalo para leer, actualizar y eliminar, porque muchas API protegen una de esas acciones y olvidan las demás.
• Pruebe identificadores que no sean de nadie y otros de un rango vecino. Una respuesta que distinga entre “no es suyo” y “no existe” revela qué registros son reales.
• Repita en cada endpoint que acepte un identificador, incluidos informes, exportaciones y adjuntos. Estos se pasan por alto porque parecen funciones y no datos.
• Compruebe también las direcciones anidadas. Proteger /orders/88 sirve de poco si /orders/88/items responde a cualquiera.

Automatizar estas comprobaciones se paga solo, ya que las mismas dos cuentas pueden impulsar cientos de solicitudes emparejadas en cada versión. Escribir y mantener esas pruebas es lo que hace nuestro equipo de pruebas de automatización.

Cómo probar la limitación de tasa en una API REST

Un límite de tasa es un tope sobre la frecuencia con la que un solo llamante puede pedir. Sin él, un único script puede adivinar contraseñas toda la noche, agotar un servicio de pago que usted revende o simplemente dejar sin servidor a todos los demás.

Cuando un llamante supera el tope, la respuesta correcta es el código de estado 429, que significa “demasiadas solicitudes”. Las respuestas equivocadas son una página lenta, un tiempo de espera agotado o un error 500 que informa de una caída en lugar de un rechazo deliberado.

Las comprobaciones que siguen empujan la API más allá de su límite, así que ejecútelas contra un entorno de pruebas y no contra producción.

• Envíe una ráfaga de solicitudes muy por encima de lo que produciría un cliente real y confirme después que recibe respuestas 429 en lugar de silencio.
• Verifique que el límite se aplica por cuenta y por dirección, no solo de forma global. Un tope global por sí solo permite que un llamante abusivo degrade el servicio de todos.
• Machaque específicamente las rutas de inicio de sesión y restablecimiento de contraseña. Merecen límites más estrictos que el resto, porque ahí es donde adivinar resulta rentable.
• Mire los endpoints costosos por separado. Una búsqueda o un informe que consume un segundo de servidor necesita un techo más bajo que uno que devuelve un nombre.
• Confirme que el límite se reinicia de forma sensata y le dice al llamante cuándo volver a intentarlo, para que los clientes legítimos se retiren en lugar de entrar en bucle.

Los límites de tasa también le protegen de sus propios clientes. Su software puede seguir enviando la misma solicitud fallida sin pausa alguna. Desde el lado de su servidor, eso se parece exactamente a un ataque.

Validación de entrada: qué hace su API con una solicitud incorrecta

Cada campo que acepta su API es un lugar donde alguien puede poner un valor que usted no esperaba. Las pruebas funcionales cubren los valores que enviaría su propia aplicación, que es la mayor parte de lo que produce un cliente real. Sin embargo, nadie escribe un nombre de miles de caracteres, pide menos cinco unidades de algo ni elige una fecha de entrega en el año 3000, así que su API nunca los ve en uso normal.

Tarde o temprano alguien los envía de todos modos, ya sea un atacante tanteando o un programa que se estropea. El daño rara vez es dramático. Lo más habitual es que la API guarde el disparate y algo en otra parte del sistema se rompa semanas después, o que devuelva un error tan detallado que nombre su base de datos y su versión.

Para probar esto, alimente el endpoint con valores que nunca debería aceptar y observe cómo responde.

• Envíe el tipo equivocado en cada campo: texto donde va un número, un número donde va una fecha, nada en absoluto donde se exige algo.
• Envíe valores muy fuera del rango sensato, incluidos negativos, cero y longitudes que lleguen a los megabytes.
• Envíe campos que el endpoint nunca documentó. Una actualización que acepta en silencio is_admin o credit_limit permite que un cliente se ascienda a sí mismo, y merece una mirada en cada endpoint que guarde datos.
• Envíe caracteres que signifiquen algo para una base de datos o una línea de comandos. La inyección funciona exactamente así, así que confirme que vuelven como texto plano y no como instrucciones.
• Lea los mensajes de error. Un rechazo debería decir que la solicitud estaba mal, no nombrar la biblioteca que la rechazó ni la tabla contra la que falló.

El fallo que busca es una API que confía en su propio front end. Si su propia aplicación nunca envía un valor incorrecto, puede que al endpoint que hay detrás nunca se le haya pedido decir que no.

CORS, JWT y exceso de información: tres formas en que las API REST filtran datos

Tres cosas explican la mayor parte de la exposición accidental, y ninguna implica que un atacante rompa nada.

CORS significa intercambio de recursos de origen cruzado. Un navegador normalmente impide que un sitio web lea datos que pertenecen a otro, y CORS es la forma en que su API concede una excepción. Configurado para aceptar a todo el mundo, invita a cualquier página de internet a hacer solicitudes usando la sesión de un visitante. Confirme que la lista permitida solo nombra sus dominios reales, que las credenciales se permiten únicamente para esos y que nadie dejó atrás una regla abierta después de depurar.

JWT significa token web JSON. Funciona como un pase: su API entrega uno tras el inicio de sesión y la aplicación lo envía con cada solicitud posterior. Una firma demuestra que el token es auténtico y no ha sido alterado, así que su servidor nunca tiene que volver a pedir la contraseña. Ese atajo pone cuatro cosas en su lista:

• Confirme que los tokens caducan y que uno antiguo se rechaza de verdad en lugar de aceptarse con una advertencia.
• Verifique que la firma se comprueba. Una API que acepta un token que declara no tener ninguna es un fallo conocido y grave.
• Compruebe qué lleva el token. Cualquiera que lo tenga puede leer su contenido, así que una dirección de correo está bien y una contraseña o una nota interna no.
• Asegúrese de que cerrar sesión, o que un administrador revoque el acceso, termina la sesión antes de que el token caduque por sí solo.

El exceso de información significa una respuesta que lleva más datos de los que la pantalla llega a mostrar. Un cliente ve su nombre y el total del pedido, mientras que la respuesta que hay detrás también contiene una calificación crediticia, el precio de coste de un proveedor o la dirección de correo de otro cliente. Nada de eso aparece en pantalla y todo ello llegó igualmente al navegador. Salt Labs situó la exposición de datos sensibles en el 34% de los problemas reportados, justo por detrás del 37% de los fallos de autorización e inyección. Lea la respuesta en bruto de cada endpoint que devuelva un registro y compárela con lo que ese usuario tiene derecho a ver.

Pruebas de seguridad de API REST en un producto en producción

Un proyecto de cliente muestra toda la lista en funcionamiento. Union54 emite tarjetas de pago para empresas fintech de toda África. Cuando nos incorporamos, el producto no tenía front end alguno, así que cada comprobación se ejecutó directamente contra los endpoints. Esa es la posición en la que acaba siempre que la interfaz va por detrás del back end, o nunca llega a construirse. Nuestra práctica de pruebas de API pone las comprobaciones de seguridad en la misma pasada que las funcionales, en lugar de dejarlas para más tarde.

El trabajo manual se hizo con Postman, que encaja con una API en la que no hay nada que pulsar. La automatización empezó en Mocha y pasó a Cypress cuando la suite creció y la estabilidad se convirtió en el problema. Ese cambio conviene hacerlo pronto y no tarde. Al final, la cobertura automatizada alcanzó el 90% de los endpoints en más de 1.500 escenarios. La colaboración sacó a la luz más de 190 defectos, todos dentro de una ventana de dos meses fijada por la demostración a inversores del cliente.

Uno de esos defectos muestra por qué importa leer las respuestas. Una tarjeta volvía informando de un saldo de cero y un estado de emitida, mientras que la base de datos que había detrás guardaba un saldo positivo y un estado de detenida. Ambas respuestas estaban bien formadas y ninguna parecía rota. Solo comparar la respuesta con el registro subyacente reveló que al llamante se le estaba diciendo algo falso sobre su propio dinero.

Esa comparación es el hábito que enseña esta lista. El trabajo funcional pregunta si llega una respuesta. El trabajo de seguridad pregunta si debería haber llegado.

Dónde se detiene la lista de verificación de seguridad de API REST

Recorra esta lista en cada versión y encontrará los problemas caros mientras todavía sale barato arreglarlos. Una suite funcional no informa de ninguno de ellos, porque por lo que ella puede ver cada respuesta llegó exactamente como se diseñó.

Tres actividades se meten en el mismo saco bajo el nombre de “pruebas de API”, y saber cuál está comprando importa:

La fila del medio es lo que acaba de recorrer. Nuestra lista de comprobación de pruebas de API REST se ocupa de la primera. Las dos encajan bien, ya que muchas comprobaciones de seguridad son una prueba funcional que funciona con el resultado esperado invertido.

REST no es la única forma de construir una API. Para los mismos problemas en GraphQL, gRPC y SOAP, nuestra guía sobre pruebas de seguridad de API recorre el OWASP API Top 10, la clasificación estándar del sector de los riesgos de API.

Comprar la tercera fila es una decisión aparte. Ese tipo de colaboración encaja con una gran versión, una entrada en un mercado regulado o un comprador empresarial que quiere pruebas antes de firmar. Rinde más una vez que su propia gente ha despejado los hallazgos fáciles, ya que pagar a un experto para que los redescubra es dinero desperdiciado.

¿Siente curiosidad por saber qué revelan sus endpoints a un llamante con sesión iniciada que se pone a buscar? Reserve una revisión con nuestro equipo de QA.

Preguntas Frecuentes

¿Qué son las pruebas de seguridad de API REST?

Las pruebas de seguridad de API REST preguntan cómo podría un usuario con sesión iniciada abusar de una API REST en lugar de simplemente usarla. Cubren la aplicación de permisos en cada endpoint, si un cliente puede alcanzar los registros de otro, los topes de solicitudes, el manejo de tokens y lo que revelan las respuestas. Las pruebas funcionales demuestran que la API funciona. Una prueba de penetración es una colaboración especializada, acotada y aparte.

¿Qué es una vulnerabilidad BOLA?

BOLA significa autorización rota a nivel de objeto. Ocurre cuando un usuario con sesión iniciada solicita un registro que no es suyo, a menudo un informe o un archivo adjunto cuya dirección contiene un identificador, y la API se lo entrega igualmente. El inicio de sesión funciona y la pregunta sobre la propiedad simplemente no se hace nunca. Es el fallo más común en las API REST y el más fácil de probar.

¿En qué se diferencian las pruebas de seguridad de API REST de las pruebas de penetración?

La diferencia está en quién paga y con qué frecuencia ocurre. Las pruebas de seguridad son trabajo que su propio equipo ya hace, así que se ejecutan en cada versión. Las pruebas de penetración son una colaboración acotada que usted compra: especialistas externos atacan el sistema deliberadamente, así que ocurren mucho menos a menudo. Despejar primero sus propios hallazgos mantiene ese presupuesto apuntado a problemas que su equipo nunca habría podido detectar.

¿Con qué frecuencia debe ejecutarse una lista de verificación de seguridad de API REST?

Repita las comprobaciones de permisos y de entrada con cada versión, ya que una pequeña modificación en un rol puede ampliar en silencio quién ve qué. Programe una pasada más profunda siempre que publique endpoints nuevos, cambie el funcionamiento de las sesiones o conecte un proveedor externo. Reserve una colaboración especializada completa para un gran lanzamiento, una reconstrucción importante o un plazo de cumplimiento normativo.

¿Se puede probar la seguridad de una API REST sin acceso al código fuente?

Sí, y la mayor parte de esta lista da por supuesto que no puede ver el código. Cada comprobación de aquí se ejecuta desde fuera, usando cuentas corrientes y una herramienta capaz de enviar solicitudes. Eso refleja exactamente la posición de un atacante, ya que ellos tampoco tienen su código fuente. Leer el código ayuda con algunos problemas, aunque no hace falta para encontrar los comunes.