SQL Injection porta a l'OWASP Top 10 des de la seva primera edició el 2003. El 2026 continua sent una de les vulnerabilitats més explotades del món. No perquè sigui difícil de prevenir — sinó perquè molts desenvolupadors encara no saben com funciona realment. Aquest article ho explica amb codi real.
Què és SQL Injection?
SQL Injection (SQLi) és una vulnerabilitat que permet a un atacant interferir en les consultes que una aplicació fa a la seva base de dades. Ocorre quan l'aplicació inclou dades de l'usuari directament en una consulta SQL sense filtrar-les ni validar-les.
El resultat: l'atacant pot llegir dades que no hauria de veure, modificar-les, eliminar-les, o en alguns casos executar ordres al servidor.
Com funciona: l'exemple clàssic del login
Imagina un formulari de login. El codi PHP que processa el login podria ser una cosa així:
$user = $_POST['usuario']; $pass = $_POST['password']; $query = "SELECT * FROM usuarios WHERE usuario = '$user' AND password = '$pass'"; // Si troba resultats → login correcte
Si l'usuari escriu admin i la seva contrasenya, la consulta queda:
SELECT * FROM usuarios WHERE usuario = 'admin' AND password = '1234'
Fins aquí tot normal. Ara ve l'atac. L'atacant escriu això al camp usuari:
admin' --
La consulta resultant és:
SELECT * FROM usuarios WHERE usuario = 'admin' --// ' AND password = 'el que sigui'
El -- comenta tot el que ve després. La condició de contrasenya desapareix. L'atacant entra com admin sense conèixer la contrasenya.
Tipus de SQL Injection
L'atacant rep els resultats directament en la resposta de la web. És la més fàcil d'explotar i detectar. Inclou la variant Union-based (utilitza UNION per extreure dades d'altres taules) i Error-based (obté informació dels missatges d'error del servidor).
L'aplicació no retorna les dades directament, però l'atacant pot fer preguntes de sí/no basant-se en el comportament de la web (si triga més a respondre, si mostra un resultat o un altre). És més lenta però igualment efectiva.
L'atacant extreu dades a través d'un canal diferent (una petició DNS o HTTP a un servidor que controla). Menys comú, però molt difícil de detectar amb monitoratge bàsic.
Què pot fer un atacant amb SQLi
- →Extreure tota la base de dades: usuaris, contrasenyes, dades de clients, targetes.
- →Saltar-se el login sense conèixer cap contrasenya.
- →Modificar o eliminar dades: comandes, preus, permisos.
- →En MySQL amb permisos de FILE: llegir fitxers del servidor o escriure webshells.
- →Escalar privilegis dins del servidor si la DB corre com a root.
Com prevenir-la correctament
1. Prepared statements (la solució definitiva)
La forma correcta de fer la consulta del login anterior utilitzant PDO en PHP:
$stmt = $pdo->prepare( "SELECT * FROM usuarios WHERE usuario = ? AND password = ?" ); $stmt->execute([$user, $pass]); // Els paràmetres mai es barregen amb l'SQL
// L'atac anterior no funciona
2. Validació i sanitització d'entrada
Encara que utilitzis prepared statements, valida sempre el tipus i format esperat. Un camp d'edat només hauria d'acceptar números. Un correu ha de tenir format vàlid. La validació no substitueix els prepared statements — els complementa.
3. Principi de mínim privilegi a la base de dades
L'usuari de base de dades que utilitza la teva aplicació només hauria de tenir els permisos estrictament necessaris. Si només necessita SELECT i INSERT, no li donis DELETE ni DROP. Si l'atacant explota un SQLi, el dany queda limitat.
4. No mostris errors SQL a l'usuari
Els missatges d'error de MySQL contenen informació que ajuda l'atacant a mapejar la teva base de dades. En producció, desactiva la visualització d'errors i guarda'ls en logs del servidor.
Vols saber si la teva web és vulnerable a SQLi?
Utilitzem SQLMap i proves manuals per detectar injeccions en formularis, URLs i capçaleres. Informe amb impacte real i codi de correcció.
Veure auditoria web →