Usted escribe esto:
$sql = "SELECT id_user, name FROM 'TAB_USER' WHERE user = '$username'
^^^^^^^^^
SQL injection is here
El chico malo enviará como "nombre de usuario" algo que, después del reemplazo, hará que su comando SQL se vea así:
SELECT id_user, name FROM 'TAB_USER' WHERE user = 'Admin'; -- (some stuff here)
es decir, el atacante establecerá el "nombre de usuario" en la cadena: Admin'; --
¿Ver el carácter de comillas ingenioso? Esa es la palanca para el ataque. Dado que su código reemplaza brutalmente a $username
en el comando SQL, con "lo que sea que proporcione el cliente", el cliente puede proporcionar un carácter de comillas de cierre, que termina la constante de cadena, luego un punto y coma, que termina el comando, luego un --
que le dice a la base de datos "todo lo demás en la línea es un comentario, simplemente ignórelo". ¡E ignórelo que hace la base de datos!
Esto le permite al atacante iniciar sesión como administrador sin importar la contraseña que usó. Esto es inyección de SQL para libros de texto . Tome nota: puede sentirse tentado a llegar a la conclusión de que los problemas provienen del carácter "comilla", y simplemente filtrarlos sería suficiente para evitar el ataque. Esto no es así. Hay varias (muchas) formas de abusar de un sustituto brutal como el que haces, y es muy difícil atraparlas a todas; como Pokemons, cada nueva versión del software de base de datos SQL introduce nuevas especies. La gente intentó pensar en la inyección de SQL como un problema de "escapar de los problemas de los personajes"; así que diseñaron esta función . Luego, intentaron nuevamente . Y todavía falló. Sólo el dolor te espera en este camino; no lo camines No espere un mysql_really_escape_string_this_time_i_said_please()
. En su lugar, use declaraciones preparadas .