Pentest de aplicaciones bancarias | Abuso de cuentas de prueba y pagos

Qué implica esto para su prueba

Una prueba de penetración de una aplicación bancaria debe seguir el recorrido del cliente a través del dispositivo, el servicio de identidad y la API del backend. Incluya la recuperación de cuentas, el registro de dispositivos, los cambios de beneficiario y la autorización de pagos. Prepare pares de roles de clientes y empleados para que la evaluación pueda distinguir entre una acción permitida y un fallo de titularidad o aprobación.

Un proceso bancario. Varios límites de seguridad.

Una prueba de penetración de una aplicación bancaria es una evaluación de seguridad autorizada de la aplicación móvil o web de un banco y de los servicios backend que la respaldan. Examina si alguien puede acceder a la información de otro cliente, hacer un uso indebido de una sesión o realizar una operación fuera de sus permisos. El alcance acordado puede incluir banca minorista, banca de empresas o una versión concreta de un producto.

Atlant Security relaciona las pruebas de aplicaciones móviles con los permisos de clientes, personal y servicios que intervienen en cada proceso. La pregunta práctica es: ¿puede el servidor seguir aplicando las reglas del banco cuando ya no se puede confiar en el cliente, el dispositivo o la sesión?

Empiece por sus plataformas, los roles de cliente y los flujos de trabajo críticos. A partir de esos datos, elaboramos una propuesta de alcance, condiciones operativas y entregables.

Qué puede abarcar una prueba de penetración de una aplicación bancaria

Seleccione los canales y flujos de trabajo que desea evaluar. Una compilación de iOS, una de Android y una API compartida son superficies de prueba distintas; incluir una no implica incluir automáticamente las demás.

Para un encargo limitado a las API, consulte pruebas de penetración de banca digital y API. Para escenarios más profundos de doble control, liberación de pagos y conciliación, consulte pruebas de flujos de pago.

Cómo probamos la banca móvil y en línea

01 / Acordar la autorización y las condiciones de prueba

Registre los identificadores de la aplicación, los números de compilación, los sistemas operativos compatibles, las versiones de la API y las diferencias entre entornos. Defina los roles de cliente, los flujos sensibles, las técnicas permitidas, los límites de frecuencia y los contactos para detener las pruebas. Acuerde si estarán disponibles el código fuente, una compilación de prueba o credenciales proporcionadas, y cómo se documentará esa asistencia.

02 / Examinar al cliente y sus comunicaciones

Revise el paquete de la aplicación proporcionado y observe su comportamiento en los dispositivos acordados. Examine el tratamiento local de los datos, las funciones de la plataforma y el tráfico hacia los servicios autorizados. Si el endurecimiento de la aplicación limita la observación, acuerde primero el enfoque de evaluación. Una elusión en una versión de prueba modificada no se presentará como una elusión demostrada de la versión de producción.

03 / Validar las reglas del banco en el servidor

Ejecute flujos representativos con identidades de prueba separadas. Compare las operaciones permitidas y denegadas en distintas cuentas, roles y estados de transacción. Valide manualmente las debilidades relevantes y confirme los cambios de estado mediante una lectura independiente o un registro de auditoría acordado. La salida de una herramienta por sí sola no demuestra el impacto empresarial.

04 / Informar, corregir y volver a probar

Explique el acceso demostrado, los controles efectivos y las áreas no evaluadas. Revise los hallazgos con los equipos responsables y, después, vuelva a probar las correcciones acordadas sobre la compilación modificada y la versión del backend. Los plazos de lanzamiento, las ventanas para repetir pruebas y las dependencias forman parte de la propuesta.

Ejemplo: cambio de beneficiario tras la aprobación

Diseño de prueba ilustrativo, no es un resultado de cliente. Un cliente de banca empresarial crea un pago sintético a un beneficiario de prueba aprobado. Un segundo usuario autorizado lo aprueba. La evaluación comprueba si los cambios posteriores en el beneficiario o el importe invalidan esa aprobación y exigen la autorización prevista de nuevo.

• Punto de partida: identidades diferenciadas de iniciador y revisor, un pago precargado y un entorno de pruebas sin liquidación.
• Resultado esperado: el servidor rechaza un cambio no autorizado o devuelve la instrucción al estado de aprobación correspondiente.
• Evidencias: versiones de la aplicación y de la API, identidad y rol, marcas de tiempo, solicitudes y respuestas anonimizadas, estado resultante de la transacción y eventos de auditoría pertinentes.
• Límite: modificar un borrador no demuestra que se puedan liberar fondos. La liquidación permanece desactivada y cualquier límite de firma posterior solo se evalúa si está autorizado.

Este enfoque proporciona a los equipos de ingeniería y riesgos un hallazgo que pueden validar sin confundir una pantalla accesible, una respuesta satisfactoria y un pago completado.

Qué recibe su equipo

• Evaluación ejecutiva: los procesos bancarios sometidos a prueba, las consecuencias empresariales, los controles que funcionaron y las decisiones prioritarias.
• Registro de cobertura: aplicaciones, compilaciones, roles, API, entornos, supuestos, exclusiones y cualquier trabajo bloqueado o incompleto.
• Hallazgos técnicos: activos afectados, condiciones previas, observaciones reproducibles, evidencias con datos ocultos, justificación de la gravedad y límites del resultado.
• Orientación para la remediación: medidas de protección inmediatas, correcciones duraderas y criterios de aceptación para el equipo responsable de desarrollo o plataforma.
• Resultados de las nuevas pruebas acordadas: versiones modificadas, casos repetidos y hallazgos confirmados como corregidos, parcialmente corregidos, aún abiertos o no sometidos a nuevas pruebas.

