TaxPinTaxPin

VERIFICACIÓN DE SEGURIDAD

Construido para ser seguro — y puesto a prueba como un atacante

La seguridad de TaxPin no se detiene en “lo construimos”. Intentamos vulnerarla repetidamente desde el punto de vista de un atacante, y la sometimos a la revisión independiente de una firma externa.

Aislamiento de tenantsEscalada de privilegiosElusión de MFARobo de invitacionesAbuso del registroXSS · secretosSuperficie de ataque

Dos capas de verificación

Combinamos revisiones internas en las que nos atacamos a nosotros mismos con una evaluación externa independiente.

🧪

Revisión adversarial interna

Equipos independientes sondearon el código con escenarios de ataque reales a lo largo de varias rondas, y cerraron los hallazgos de forma estructural en las capas de base de datos y servidor.

🛰️

Revisión externa — AEGISonar

Una evaluación externa independiente de nuestra superficie de ataque y vulnerabilidades web mediante AEGISonar de WebEASM.

Revisión adversarial interna — cómo lo hicimos

No fue “programamos con cuidado” — realmente intentamos entrar. Equipos independientes con metodologías distintas revisaron el código en paralelo a lo largo de varias rondas, y cada hallazgo se confirmó solo después de intentos independientes de refutar que fuera alcanzable.

Nuestro método

Equipos multiánguloRLS y autorización (aislamiento de tenants), lógica de servidor (STRIDE), cliente y web (OWASP), y regresión de datos/almacenamiento — cuatro frentes revisando a la vez desde perspectivas distintas.
Rondas repetidasNo una sola vez, sino varias rondas de revisión → corrección → nueva revisión. Cada nueva capacidad (autorregistro, facturación, prueba gratuita) desencadenó otra pasada.
Verificación adversarialCada hallazgo fue cuestionado de forma independiente por varios revisores, de modo que solo se confirmaron los problemas realmente alcanzables y se descartaron los exagerados.
Correcciones estructuralesNada de parches temporales — los hallazgos se cerraron en capas estructurales: seguridad a nivel de fila (RLS), triggers y controles del lado del servidor, con un historial documentado de revisión y corrección.

Escenarios de ataque que probamos

Intentamos realmente los siguientes ataques y verificamos que quedan bloqueados a nivel de base de datos y de código de servidor.

Elusión del aislamiento de tenants

Intentos de leer o escribir clientes, documentos o solicitudes de otro despacho. No solo las lecturas — las escrituras (INSERT/UPDATE) también están vinculadas a la relación despacho↔cliente y quedan bloqueadas.

Escalada vertical de privilegios

Intentos de pasar de empleado→propietario o de cliente→miembro del despacho. Las decisiones de rol y la aceptación de invitaciones se imponen en el servidor y en la base de datos.

Robo de enlaces de invitación

Intentos de reclamar una invitación con un correo que no coincide. El correo de inicio de sesión debe coincidir con el correo invitado.

Elusión de MFA

Intentos de llegar a los datos solo con la contraseña. Una vez inscrito un segundo factor, la base de datos exige una sesión aal2 (de dos factores).

Abuso de relés de notificación/correo e inyección de phishing

Intentos de inyectar enlaces de inicio de sesión falsificados a través de las rutas de notificación. La identidad del remitente y los dominios de los enlaces están fijados a valores de confianza.

Abuso del embudo de registro

Llamadas masivas anónimas a la API de registro para tumbar el servicio u ocupar direcciones de despachos. Bloqueado mediante enrutamiento por servidor, límites de tasa y vinculación a la sesión de pago.

Exposición de secretos, XSS, redirecciones abiertas

Comprobamos si los secretos del servidor se filtran al navegador, si la entrada del usuario se ejecuta como script y si las redirecciones pueden abusarse.

Falsificación de webhooks SMS entrantes

Intentos de falsificar webhooks entrantes para alterar el consentimiento de SMS. Bloqueado mediante verificación de firma obligatoria.

Los problemas reales confirmados se cerraron a nivel de políticas de base de datos y código de servidor, en su mayoría antes de incorporar a clientes reales.

Un límite honesto

La seguridad es un proceso continuo que nunca está “terminado”. Nuestras revisiones internas se basan en análisis estático y escenarios, y se complementan con la evaluación externa de AEGISonar. A medida que atendemos a más clientes, seguimos ampliando nuestras pruebas. En lugar de proclamar la perfección, elegimos ser transparentes sobre qué verificamos y cómo.

Revisión externa — WebEASM AEGISonar

La revisión interna por sí sola puede dejar puntos ciegos, así que nos sometimos a una evaluación externa independiente. AEGISonar de WebEASM examinó de forma independiente nuestra superficie de ataque expuesta al exterior y nuestras vulnerabilidades web.

5

Resultado de la auditoría externa · Calificación global 5 (Safe)

0 hallazgos Critical/High/Medium, SSL/TLS seguro, 0 amenazas en enlaces externos — ver resultados completos