El gerente de producto me asignó un trabajo de prueba de aplicaciones (en otras palabras, ¿por qué el gerente de producto asigna el trabajo? ¿No estoy bajo la supervisión del director de tecnología), incluidos Android e iOS, un poco confuso, penetración web acordada? testing and server En cuanto a las pruebas de penetración de terminales, aunque es confuso, pero con mi fuerte capacidad de autoaprendizaje, con el siguiente artículo, si un trabajador quiere hacer un buen trabajo, primero debe afilar sus herramientas. Primero organice sus pensamientos y profundice en ellos para que pueda ir sin problemas y no confundirse.
Análisis de amenazas de seguridad :
Para las pruebas de penetración de aplicaciones, la fuente de amenazas no es más que tres aspectos:
De hecho, el lado web parece ser el mismo en estos tres aspectos.
Los principales riesgos que enfrenta:
cliente:
- descompilar
- depuración
- Cifrado/descifrado de firmas
- registro de entrada
- exportar componentes
- inyección de proceso
- ...
transmisión de datos:
- fuga de información
- manipulación de datos de transmisión
- ataque de repetición
Servidor:
- trabajo duro
- ST2
- inyección
- Estación cruzada
- ultra vires
- Subir descargar
- contraseña debil
Contenido de la prueba de seguridad de la aplicación:
y seguridad de servidor y lógica empresarial
Proceso de prueba de seguridad:
Puntos clave de las pruebas de seguridad de aplicaciones móviles
Puntos clave de la inspección de seguridad:
Permitir vulnerabilidad de copia de seguridad
El valor del atributo allowBackup en el archivo AndroidManifest.xml se establece en verdadero. Cuando el indicador allowBackup es verdadero, el usuario puede hacer una copia de seguridad de los datos de la aplicación a través de la copia de seguridad de adb, y todos los datos almacenados en la aplicación se pueden exportar sin root, lo que resulta en una fuga grave de datos del usuario.
Sugerencia de reparación:
Establezca el atributo android:allowBackup del parámetro en falso y no se podrá realizar una copia de seguridad de los datos de la aplicación.
Vulnerabilidad de WebView
Existe una vulnerabilidad de WebView en la aplicación y no hay restricción en la llamada al método de la clase JAVA registrada, como resultado, el atacante puede usar el mecanismo de reflexión para llamar a cualquier otra clase JAVA no registrada y finalmente hacer que el código javascript realizar ataques arbitrarios al dispositivo.
Sugerencia de reparación:
Reemplace addjavascriptInterface declarando @JavascriptInterface en el método remoto de Java;
Al usar el puente de js2java, es necesario verificar cada parámetro entrante y bloquear el código de ataque;
Nota: Controle los permisos relevantes o intente no usar el puente de js2java.
Transmisión de texto claro de datos clave
Durante el proceso de inicio de sesión, la aplicación utiliza el protocolo http para transmitir el nombre de usuario y la contraseña en texto claro y no cifra el nombre de usuario y la contraseña. Los datos de los nombres de usuario y las contraseñas de los usuarios pueden ser interceptados al monitorear los datos de la red, lo que resulta en una fuga de información del usuario y genera riesgos de seguridad para los usuarios.
Sugerencia de reparación:
La información confidencial debe cifrarse al transmitirla.
Cualquier registro de cuenta
Utilice el número de teléfono móvil 177******706 para registrar una aplicación y obtener el código de verificación 38091;
Al confirmar el envío, interceptar la solicitud y modificar el número de teléfono móvil registrado para registrar cualquier cuenta, aquí se modifica a 1338*****678 (cualquier número de teléfono móvil);
Utilice 177******706 y 133******678 (cualquier número de teléfono móvil) para iniciar sesión respectivamente, y puede iniciar sesión a través de la verificación y ver el resultado final.
Sugerencia de reparación:
Al confirmar el envío al final del proceso de registro, el servidor debe verificar si la cuenta enviada es el número de teléfono móvil que emitió el código de verificación.
La interfaz de inicio de sesión puede ser secuestrada por phishing
La aplicación tiene el riesgo de phishing y secuestro. La aplicación no tiene medidas contra el secuestro de phishing. Al secuestrar la interfaz de inicio de sesión de la aplicación, se puede obtener el número de cuenta y la contraseña del usuario, lo que puede provocar la fuga de información de la cuenta del usuario.
Sugerencia de reparación:
El programa de la aplicación en sí juzga el programa que se está ejecutando actualmente en el sistema al obtener la actividad en la parte superior de la pila. Una vez que encuentra que la aplicación está cambiada (posiblemente secuestrada), le dará al usuario un aviso para evitar el fraude del phishing. programa.
Obtenga la actividad en la parte superior de la pila (como se muestra en la figura a continuación). Al cambiar actividades sensibles (inicio de sesión, transacción, etc.), juzgue si todavía está en el programa original. De lo contrario, brinde al usuario un aviso a través de Tostada.
Utilice la arquitectura HTML5 o el desarrollo mixto de Android+HTML5 para realizar páginas clave como el inicio de sesión y el pago, y reduzca el riesgo de ser secuestrado.
Vulnerabilidades de seguridad típicas de las aplicaciones móviles
En la prueba de penetración de la aplicación móvil, el bloguero resumió varias vulnerabilidades comunes de seguridad de la aplicación móvil, incluida la puerta trasera de la lógica del código de verificación gráfica, la fuga de información confidencial del usuario y la penetración de los desarrolladores. Ingenieros de desarrollo de aplicaciones, deben prestar atención.
Puerta trasera lógica captcha gráfica
Descripción general del caso
La empresa A es una empresa de tecnología de la información que cotiza en bolsa y muchos bancos comerciales nacionales son sus clientes. Al analizar los productos de banca móvil de la empresa A, se descubrió que hay una puerta trasera lógica en el mecanismo del código de verificación gráfica del producto que se puede eludir, y se puede robar una gran cantidad de cuentas de usuario al explotar esta falla. Hemos reproducido este problema de seguridad en los sistemas de banca móvil de al menos dos bancos comerciales debido a la reutilización de códigos por parte de equipos subcontratados.
Consecuencias: Ataque de fuerza bruta a la cuenta a gran escala.
En términos generales, la mayoría de los usuarios están acostumbrados a configurar la contraseña de la banca móvil en seis dígitos, y existe una alta probabilidad de que la contraseña de consulta y la contraseña de transacción sean las mismas. Los atacantes pueden buscar el rango de números de teléfonos móviles en el área como el nombre de usuario de inicio de sesión, usar un diccionario de contraseñas de seis dígitos para descifrar la fuerza bruta y cientos de miles de información de cuentas bancarias móviles están al alcance de su mano.
Fuga de información sensible del usuario
Descripción general del caso
La empresa B también es una empresa de tecnología que cotiza en bolsa con clientes financieros en todo el país. Los clientes que utilizan la solución de banca móvil de la empresa B incluyen al menos dos bancos comerciales nacionales por acciones y varios bancos comerciales de la ciudad. Al analizar la seguridad de los productos de banca móvil de la Compañía B, se encontró que la interfaz de depuración del servidor no estaba cerrada, lo que provocó la fuga de una gran cantidad de información confidencial del usuario. Este tipo de problema en realidad es bastante común y, a menudo, es causado por negligencia en el proceso en línea después de que se completa el desarrollo de la subcontratación. De hecho, un ejemplo más común es el problema de que el cliente de Android genera información de depuración a través de logcat.
La interfaz de depuración generará la información detallada de las transferencias del usuario al archivo test.log en el directorio web . Los atacantes pueden acceder directamente a este archivo de registro a través de un navegador, y cada transacción de transferencia del sistema se registra en él, desde donde se puede obtener una gran cantidad de números de cuenta de usuario, números de teléfono móvil, números de tarjeta y contraseñas de transacción.
El desarrollador está infiltrado
Descripción general del caso
Una plataforma de vulnerabilidad doméstica expuso una vez tal vulnerabilidad: hay un archivo txt en el cliente ios de banca móvil de un gran banco, que almacena la dirección IP, el nombre de usuario y la contraseña de un servidor svn.Después de que el hacker descomprime el archivo y obtiene la información, puede conectarse directamente y retirar archivos en el servidor.
El contenido almacenado en el servidor svn incluye todos los documentos del proyecto del sistema de banca móvil del banco, códigos completos de clientes Android e IOS , e incluso certificados digitales para firmas de clientes.
Este artículo está resumido y organizado después de estudiar otros artículos en Internet para referencia en el trabajo. El tutorial específico de la herramienta de penetración se actualizará la próxima vez.
Finalmente, un modesto esfuerzo
Gracias a todos los que leyeron mi artículo con atención, aunque no es algo muy valioso, si pueden usarlo, se lo pueden llevar:
Estos materiales deben ser el almacén de preparación más amplio y completo para los amigos [de pruebas de software] . Este almacén también ha acompañado a decenas de miles de ingenieros de pruebas a través del viaje más difícil. ¡Espero que también pueda ayudarlo a usted!
Método de adquisición de información:
