¿Es legal?
Solo con un mandato escrito de quien posee el sistema, que defina alcance, horarios y límites. Es lo primero que preparamos, y sin eso no se empieza: un test de intrusión no autorizado es un delito, para nosotros y para quien lo encarga.
Intentamos entrar nosotros,
antes de que lo intente otro
Test de intrusión en web apps, portales y redes corporativas. No un escaneo automático con un sello al final: alguien que intenta entrar de verdad, con las mismas técnicas de quien lo haría para robar, y que después te escribe lo que ha encontrado en un lenguaje que puedes pasar a tu proveedor.
pentest --scope "app + api" --mode grey-box
superficie mapeada ..... 148 endpoints
intentos de acceso ..... ningún límite detectado
control de permisos .... 1 fallo crítico
[ok] informe entregado en 5 días laborables
pentest --retest
segunda pasada tras la corrección: incluida
esperando
$ ./pentest --target "tu sistema"
Intentamos entrar nosotros,
antes de que lo intente otro
Un test de intrusión no es un escaneo automático con un sello al final. Es alguien que intenta entrar de verdad, con las mismas técnicas de quien lo haría para robar — y luego te escribe lo que ha encontrado en un lenguaje que puedes pasar a tu proveedor.
-
critica
Acceso a los datos de otros clientes
Cambiando un número en la dirección se abrían los documentos de otra empresa. Es el fallo más común que encontramos, y casi nunca nadie lo ha buscado.
-
alta
Credenciales escritas en el código
Claves de API y contraseñas dentro del repositorio o dentro del JavaScript que llega al navegador. Cualquiera que sepa mirar, las encuentra.
-
alta
Sin límite de intentos de acceso
El formulario de acceso aceptaba intentos infinitos: una contraseña débil cae en pocos minutos.
-
media
Sesiones que nunca caducan
Un acceso robado sigue valiendo para siempre. Quien dejó la empresa todavía entra.
-
media
Actualizaciones paradas desde hace meses
Componentes con vulnerabilidades conocidas y ya publicadas. No hace falta un ataque: basta leer el boletín.
Ninguna de estas es teórica: son las cinco que encontramos más a menudo. El informe que entregamos dice dónde está, cómo llegamos y qué hacer — con la reprueba gratuita después de la corrección.
// cuándo hace falta
Las señales de que conviene mirar
antes de un incidente
No le hace falta a todo el mundo por igual. Pero si reconoces tres, el coste de no mirar ya ha superado al de una prueba.
- 01 El software gestiona datos de clientes, pagos o documentos firmados
- 02 Un cliente o una licitación os ha pedido una verificación de seguridad por escrito
- 03 El portal está abierto en internet y accede gente de fuera de la empresa
- 04 Quien escribió el software ya no está, y nadie ha vuelto a leer ese código
- 05 Las actualizaciones de los componentes llevan más de seis meses paradas
- 06 No sabéis decir cuántas credenciales activas existen ahora mismo
// qué hacemos de verdad
Cuatro cosas,
y ninguna es un sello
Un test serio se distingue de uno falso en una sola cosa: el falso produce una lista de avisos automáticos, este produce un camino recorrido.
-
01
Reconocimiento
Se mapea la superficie expuesta: dominios, subdominios, endpoints, servicios olvidados encendidos desde hace años. La mitad de las intrusiones empieza por algo que nadie sabía que seguía en línea.
-
02
Intrusión guiada
Se prueban de verdad los caminos: permisos que se pueden esquivar, sesiones reutilizables, datos de otros accesibles cambiando un número. Acordamos antes los límites y los horarios, y nunca tocamos datos reales.
-
03
Informe en dos idiomas
Una parte para quien decide — qué riesgo hay, cuánto es grave, qué hacer primero. Una parte para quien corrige, con peticiones, respuestas y pasos para reproducirlo. Sin la segunda, la primera no se puede arreglar.
-
04
Reprueba incluida
Después de que hayáis corregido, volvemos a los mismos puntos y comprobamos. Es la parte que casi nadie incluye, y la única que demuestra que el problema está cerrado de verdad.
// cómo llegamos
Autorización primero,
siempre y por escrito
Un test de intrusión sin un mandato firmado no es un test: es un delito. Es lo primero que ponemos sobre la mesa, y si falta no se empieza.
Alcance y mandato
01Se escribe qué está dentro y qué fuera, en qué horarios, con qué límites. Firmado por quien tiene poder para autorizarlo — no por quien gestiona el sistema, por quien lo posee.
Reconocimiento y mapeo
02Se construye el inventario de lo que es accesible. A menudo es aquí donde sale la primera sorpresa: un entorno de pruebas abierto, un subdominio viejo todavía vivo.
Pruebas y aviso inmediato
03Los fallos críticos se comunican al momento, no en la entrega: si encontramos una puerta abierta a los datos de vuestros clientes, lo sabéis ese mismo día.
Informe y reprueba
04Entrega del informe con prioridades y pasos de corrección, y después de vuestras intervenciones volvemos a comprobar los mismos puntos.
// un fragmento de informe
Un fallo real,
de la petición a la línea que lo cierra
Esta es la forma en que llegan las cosas al informe: qué hemos enviado, qué ha respondido y dónde está el problema. Es también el fallo que encontramos con más frecuencia.
informe 04 · falta el control de autorización · gravedad alta
# La sesión es la de un usuario real: ha iniciado sesión\n# con normalidad. Solo cambia el número de la dirección.\n\nGET /api/documenti/4187 HTTP/2\nHost: portale.esempio.it\nCookie: sessione=8f2a91c4d7e0\n\nHTTP/2 200 OK\nContent-Type: application/json\n\n{\n "id": 4187,\n "cliente": "otra empresa",\n "file": "contratto-firmato.pdf",\n "url": "https://portale.esempio.it/media/9f1c2b.pdf"\n}
# La sesión es la de un usuario real: ha iniciado sesión\n# con normalidad. Solo cambia el número de la dirección.\n\nGET /api/documenti/4187 HTTP/2\nHost: portale.esempio.it\nCookie: sessione=8f2a91c4d7e0\n\nHTTP/2 200 OK\nContent-Type: application/json\n\n{\n "id": 4187,\n "cliente": "otra empresa",\n "file": "contratto-firmato.pdf",\n "url": "https://portale.esempio.it/media/9f1c2b.pdf"\n}
// El código que respondió 200.\n\nfunction documento(int $id): ?array\n{\n // Hay un control y, a primera vista, es el correcto:\n // sin sesión válida de aquí no se pasa.\n if (!utente_autenticato()) {\n return null;\n }\n\n // Pero la pregunta que responde esta línea es\n // "¿existe el documento 4187?" — y no\n // "¿el documento 4187 es de quien lo está pidiendo?".\n return db()->riga(\n 'SELECT * FROM documenti WHERE id = ?',\n [$id]\n );\n}
// El código que respondió 200.\n\nfunction documento(int $id): ?array\n{\n // Hay un control y, a primera vista, es el correcto:\n // sin sesión válida de aquí no se pasa.\n if (!utente_autenticato()) {\n return null;\n }\n\n // Pero la pregunta que responde esta línea es\n // "¿existe el documento 4187?" — y no\n // "¿el documento 4187 es de quien lo está pidiendo?".\n return db()->riga(\n 'SELECT * FROM documenti WHERE id = ?',\n [$id]\n );\n}
// La misma función, con el propietario dentro de la pregunta.\n\nfunction documento(int $id): ?array\n{\n $utente = utente_autenticato();\n if (!$utente) {\n return null;\n }\n\n // Ahora la línea pregunta las dos cosas a la vez, y\n // el documento de otro no está "prohibido": no existe.\n // Ningún segundo control que recordar en otro sitio, porque\n // no queda ningún otro sitio donde olvidarlo.\n return db()->riga(\n 'SELECT * FROM documenti WHERE id = ? AND cliente_id = ?',\n [$id, $utente->cliente_id]\n );\n}
// La misma función, con el propietario dentro de la pregunta.\n\nfunction documento(int $id): ?array\n{\n $utente = utente_autenticato();\n if (!$utente) {\n return null;\n }\n\n // Ahora la línea pregunta las dos cosas a la vez, y\n // el documento de otro no está "prohibido": no existe.\n // Ningún segundo control que recordar en otro sitio, porque\n // no queda ningún otro sitio donde olvidarlo.\n return db()->riga(\n 'SELECT * FROM documenti WHERE id = ? AND cliente_id = ?',\n [$id, $utente->cliente_id]\n );\n}La corrección no añade un control: elimina la posibilidad de olvidarlo. Mientras la autorización sea un if escrito junto a la consulta, tarde o temprano alguien escribirá una consulta nueva sin ese if al lado. Metida dentro de la consulta, la pregunta equivocada ya no se puede formular — y quien prueba un número al azar recibe un 404, así que ni siquiera aprende que ese número corresponde a algo.
$ cat stack.json
Sobre qué lo construimos
- OWASP Top 10 La lista de referencia de fallos de aplicación: es el mínimo, no el objetivo
- Burp Suite Interceptar y manipular el tráfico: ahí se ven los permisos que no aguantan
- Nmap Reconocimiento de red y servicios expuestos, incluidos los que nadie recordaba tener encendidos
- Prueba manual La parte que ninguna herramienta hace: entender la lógica de la aplicación e intentar sortearla
- Análisis de dependencias Componentes con vulnerabilidades ya publicadas: se encuentran leyendo, no atacando
- Reprueba tras la corrección Los mismos puntos, las mismas pruebas, después de vuestro trabajo. Incluida, no aparte
$ ./domande --frequenti
Las preguntas que
siempre llegan
¿Podéis romper algo?
Las pruebas destructivas — las que pueden tirar un servicio — solo se hacen si se piden y en entornos acordados, con una ventana declarada. En sistemas en producción trabajamos de forma no destructiva y no tocamos datos reales.
¿Cuánto dura?
Un test sobre una web app de tamaño medio lleva entre 5 y 10 días laborables, informe incluido. El reconocimiento lleva más tiempo del que se imagina: es la parte que decide la calidad de todo lo demás.
¿Qué recibimos al final?
Un informe en dos partes: una para quien decide, con riesgo y prioridades, y una técnica con pasos para reproducir cada fallo. Más una llamada para leerlo juntos, porque un PDF entregado y ya acaba en una carpeta.
¿Hace falta aunque la web sea pequeña?
Si recoge datos de personas, sí — y no por el tamaño: los escaneos automáticos que buscan fallos no miran la facturación. Si es una web corporativa sin datos y sin área privada, a menudo la respuesta honesta es que bastan actualizaciones y copias de seguridad.
¿Y después, cómo seguimos seguros?
La seguridad no es un estado sino un mantenimiento: actualizaciones, revisión de accesos, y una prueba nueva cuando cambia algo relevante. En el informe escribimos cada cuánto tiene sentido repetirlo en vuestro caso.
fymera init --proyecto "el tuyo"
Hablemos de qué
tenéis expuesto en internet
Treinta minutos por vídeo para entender el alcance. Si la respuesta correcta es «actualizad y poned un límite a los intentos de acceso», os lo decimos sin venderos un test.