Consulte los entregables de los informes o vea una vista previa del informe ficticio de Megabank AG. El ejemplo muestra el formato más amplio de los informes bancarios; no constituye evidencia de una evaluación real de banca móvil.

Preparar el alcance de una prueba de aplicaciones

Para la consulta inicial basta con una descripción general. Utilice el generador de solicitudes de propuestas para esbozar los sistemas, los objetivos y el calendario, o envíe un documento de requisitos existente junto con un acuerdo de confidencialidad para su revisión a través del formulario de contacto. Acuerde un canal seguro de transferencia antes de compartir compilaciones, credenciales o información confidencial sobre la arquitectura.

• Plataformas y versión: iOS, Android, banca web, versiones de compilación y fecha prevista de lanzamiento o de garantía.
• Flujos: alta, inicio de sesión, recuperación, acceso a la cuenta, gestión de beneficiarios, transferencias, aprobaciones y otras funciones críticas.
• Roles: clientes particulares, usuarios empresariales, usuarios delegados, aprobadores, personal de soporte y relaciones de prueba representativas.
• Dependencias: documentación de API, proveedores de identidad, entornos de pruebas de pagos, titularidad de terceros y requisitos de autorización.
• Condiciones operativas: entorno, datos sintéticos, métodos permitidos, autoridad para detener las pruebas, contactos de supervisión y limpieza.
• Resultados: destinatarios del informe, debate sobre la corrección, necesidades de repetición de pruebas y cualquier correspondencia necesaria con requisitos de contratación o aseguramiento.

La duración y las tarifas dependen del número de versiones y roles, la complejidad de los flujos de trabajo, la cobertura de las API, las condiciones de acceso y los requisitos de elaboración de informes. Una evaluación limitada a una versión requiere un esfuerzo distinto al de un alcance completo para aplicaciones móviles y web. Acordamos estos supuestos antes de preparar el presupuesto.

Prepare un documento de alcance detallado o envíe su RFP y adjunte un NDA.

Preguntas sobre el pentest de aplicaciones bancarias

¿Las pruebas de banca móvil incluyen las API del backend?

El alcance debe incluir las operaciones de API necesarias para evaluar los flujos móviles acordados, con los servicios y puntos de conexión exactos documentados en el alcance. Los demás conjuntos de API, los sistemas internos del personal y otros canales requieren decisiones de alcance independientes. Probar únicamente el binario de la aplicación no permite determinar cómo aplica el servidor cada permiso.

¿Pueden evaluar tanto iOS como Android?

Sí. Indique ambas plataformas al solicitar el alcance. Las funciones compartidas del producto no hacen que el almacenamiento, los permisos, los enlaces de aplicaciones y el endurecimiento específicos de cada plataforma sean idénticos. La propuesta documenta las compilaciones y la cobertura de dispositivos o sistemas operativos.

¿Se pueden realizar pruebas en producción?

Solo en las condiciones acordadas expresamente. Para los escenarios de pago que modifican el estado, resulta útil un entorno representativo que no liquide operaciones. Cualquier trabajo en producción requiere autorización por escrito, identidades y datos controlados, límites operativos y autoridad para detenerlo. El informe registra las diferencias que impiden asumir que un resultado de preproducción también sea válido en producción.

¿Necesita código fuente o cuentas de prueba?

Las cuentas representativas suelen hacer más útiles las pruebas de roles y límites entre clientes. El código fuente y una compilación instrumentable pueden ayudar a responder preguntas concretas, pero son opciones de alcance. La propuesta distingue entre trabajo sin autenticación, autenticado y asistido, y deja constancia de lo que no puede probarse sin el acceso solicitado.

¿Es esto lo mismo que una prueba de penetración de la red de un banco?

No. Este servicio sigue los recorridos de las aplicaciones orientados al cliente desde el dispositivo o navegador hasta las API de soporte. Una evaluación de la red y la identidad bancaria examina la infraestructura y las rutas de confianza internas. Se pueden combinar cuando el objetivo requiera ambas.

¿Cuándo deberíamos solicitar una prueba de penetración de una aplicación bancaria?

Planifique con suficiente antelación para corregir los problemas y repetir las pruebas antes de una versión importante. Las nuevas funciones de autenticación, recuperación, pago o API pueden cambiar sustancialmente el alcance necesario. Acuerde una cobertura periódica que se ajuste a su ciclo de versiones y programa de riesgos, en lugar de suponer que una evaluación cubre todas las versiones posteriores.

Referencias y cobertura de las pruebas

Utilizamos las áreas de control pertinentes de OWASP MASVS y las directrices de pruebas de MASTG para estructurar el alcance móvil. La declaración de trabajo especifica los controles y casos de prueba aplicables; citar estas referencias no implica una certificación de OWASP ni la cobertura completa de todos los controles.

La selección de escenarios de API incluye la autorización a nivel de objeto y los flujos empresariales sensibles de OWASP API Security Top 10. Estas referencias ayudan a estructurar la evaluación; las propias reglas de la entidad bancaria sobre cuentas, roles y pagos determinan qué decisiones se esperan.

Si el encargo tiene un objetivo regulatorio, identifíquelo durante la definición del alcance y consulte nuestra guía sobre pruebas bancarias y requisitos regulatorios junto con el responsable del programa correspondiente.