SQL sin formato
Cuando estás escribiendo SQL, para cualquier cosa que realmente requiera aportaciones humanas, se han hecho muchas cosas para evitar la inyección.
Todos los que han oído hablar de la inyección SQL saben que (voy a usar PHP como ejemplo) hacer algo como esto no es seguro:
$sql = "SELECT * FROM 'users'
. WHERE 'userName' = "{$_POST["username"]}"
. AND 'pass' = "{$_POST["pass"]}";";
Magia
Luego, por supuesto, alguien tuvo la idea de usar "citas de escape mágico" para lidiar con la información del programa que no se había saneado correctamente y se colocó directamente en SQL como resultado de las malas prácticas. Esto realmente no resolvió el problema con la inyección de SQL, pero sí significó que se modificaron todas las entradas de los usuarios.
Añadiendo barras diagonales
Por lo tanto, algunas personas desactivaron las citas mágicas. Luego, analizaron las entradas del usuario antes del punto de SQL a través de addslashes() que, en teoría, escapa a todas las comillas y su pirata informático no puede hacer ' OR 1=1 , pero incluso la documentación para addlashes dice que no debe usar addlashes, dice que usa la función específica de la base de datos como mysql_real_escape_string() , pero algunos todavía dicen que esto no es suficiente.
Agregar barras específicas a la base de datos
Por lo tanto, no podemos usar *_real_escape_string específico de DBMS, no podemos usar add slashes , la cosa de "citas mágicas" causó muchos problemas, y la web está llena de citas con palabras cortas como:
"Un hacker dedicado encontrará una manera de saltar a través de sus bucles de cotización de escape, simplemente use las declaraciones preparadas de DBAL "- John Q cualquier programador
Bueno, eso me asustó lo suficiente como para usar las declaraciones de preparación y un DBAL. Realmente no explicó nada, pero suena bien porque lo he escuchado mucho.
Declaraciones preparadas
Así que ahora estamos usando PDO, o un DBAL de un marco, o alguna otra cosa que envuelva todos nuestros sql y se asegure de que alguien no pueda ejecutar una inyección de sql.
Mi pregunta es básicamente un "¿por qué no?", no un "¿qué debo usar?". La web está llena de personas que le dicen que use esto o que use eso o lo que sea , pero no hay explicaciones de por qué tuvieron que suceder estas cosas.
Preguntas directas
Preguntas puntuales (recordatorio, estoy preguntando sobre SQL, PHP fue un lenguaje de ejemplo debido a su mala reputación con respecto a SQL, los conceptos son universales):
- ¿Por qué no podemos escapar de todas las entradas del usuario usando "magia"?
- ¿Por qué las barras no eran "suficientemente buenas"?
- ¿Qué tiene de malo usar las funciones de escape específicas de la base de datos, y por qué fue mejor que las barras agregadas?
- ¿Por qué las declaraciones preparadas con marcos y PDO se consideran como el estándar de oro de SQL? ¿Por qué son mejores? ¿Por qué no puedo hacer una inyección de SQL con estos, donde, como PODRÍA HACER con los medios mencionados anteriormente? ¿Puede un programador que no de alguna manera logre arruinar esto? ¿Qué deben tener en cuenta?
- ¿Alguna otra preocupación que no haya mencionado?