Inyección SQL, XSS y prompt injection: los ataques que todo litigante debería entender (y cómo se prueban en juicio)
Una empresa puede tener servidores modernos, controles de acceso y sistemas de monitoreo. Sin embargo, una entrada mal validada, una sesión mal protegida o una aplicación de inteligencia artificial conectada a información sensible pueden abrir la puerta a un incidente con consecuencias legales.
Para un abogado litigante, la pregunta no es únicamente qué ataque ocurrió. También importa saber qué rastro dejó, quién podía conservarlo, cómo se obtuvo y qué puede demostrarse técnicamente ante el juez.
¿La empresa fue realmente vulnerada? ¿La operación cuestionada pudo realizarse desde el dispositivo señalado? ¿El sistema registró el acceso? ¿El dictamen de la contraparte distingue entre una posibilidad técnica y un hecho acreditado?
En este artículo encontrarás una explicación clara de los ataques más relevantes, inspirada en el enfoque de aprendizaje por escenarios de Hacksplaining, y su relación con la informática forense y el litigio.
El problema: los ataques digitales dejan rastros, pero no todos se interpretan igual
Hacksplaining utiliza lecciones interactivas para explicar vulnerabilidades frecuentes de aplicaciones web y sistemas de inteligencia artificial. Entre sus escenarios se encuentran la inyección SQL, el prompt injection en aplicaciones LLM, el cross-site scripting o XSS, la autenticación débil, CSRF, path traversal, command injection y control de acceso roto.
La utilidad de conocer estas técnicas no se limita al área de desarrollo. En un expediente judicial, identificar el mecanismo de ataque ayuda a formular preguntas concretas:
- ¿Qué sistema fue afectado?
- ¿Qué información estaba disponible para el atacante?
- ¿Existieron accesos no autorizados?
- ¿Se modificaron registros, saldos, cuentas o comunicaciones?
- ¿Los logs fueron preservados antes de ser sobrescritos?
- ¿La evidencia permite atribuir una acción a una persona o solo demostrar que ocurrió desde una cuenta o dirección IP?
El nombre del ataque no prueba por sí solo la responsabilidad. Lo que tiene valor probatorio es la relación documentada entre la vulnerabilidad, la actividad registrada, el impacto y las fuentes que permiten verificar cada conclusión.
Inyección SQL: cuando una entrada llega hasta la base de datos
La inyección SQL ocurre cuando una aplicación incorpora de manera insegura información proporcionada por el usuario dentro de una consulta a la base de datos. En términos sencillos, el sistema confunde datos introducidos en un formulario, una URL o una solicitud con instrucciones que puede ejecutar.
¿Qué podría permitir? Dependiendo de la vulnerabilidad y de los permisos del sistema, el atacante podría consultar información, modificar registros, crear usuarios, alterar operaciones o eliminar datos.
¿Qué evidencia puede dejar?
Un análisis forense puede buscar:
- Logs del servidor web, con solicitudes anómalas y parámetros fuera del comportamiento normal.
- Registros de la base de datos, incluyendo consultas, errores, tiempos de respuesta y operaciones realizadas.
- Logs de la aplicación, con excepciones, mensajes de error y trazas de ejecución.
- Registros de WAF, IDS o SIEM, que pueden mostrar alertas, bloqueos y reglas activadas.
- Copias de respaldo y comparaciones de integridad, para identificar cambios en información almacenada.
- Registros de cuentas y sesiones, para relacionar el acceso con usuarios, fechas, dispositivos o direcciones IP.
En juicio, no basta con señalar que una empresa tenía una aplicación vulnerable. Debe establecerse, con metodología, si existió explotación efectiva, qué datos fueron consultados o modificados y qué fuentes respaldan esa reconstrucción.
XSS: cuando una aplicación ejecuta contenido que no debía confiar
El cross-site scripting (XSS) ocurre cuando una aplicación incorpora contenido controlado por un usuario dentro de una página web sin validarlo o procesarlo correctamente. El navegador de otra persona puede interpretar ese contenido como código ejecutable.
Existen distintas modalidades. En el XSS reflejado, el contenido malicioso puede viajar en una solicitud y aparecer en una respuesta. En el XSS persistente, queda almacenado en la plataforma —por ejemplo, en un comentario, perfil o registro— y se presenta posteriormente a otros usuarios.
El riesgo puede incluir manipulación de contenido, redirecciones, captura de información de sesión o ejecución de acciones en el contexto de una cuenta autenticada.
¿Cómo se prueba técnicamente?
El peritaje informático puede examinar:
- El contenido almacenado en bases de datos o sistemas de gestión.
- Las respuestas HTTP entregadas por el servidor.
- Cabeceras, cookies y tokens de sesión.
- Registros del navegador y de los dispositivos afectados.
- Historiales de acceso, redirecciones y solicitudes correlacionadas.
- Capturas de tráfico o registros de herramientas de seguridad.
- Diferencias entre el contenido original y el contenido mostrado al usuario.
Una captura de pantalla puede ayudar a ilustrar un resultado, pero rara vez explica por sí sola cómo se generó, cuándo ocurrió, desde qué fuente provino o si el contenido fue alterado después. Por eso es necesario relacionarla con registros técnicos y, cuando sea posible, con la fuente original.
Prompt injection: el riesgo emergente en aplicaciones con inteligencia artificial
El prompt injection consiste en introducir instrucciones o contenido diseñado para alterar el comportamiento esperado de una aplicación que utiliza un modelo de lenguaje. El problema no se limita a la conversación con la IA: aumenta cuando el sistema está conectado con bases de datos, documentos, correo electrónico, APIs o herramientas capaces de ejecutar acciones.
Un contenido externo puede intentar que el sistema ignore reglas, revele información del contexto, consulte una fuente no autorizada o realice una operación que el usuario no pretendía solicitar.
¿Es igual que una inyección SQL? No. La lógica es parecida —una aplicación confía demasiado en una entrada externa—, pero el objetivo y el mecanismo son distintos. En la inyección SQL se busca influir en consultas a una base de datos; en el prompt injection se intenta influir en las instrucciones y decisiones de una aplicación basada en IA.
¿Qué debe preservarse?
En estos casos, el análisis puede requerir:
- Prompt del usuario y respuesta completa del modelo.
- Instrucciones del sistema y configuración vigente.
- Documentos o contenidos que la aplicación procesó.
- Registro de llamadas a herramientas, APIs y bases de datos.
- Identidad, sesión, fecha y permisos del usuario.
- Versiones del modelo, de la aplicación y de sus componentes.
- Acciones ejecutadas después de la interacción.
- Alertas y registros de auditoría.
La dificultad probatoria es importante: una respuesta extraña de la IA no demuestra automáticamente una intrusión. Debe verificarse qué entrada recibió el sistema, qué instrucciones estaban configuradas, qué herramientas tenía disponibles y qué acción se produjo posteriormente.
El riesgo procesal: confundir una vulnerabilidad con una responsabilidad acreditada
Un error frecuente consiste en presentar una vulnerabilidad como si, por sí sola, demostrara quién causó un daño. Eso puede debilitar el caso durante el contrainterrogatorio.
Por ejemplo:
- Que exista una falla no demuestra que haya sido explotada.
- Que aparezca una dirección IP no demuestra necesariamente quién estaba detrás del teclado.
- Que una cuenta haya sido utilizada no demuestra que su titular haya ejecutado la acción.
- Que un log contenga un registro no significa que sea completo, auténtico o técnicamente confiable.
- Que una herramienta de seguridad haya generado una alerta no prueba, sin corroboración, el alcance del incidente.
La prueba debe construirse con contexto, integridad y correlación.
Un peritaje informático serio revisa las fuentes disponibles, documenta su preservación, calcula hashes cuando corresponde, identifica los límites del análisis y explica cómo se llega de los datos observados a la conclusión técnica. También debe distinguir entre hechos constatables, inferencias razonables e hipótesis que no pueden confirmarse.
Cómo documenta el rastro un perito informático forense
En términos generales, el trabajo puede organizarse en cuatro etapas:
1. Preservación
Se identifican servidores, dispositivos, respaldos, cuentas, registros y archivos relevantes. Debe evitarse la manipulación innecesaria de las fuentes y documentarse quién tuvo acceso, cuándo y con qué propósito.
2. Adquisición y verificación
Se obtienen copias o exportaciones técnicas de acuerdo con el alcance del caso. Los hashes, metadatos y registros de transferencia ayudan a verificar que la información analizada corresponda a la fuente recibida.
3. Correlación
Se comparan logs de distintos sistemas: servidor web, base de datos, autenticación, WAF, aplicación, dispositivo y red. Una línea de tiempo coherente puede revelar si hubo una solicitud, una autenticación, una modificación y una respuesta posterior.
4. Dictamen y explicación
El resultado debe expresarse en un lenguaje comprensible para el juzgador, sin sacrificar precisión técnica. El dictamen debe explicar el método, las fuentes, los hallazgos, las limitaciones y la relación entre cada evidencia y la pregunta pericial.
Por qué capacitar al área técnica también fortalece un litigio
La capacitación de equipos técnicos, como el enfoque de aprendizaje por escenarios que presenta Hacksplaining, no sustituye un peritaje informático. Sin embargo, puede mejorar significativamente la calidad de la evidencia futura.
Un equipo que entiende cómo funcionan SQL injection, XSS, autenticación rota o control de acceso roto está en mejores condiciones de:
- Configurar registros útiles y conservarlos durante el tiempo necesario.
- Documentar incidentes desde el primer momento.
- Separar logs de operación y logs de seguridad.
- Registrar cambios de configuración y permisos.
- Evitar que una investigación destruya información relevante.
- Definir procedimientos de respuesta y escalamiento.
- Explicar al abogado qué ocurrió antes de que se pierda el contexto.
Así pues, la prevención técnica también tiene una dimensión procesal: un sistema que registra correctamente facilita la reconstrucción de los hechos.
El papel del perito de apoyo para abogados litigantes
Si tu despacho representa a una empresa afectada, a una persona acusada o a una parte que necesita cuestionar la versión técnica de la contraparte, conviene involucrar al perito desde las primeras decisiones sobre preservación y puntos de pericia.
El servicio de Perito en informática Fernando Amador Diaz está dirigido exclusivamente a abogados litigantes, despachos e independientes. La contratación se realiza a través del abogado que dirige el caso, no directamente con la persona o empresa involucrada en el juicio.
El trabajo incluye análisis de evidencia digital, reconstrucción de actividad, revisión de sistemas, apoyo en casos de transferencias no reconocidas, análisis de dispositivos y refutación de dictámenes periciales de la contraparte. Los entregables están diseñados para explicar qué puede sostenerse ante el juez, qué debe matizarse y qué preguntas pueden surgir durante la ratificación o el contrainterrogatorio.
Cuenta con registro como perito ante el Poder Judicial de la Federación, P.0063-2020, y ante el Poder Judicial del Estado de Querétaro, PJQ/0339/PER. Además, acumula más de 1,000 casos periciales en jurisdicción federal y estatal, con comprensión práctica de los plazos procesales y de los formatos que exige cada litigio.
La información del expediente se maneja con confidencialidad y el alcance se define conforme a la pregunta técnica, las fuentes disponibles y la etapa procesal.
Conclusión: el ataque importa, pero la prueba importa más
SQL injection, XSS y prompt injection son técnicas diferentes, pero comparten una consecuencia: pueden dejar rastros digitales que resultan relevantes para un litigio.
La clave no es utilizar términos técnicos para impresionar. Es demostrar, con fuentes preservadas y una metodología reproducible, qué ocurrió, cuándo ocurrió, qué impacto tuvo y qué puede atribuirse realmente a cada actor.
Por lo tanto, si tu caso depende de logs, sesiones, sistemas corporativos, aplicaciones web o inteligencia artificial, actúa antes de que los registros se sobrescriban o pierdan contexto. Confía la revisión a un perito informático que entienda tanto la tecnología como los tiempos y exigencias del proceso judicial.
Para revisar el alcance de un caso, consulta la guía para abogados litigantes, conoce los servicios de peritaje informático o envía el contexto del expediente mediante el formulario de contacto.
Categoría: Informática Forense
Slug: informatica-forense
Tag ID: 12