shipfast api protection
vor, improvments, fixes and security updates
¡Bienvenido! Este repositorio es parte de esta serie de publicaciones de blog sobre técnicas prácticas de seguridad de API. La serie lo guía a través del proceso de defender un backend de API móvil contra varias exploits que un atacante puede usar para obtener acceso a los datos que posee. En este escenario de demostración, el ataque permite a los usuarios reales del sistema obtener una ventaja comercial injusta a expensas de la empresa.
Este repositorio contiene los tres componentes que se utilizan para describir la historia de Shipfast:
Hemos mantenido los 3 proyectos en el mismo repositorio y estructurado el código para incluir todos los pasos de la progresión de la serie de blogs. Esperamos que esto haga que sea más fácil de entender en su conjunto.
Después de establecer la escena en la primera publicación de blog, las entradas sucesivas muestran cómo las medidas de seguridad pueden fortalecerse (o pasar) utilizando enlaces al código en este repositorio de GitHub cuando sea apropiado. La serie de blogs se puede resumir refiriéndose al método de seguridad principal en discusión en cada uno:
Proporcionamos implementaciones disponibles gratuitamente de los dos servicios y APK para que pueda descargar e instalar, por lo que puede trabajar con ellos mientras lee el blog. Las siguientes secciones ofrecen un breve resumen de los servicios que hemos implementado, las aplicaciones que proporcionamos, dónde encontrar el código asociado en este repositorio y dónde se encuentran los cambios para cada publicación de blog.
El código API de ShipFast se puede encontrar en la carpeta Server/Shapfast-API. El código se implementa en la nube y se pone a disposición en https://shipfast.demo.approov.io.
La API de ShipFast está versión de v1 a v4 para seguir la historia del blog y puede acceder a cada etapa utilizando las siguientes URL:
La página Libertad de este repositorio contiene un APK para cada etapa. Están configurados para que pueda instalarlos todos a la vez en su dispositivo Android (lo siento, no iOS en este momento).
El código para las aplicaciones está en un proyecto AndroidStudio: App/Android/Kotlin/ShipFast.
Hemos utilizado un esquema de color diferente en cada versión de la aplicación para que pueda identificar rápidamente cuál está ejecutando:
Los colores no tienen ningún significado especial, pero obviamente, el verde es el mejor.
El servicio web de Rogue, Shipraider, fue configurado por un pirata malvado para ayudar a los conductores de Shipfast a aprovechar las propinas de los clientes de Shipfast. El código se puede encontrar en la carpeta Server/Shipraider-Rogue-Web.
Cada versión del sitio web se sirve desde un dominio diferente:
El sitio web de Shipraider sigue el mismo esquema de color que las aplicaciones móviles para diferenciar entre versiones.
A continuación damos una breve descripción general de las técnicas utilizadas en la serie de blogs para bloquear la API con enlaces a las líneas de código relevantes y la publicación de blog asociada.
El método más común utilizado por los desarrolladores para identificar lo que está haciendo una solicitud al servidor API es usar una cadena larga en el encabezado de solicitud, con mayor frecuencia llamada Api-Key , consulte la primera publicación de blog.
Las claves API son muy simples de implementar tanto en el servidor como en el cliente. Este código de la aplicación agrega la clave a cada solicitud y el servidor valida la solicitud con una verificación de encabezado simple, como se muestra en este código.
Desafortunadamente, evitar la protección de la clave API también es fácil, ya que es un secreto comunicado en cada solicitud. El segundo blog de la serie comienza mostrando cómo extraer la llave API con un ataque MITM (Man in the Middle). Luego, la clave se agrega al sitio web de ShipRaider para ser utilizado en las solicitudes que realiza a la API de Shipfast.
Para mejorar la protección, la segunda publicación de blog presenta un HMAC para firmar digitalmente las solicitudes de API y, por lo tanto, evitar que sean secuestrados o manipulados. Es mejor que una clave API, ya que la parte secreta nunca se envía explícitamente desde el cliente al servidor y en esta versión está estadalmente integrada en el código.
La implementación de HMAC es un poco más elaborada que la implementación de la clave API, pero sigue siendo simple. Puede verificar este código para la implementación del servidor API y este código para la implementación de la aplicación móvil.
Sin embargo, si el secreto de HMAC está codificado, entonces es fácil para un atacante extraer. La tercera publicación de blog demuestra esto mediante el uso de herramientas de análisis binario de código abierto para revelar el secreto HMAC y el algoritmo asociado utilizado para firmar las solicitudes. Una vez que se copian en el código de ShipRaider, el sitio web de Rogue puede volver a funcionar.
El segundo escenario de ataque reveló que usar un secreto estático para el algoritmo HMAC es un punto débil. La siguiente defensa es usar un secreto dinámico; uno que se calcula en tiempo de ejecución. La tercera publicación de blog explica cómo combinar un secreto estático con datos dinámicos para producir un secreto dinámico con el que inicializar el algoritmo HMAC.
La implementación de la aplicación móvil se puede ver en estas líneas de código, mientras que el equivalente del servidor API se puede ver aquí.
Calcular el secreto de HMAC en tiempo de ejecución hace que sea más difícil omitir pero no imposible. El atacante ahora necesita comprender una sección de código más grande para reproducir el comportamiento en el sitio web de Shipraider. La cuarta publicación del blog enumera varios enfoques para esto, dando un ejemplo más detallado utilizando el reempaquetaje de aplicaciones y el depurador de Android Studio. Nuevamente, el atacante puede escribir un código equivalente en Shipraider para continuar usando la API de Shipfast.
La cuarta publicación de blog presenta la medida de seguridad final de la serie. El certificado de aplicaciones móviles es el concepto de seguridad API implementado en aproximación. En pocas palabras, Aproxime verifica toda la aplicación y el entorno en el que se ejecuta antes de habilitar el acceso a la API: la aplicación es la clave . Le brinda un alto grado de confianza en que sus accesos de API están bloqueados para instancias legítimas de su aplicación. Este enfoque se describe con más detalle en nuestra página de descripción general del producto y en el documento blanco asociado.
La integración aproximada es tan simple como puede ser para los desarrolladores de aplicaciones móviles. Agregue el SDK de aprobación a su compilación, con suerte utilizando uno de los [ejemplos de integración de avance rápido]] (https://approov.io/docs/latest/approov-integration-examples/mobile-app/) para acelerar el proceso y luego llamar al SDK para obtener un tope de aproximación para incluir en las solicitudes de API. Puede ver esto en la aplicación ShipFast en ShapFastapp.kt, busque las líneas que están precedidas por // *** UNCOMMENT THE CODE BELOW FOR APPROOV *** .
La integración del servidor API también es simple: use una de las muchas bibliotecas JWT para verificar el token AdopOV antes de responder a las solicitudes de API. La API de ShipFast utiliza el paquete de nodo Express-JWT para verificar el token aproximado con la devolución de llamada checkApproovToken .
El documento de uso avanzado describe los pasos de compilación e implementación para cada uno de los componentes que componen los servicios de Shipfast y ShipRaider. Para seguir la serie de blogs, normalmente es suficiente utilizar los servicios y aplicaciones implementados y mantenidos por el equipo de Atov, en cuyo caso no necesita seguir ese documento. Sin embargo, lo necesitará si intenta el desafío Pentesting opcional, descrito al final de la última publicación de blog.
La serie de blogs, en su conjunto, muestra una mejora gradual en la seguridad de las API al garantizar que las solicitudes solo provengan de fuentes legítimas. Los blogs y el código en este repositorio se utilizan para mostrar cómo eludir fácilmente algunos mecanismos de protección que se usan comúnmente en el desarrollo de API. Culmina en una integración aproximada que brinda el mayor grado de confianza en las solicitudes verificadas recibidas por la API de Shipfast. Si desea explorar la solución aproximada con más profundidad, ¿por qué no probar uno de los siguientes enlaces como punto de salida:
