mysql - reales - tipos de inyeccion sql

Sin interactividad de usuario ¿Puedo obtener inyección de SQL?

Question

Tengo páginas que solo muestran datos de tablas de DB, las páginas de php solo muestran la información, no tienen botones, enlaces, menús desplegables o formularios.

Estoy usando el viejo mysql y no el mysqli o PDO para la sintaxis

¿Todavía puedo obtener un truco de inyección SQl?

Answer 1

La inyección SQL funciona al inyectar cadenas en el SQL que está ejecutando.

Esto es más fácil si la aplicación le presenta un bonito cuadro de texto cuyo contenido pega en una consulta SQL, pero también es posible a través de otros medios.

Por ejemplo, si su aplicación de informes utiliza algún tipo de solicitud HTTP para mostrar datos, un atacante puede usar WGET para suplantar la solicitud e inyectar SQL. Por ejemplo, si sus informes tienen un formato URL de http://myserver/report.php?month=february y utiliza february para generar una consulta SQL, usted es vulnerable.

Answer 2

Para que SQL Injection funcione, necesitan una forma de enviar código SQL a su servidor, ya que no hay entrada, es teóricamente imposible para ellos Inyectar SQL. (Aunque no soy un experto en el tema)

Aún así, le recomendaría que utilice un marco como mysqli o PDO, debe familiarizarse con dichos marcos, ya que se convirtieron en la norma en el diseño de sitios web.

Answer 3

Si la consulta es independiente de la solicitud, está a salvo. Ten en cuenta que los usuarios malintencionados son muy creativos. Es posible que tenga cierta dependencia de los datos del usuario que no conoce. Por ejemplo, un script como este podría estar roto:

$locale = Locale::acceptFromHttp($_SERVER[''HTTP_ACCEPT_LANGUAGE'']);
$sql = "SELECT * FROM entities WHERE id = 7 and locale = ''$locale''";

^{Descargo de responsabilidad: no estoy al tanto si Locale::acceptFromHttp() realiza alguna validación. Supongamos que para el contexto de esta publicación no.}

No quiero decir que no es posible escribir código seguro sin declaraciones preparadas . OTOH realmente no duele usarlos.

Answer 4

Todo depende del origen de la consulta. Si CUALQUIER parte de su consulta SQL proviene de una entrada del usuario (en otras palabras, si no toda su cadena de consulta es una cadena constante) entonces no está seguro.

Por ejemplo:

SELECT * FROM USERS ;
SELECT * FROM myTable WHERE id = 5;

es seguro, pero

SELECT * FROM myTable WHERE id = (some variable derived from user input like querystring or post-form)

es DEFINITIVAMENTE no.

Deberías usar

SELECT * FROM myTable WHERE id = @0 

sintaxis para la máxima seguridad Esta es la única forma comprobada de mantenerse a salvo de la inyección de SQL.

Answer 5

Tengo páginas que solo muestran datos de tablas de DB, las páginas de php solo muestran la información, no tienen botones, enlaces, menús desplegables o formularios.

Me atrevería a decir que tal configuración es simplemente imposible .

La sola idea de tener una página web dinámica , servida por una secuencia de comandos php desde la base de datos, es usar la misma secuencia de comandos para mostrar diferentes contenidos de la base de datos.

Por lo tanto, o bien usted solo tiene un conjunto de páginas estáticas (lo cual dudo), entonces no necesita PHP / base de datos para ellas, solo HTML estático sería suficiente.

O, lo más probable, tiene páginas dinámicas que muestran contenido basado en la entrada del usuario de algún tipo, y por lo tanto, perfectamente vulnerable.

Answer 6

La inyección SQL ocurre si los datos controlables por el usuario se usan en una declaración SQL sin el procesamiento adecuado:

El software construye todo o parte de un comando SQL usando entrada influenciada externamente desde un componente en sentido ascendente, pero no neutraliza o neutraliza incorrectamente elementos especiales que podrían modificar el comando SQL deseado cuando se envía a un componente en sentido descendente.

Sin una eliminación suficiente o sintaxis de la sintaxis de SQL en las entradas controlables por el usuario, la consulta SQL generada puede hacer que esas entradas se interpreten como SQL en lugar de datos de usuario ordinarios.

Tenga en cuenta que los datos controlables por el usuario incluyen cualquier dato que pueda ser influenciado por la solicitud de un usuario, directa o indirectamente.

Por el contrario, esto significa que si sus consultas SQL no contienen ningún dato controlable por el usuario, es decir, las consultas están corregidas en código y no están influenciadas por ninguna entrada modificable, no pueden ser vulnerables a las inyecciones de SQL.