Como tener android auto en la pantalla de la moto.
https://ridescreen.app/
Le he pasado a chatgpt todo el codigo y esto es lo que me devuelve. Así que cada cual sepa a lo que se expone o no.
Resumen de auditoría de seguridad – RideScreen AA
Tras la revisión del código fuente de RideScreen AA, mi valoración es que se trata de un proyecto aparentemente legítimo, con funcionalidades bien planteadas y algunas medidas de seguridad correctas, pero que presenta varios puntos débiles que deberían corregirse antes de distribuirlo como aplicación de producción.
Te resumo las principales fortalezas y debilidades.
1. Fortalezas de seguridad
Aspectos positivos
1. No se detecta malware evidente. No he encontrado indicios claros de robo intencionado de información, ejecución de comandos maliciosos o comportamiento típico de software espía.
2. Consultas SQL parametrizadas. El servidor utiliza mecanismos que reducen considerablemente el riesgo de inyección SQL.
3. Protección de tokens. Los tokens utilizados para compartir ubicaciones no se almacenan directamente, sino mediante hashes SHA-256.
4. Control de duración de las sesiones. La función de ubicación compartida tiene una duración máxima de 12 horas.
5. Limitación de peticiones. Existen mecanismos para limitar la frecuencia de determinadas solicitudes al servidor.
6. Protección parcial de registros. Se intenta ocultar información sensible, como contraseñas y determinados identificadores, en los informes técnicos.
7. Ausencia de mecanismos sospechosos de ejecución dinámica. No he encontrado indicios evidentes de descarga y ejecución de código externo.
8. Transparencia en la recopilación de datos. El proyecto dispone de documentación sobre privacidad y telemetría.
2. Debilidades y riesgos detectados
Aspectos que requieren atención
1. Contraseñas Wi-Fi sin cifrar. Las contraseñas de las redes de las motocicletas se almacenan en SharedPreferences sin protección criptográfica adicional.
2. Copias de seguridad habilitadas. La configuración
android:allowBackup="true" puede facilitar la exposición de información almacenada en el dispositivo.
3. Clave de firma de producción incorrecta. La versión release utiliza una clave de depuración pública y conocida. Es uno de los problemas más importantes detectados.
4. Telemetría activada por defecto. La aplicación puede enviar información técnica del dispositivo y registros de errores sin que el usuario tenga que activar expresamente esa función.
5. Posible exposición de datos personales. Los filtros de ocultación de información en los registros no garantizan que todos los datos sensibles queden eliminados.
6. Ubicación compartida mediante enlace. Cualquier persona que conozca el enlace puede consultar la posición de la motocicleta durante el periodo de validez.
7. Componentes Android exportados. Hay servicios y receptores accesibles desde otras aplicaciones que deberían someterse a una revisión de permisos y validación de mensajes.
8. Seguridad Bluetooth pendiente de profundización. Es necesario revisar si las comunicaciones con las motocicletas validan correctamente los dispositivos, mensajes y posibles intentos de suplantación.
9. Seguridad del servidor pendiente de auditoría completa. Aunque hay medidas positivas, conviene comprobar los controles de acceso, autenticación, autorización y exposición de las API.
3. Comparativa general
[th]Elemento[/th]
[th]Valoración[/th]
|
| Código malicioso evidente | No detectado
|
| Gestión de contraseñas | Débil
|
| Firma de aplicación | Débil
|
| Protección de datos | Mejorable
|
| Telemetría | Revisar
|
| Seguridad Bluetooth | Pendiente
|
| Seguridad del servidor | Pendiente
|
| Gestión de sesiones | Buenas medidas
|
| Consultas SQL | Buenas medidas
|
4. Prioridades de corrección
Mi orden recomendado sería el siguiente:
Prioridad 1
Correcciones urgentes
- Sustituir la clave de depuración por una clave privada de producción.
- Cifrar las contraseñas Wi-Fi.
- Revisar y restringir las copias de seguridad.
Prioridad 2
Mejoras importantes - Desactivar la telemetría por defecto.
- Mejorar la anonimización de los registros.
- Revisar los servicios Android exportados.
- Reforzar la protección de los enlaces de ubicación.
Prioridad 3
Auditoría complementaria - Analizar el protocolo Bluetooth.
- Comprobar la seguridad de todas las API.
- Revisar las dependencias externas.
- Analizar el APK final y su comportamiento en ejecución.
5. Conclusión final
Mi opinión es que RideScreen AA parece un proyecto con una base funcional razonable, pero todavía necesita trabajo en seguridad y privacidad.
No hay evidencias suficientes para calificarlo como malware ni para afirmar que esté robando información deliberadamente.
Sin embargo, hay tres cuestiones que considero especialmente importantes:
- Las contraseñas Wi-Fi almacenadas sin cifrar.
- La utilización de una clave de depuración para firmar versiones de producción.
- La recopilación y transmisión de información técnica activada por defecto.
Mi recomendación: no descartaría el proyecto, pero tampoco lo consideraría preparado para una distribución pública segura hasta solucionar esos problemas y completar las comprobaciones pendientes.
Una siguiente fase especialmente útil sería hacer una auditoría de Bluetooth y de las comunicaciones entre la aplicación y la motocicleta, porque ahí podría encontrarse algún fallo que permita a terceros conectarse, suplantar dispositivos o enviar comandos no autorizados.