inyección de SQL con la declaración "INSERT"

  

¿Es posible inyectar algo en esto incluso si está en una declaración if?

Sí. Con consultas multilínea, funciona un simple '; drop table usertable;-- . Con consultas de una sola línea, ' (select abc from def),0)-- puede funcionar, aunque con un poco más de anidamiento puedes ejecutar prácticamente cualquier cosa.

  

¿Cómo puedes escapar de esta consulta?

Simplemente escapar de todo no funcionará, ya que esto puede cambiar el significado de algunos de los personajes. Tienes que tener cuidado.

Cosas como mysqli_real_escape_string() también son vulnerable . Use declaraciones preparadas.

  

¿Existe la posibilidad de hacer eco de toda la declaración para que pueda obtener más información sobre el php utilizado, lo que significa que toda la consulta de resultados se está haciendo eco debido al código inyectado?

Claro, primero almacene la cadena y luego haga eco. Pero eso puede ser peor, es mejor si el atacante no puede ver nada. Es preferible registrar las consultas.

  

Si esto tiene una situación potencial de inyección de SQL. ¿Hay personas lo suficientemente tontas para codificar de esta manera?

No es tanto la estupidez como la falta de idea / el descuido, pero sí. La inyección de MySQL es una de las vulnerabilidades web más comunes que existen.

1) La consulta SQL simplemente envuelta en una declaración PHP if no tendrá ningún impacto sobre si un atacante puede inyectar en la declaración o no.

2) ¿Puede quien escapar de esto? Usted o el atacante? Suponiendo que te refieres al atacante, y dado el ejemplo que proporcionas, nadie puede. Los valores que ha utilizado para la consulta están codificados. Para que exista una vulnerabilidad de inyección SQL, debe utilizar la entrada usuario . Por ejemplo, el campo de entrada de correo electrónico para la consulta podría usarse para ingresar algo diferente a [email protected] en la declaración.

3) Si quiere decir si es posible que el atacante tenga esa salida en su navegador, posiblemente. Depende de su nivel de desinfección de entrada y su nivel de salida de error. Si un atacante alimenta una entrada no válida a la consulta para provocar un error de sintaxis y tiene una salida de error bastante detallada, entonces sí, es posible. Entre otras opciones de todos modos.

4) Siempre hay gente lo suficientemente tonta como para codificar de esta manera. El 99.9% de los tutoriales que he visto en Internet documentan cómo utilizar la interfaz mysql para los arrancadores que ahora han quedado en desuso. En segundo lugar, la mayoría de ellos ni siquiera hablan de seguridad y simplemente le muestran cómo obtener un bloque de código operativo con el menor esfuerzo.

Lo primero que debe comprobar aquí es el soporte para varias declaraciones en una sola consulta. Puede dejar la declaración INSERT e intentar ejecutar otra consulta SQL: $userName = x', 1); DROP TABLE userTable;#

Sin embargo, supongamos que se deshabilitan varias declaraciones (por ejemplo, el antiguo mysql_query no es compatible por defecto). La segunda idea para verificar su código PHP sería utilizar subconsultas. En lugar de insertar algunas cadenas constantes (como $ nombre, $ correo electrónico, $ nombre de usuario, etc.), podríamos intentar insertar el valor de la subconsulta:

$email = x',(SELECT 'aaa' FROM DUAL),1)# .

Esta carga útil resultaría en la consulta: INSERT INTO UserTable VALUES (NULL,'$name','x',(SELECT 'aaa' FROM DUAL),1)#', '$userName', '1')

Como puede ver, en la columna userName (de UserTable) verá el resultado de la subconsulta SELECT . Si el valor de userName se muestra en el sitio web de la víctima (que supongo que sí), el atacante podría verificar el resultado de la subconsulta insertada.

Además, si el atacante desea que no se detecte más (crear muchas entradas en la base de datos se podría notar fácilmente), podría usar técnicas de ciego-sqli o basadas en errores en subconsultas insertadas (puede encontrar más detalles here ).

El punto es que, al utilizar valores que incluyen comillas simples en los campos variables, los atacantes podrían intentar hacer todo tipo de cosas malas en su base de datos, ninguna de las cuales sería lo que pretendía que sucediera. Probablemente solo generaría muchos errores inesperados; pero hiciera lo que hiciera, no sería para su beneficio.