¿La eliminación de espacios en una cadena protegería contra la inyección de SQL?

No. La eliminación de espacios no evitaría la inyección de SQL, ya que hay muchas otras formas de hacer que el analizador procese su entrada. Veamos un ejemplo. Imagina que tenías una URL que usaba la entrada proporcionada por el usuario de forma poco segura en una consulta:

enlace = > SELECT * from page where id = 1

En tu ejemplo, el atacante usaría espacios:

enlace = > %código%.

Eliminar los espacios colapsaría la inyección en una cadena.

Ahora imaginemos que el atacante usó otra forma de espacio en blanco, es decir, pestañas:

enlace = > %código%.

Eliminar los espacios todavía permitiría la inyección.

Dependiendo de la tecnología en uso, el atacante podría reemplazar los espacios con SELECT * from page where id = 1 or 1=1 SELECT * from page where id = 1 or 1=1 /**/ %00 %09 o cualquier número de Unicodes que cause la tokenización por el analizador SQL. Si bien el ejemplo al que se hace referencia eliminó más que solo espacios, el ejemplo mencionado anteriormente aprovecha los comentarios de SQL para provocar la tokenización que no son espacios en blanco. Aún serías vulnerable.

La única forma confiable de evitar la inyección de SQL es usar consultas parametrizadas.

Estamos en 2016! Las inyecciones de SQL son cosa del pasado, a menos que utilice un código inseguro.

Sea cual sea el idioma que use, si desea evitar cualquier all inyecciones de SQL, utilice declaraciones preparadas o cualquier otro tipo de enlace de datos.

Las declaraciones preparadas separan la consulta de los datos, lo que hace imposible que los datos afecten a la consulta.

Para responder directamente a su pregunta, la eliminación de espacios reduciría las inyecciones de SQL (al usar códigos y bibliotecas desactualizados), pero seguramente limitaría el texto de entrada (sin espacios en ninguna parte).

Limitaría el problema, pero no lo eliminaría. Considere la siguiente situación:

$un = str_replace(" ", "", $_POST["username"]);
$pw = hash($_POST["password"];
$sql = "SELECT * FROM users WHERE username = '$un' AND password = '$pw'";

Digamos que publico el nombre de usuario admin'-- . Eso me registraría como administrador, sin usar un solo espacio.

Como señala wireghoul , también deberá eliminar otros caracteres en blanco como la pestaña. Pero como lo señala Julie Pelletier , solo use las declaraciones preparadas. Tratar de idear esquemas inteligentes para detener SQLi sin que sea un juego divertido, pero nunca le dará la seguridad que ofrecen las declaraciones preparadas. Todo lo demás es solo una distracción.

No . Digamos que tienes esto como tu SQL:

"select * from people where last_name = '" + surname + "'"

Si escribo: 'OR(1=1)OR'a'=' en la entrada, se convierte en:

select * from people where last_name = ''OR(1=1)OR'a'=''

Que se ejecuta en Oracle y MySQL (al menos) y devuelve todas las filas de la tabla.

  

Sin embargo, si tomaste esa cadena de búsqueda

     

update aTable set someColumn='JackedUpValue' where someColumn like   y realizó la operación que se muestra en esta pregunta, ¿no lo obtendría?

     

updateaTablesetsomeColumn='JackedUpValue'wheresomeColumnlike cuales   no debería ejecutar, ¿verdad?

Como han señalado otros, hay otras formas de incluir los espacios en blanco en varias implementaciones de bases de datos SQL que debería tener en cuenta, como las pestañas y \n (nueva línea). Casi todos los motores de bases de datos aceptarían con gusto:

update
aTable
set
someColumn='JackedUpValue'

Puede haber varios caracteres Unicode que funcionan como espacios en blanco según las configuraciones de localización en varias bases de datos, pero realmente tendrías que profundizar en los detalles de la implementación para descubrirlo. Realmente no hay razón para tratar de cubrir todos estos casos de borde para el reemplazo de cadenas, en lugar de usar solo consultas parametrizadas.

Así que aquí hay una idea. Los servidores de base de datos toman la consulta SQL entrante y la ejecutan a través de un analizador que da como resultado un árbol de análisis. Luego convierten el árbol en un plan y ejecutan el plan.

La esencia de la inyección es que el analizador produce un árbol diferente del diseñado por el programador.

Por lo tanto, la solución es poder detectar árboles de análisis inusuales. Camine por el árbol después de analizar y produzca una cadena en forma canónica menos los valores de los datos. Calcular un hash SHA de la cadena. Mantenga una tabla de hashes conocidos para el usuario de la aplicación / base de datos. Avisar o cancelar si el servidor ve un hash desconocido.

Obviamente, hay un problema de inicio. Por lo tanto, el programador tendría que ejecutar la aplicación en un modo de prueba, extraer los hashes después de las pruebas exhaustivas y cargar el servidor con los hashes en el inicio de la aplicación. Luego active abort-on-new-hash y no será posible realizar más inyecciones SQL.