Desarrollo de Software con IA

Cómo rompen tu app: inyección SQL, XSS y CSRF explicados con dibujos

Describir los tres ataques clásicos (inyección SQL, XSS, CSRF), su efecto y su defensa estándar.

Conoce las tres trampas que la IA olvida cerrar

Candado de acero macizo con cadena sobre un fondo oscuro.
La seguridad no es un feature: es capas que se suman. Inyección, XSS, secretos, hash: aquí aprendes a exigir auditorías y a no tragar con la primera respuesta.

Cuando pides «pon un buscador» o «muestra los comentarios», la IA escribe lo que funciona, no necesariamente lo que es seguro. Tres ataques son los que se cuelan una y otra vez. No necesitas explotarlos: necesitas reconocerlos y exigir su defensa. Los verás como dibujos, no como código de hacker.

Inyección SQL: el dato que se vuelve orden

En un buscador mal hecho, lo que escribe el usuario se pega directamente a la consulta. Un listo puede escribir texto que la base de datos lee como instrucción, no como dato: y se lleva todo.

El mismo texto: dato vs orden
BUSCO: un nombre en el buscador de clientes\n\nSi el codigo PEGA tu texto a la consulta:\n  SELECT * FROM clientes WHERE nombre = '[lo que escribi]'\n\nEscribo:  x' OR '1'='1\nY la consulta se convierte en:\n  ... WHERE nombre = 'x' OR '1'='1'   -> devuelve TODOS los clientes\n\nDEFENSA: consultas parametrizadas (el dato nunca se mezcla con la orden).

XSS: script ajeno en tu página

Si guardas y muestras comentarios sin limpiarlos, alguien puede «comentar» un pedazo de JavaScript. Tu navegador lo ejecutará creyendo que es tuyo, y puede robar sesiones.

XSS en una línea Un usuario escribe como comentario un trozo de JavaScript que roba la sesión. Otros lo ven; su navegador lo ejecuta creyendo que es parte de tu página. La defensa: escapar/sanitizar todo lo que se muestra y nunca tratar la entrada como código.

CSRF: el navegador traicionado

Una página maliciosa hace que tu navegador, ya conectado a tu banco, dispare una acción sin que tú la pidas (un «transferir dinero»). La defensa es un token anti-CSRF que solo tu formulario real conoce.

Para reforzar la defensa SQL

Migraciones, respaldos y evitar el SQL injection
OA publicado que ya trata el SQL injection. Aquí lo sitúas junto a XSS y CSRF y aprendes a pedir las tres defensas a la vez.

Prueba

La defensa estándar contra la inyección SQL es:

Mostrar los comentarios del usuario tal cual fueron escritos es inocuo.

Detecta el código inseguro

Lees la explicación de una IA sobre cómo hizo tres funciones. Señala la que introduce una vulnerabilidad:

  1. El buscador usa una consulta parametrizada para el término.
  2. Los comentarios se escapan al mostrarlos para que nada se ejecute como script.
  3. El formulario de transferencia acepta la orden sin token anti-CSRF porque «el usuario ya está logueado».
  4. La contraseña se guarda con hashing.

Identifica la linea con error.

Revisa tu proyecto: ¿dónde metes texto del usuario en una consulta, dónde muestras texto ajeno y dónde hay acciones sensibles? Para cada uno, escribe la defensa que le exigirás a la IA.

PistaLa seguridad no es un módulo aparte: son decisiones en cada punto donde entra o sale texto del usuario.