2011-01-07 16 views
5

Soy un novato con las bibliotecas PDO. Estoy trabajando en un entorno de desarrollo con mysql como mi base de datos. Puedo ejecutar mis consultas usando la función de preparación y ejecución mientras uso "?" marcador de posición y también método bindParam al usar marcadores de posición con nombre (por ejemplo: "columna").¿Cómo sabemos que PDO está escapando de las inyecciones de SQL?

Después de esto traté de ver si PDO hace algún tipo de escape al poner en cualquier cotización para desinfectar la consulta como lo hace mysql_real_escape_string. Estoy tratando de ver cuál sería la consulta, pero todo lo que obtengo es la declaración que se ha pasado a la declaración de preparación, pero no la consulta que se ejecutará.

Intenté var_dump el $ result-> execute(), y $ result-> fetch() pero la instrucción execute me da el sql de mi declaración de preparación con placeholders mientras que la instrucción fetch me da el resultado de esa consulta.

¿Hay alguna manera de ver la consulta de búsqueda que se ejecutará o, al menos, cómo se verían los parámetros antes de ejecutar la consulta?

Espero tener claro mi pregunta. : |

+1

usted se preocupa demasiado. Las declaraciones preparadas escapan a su entrada al 100%. Si necesita ver cómo se ve la consulta final, debe configurar un registro de consulta de la base de datos. – netcoder

+1

@netcoder Las declaraciones preparadas no escapan a nada (a menos que esté en modo compatible). Y no hay nada nuevo en el registro de consultas –

+0

@Col. Metralla: Bueno, técnicamente sí, sí, aunque puedes decirlo de la manera que quieras. En cuanto a "no hay nada nuevo en el registro de consultas", simplemente no entiendo lo que eso significa ... – netcoder

Respuesta

6

Cuando se escribe algo como:

$stmt = $pdo->prepare('SELECT * FROM tbl_name WHERE col_name = :col_name;'); 
$stmt->bindValue('col_name', 'some \' value'); 
$stmt->execute(); 

El la consulta real es ... SELECT * FROM tbl_name WHERE col_name = :col_name;. Eso se llama estado preparado. En primer lugar, envía consultas a la base de datos, luego envía los parámetros de consulta. PDO no combina la consulta y los parámetros.

Usted probablemente ha pensado que PDOStatement::bindValue() hace algo como:

public function bindValue($placeholer, $value, $valueType = PDO::PARAM_STR) { 
    $this->query = str_replace($placeholder, $this->quote($value, $valueType), $this->query); 
} 

Pero no lo hace .

Hace algo más de esa manera:

public function execute() { 
    try { 
     $this->sendQueryToDatabase($this->query); 

     // Query is valid 
     $this->sendParametersToDatabase($this->parameters); 

     return $this->fetchResultSet(); 
    } catch (... $e) { 
     // Query is invalid (eg. syntax error) 
     throw ...; 
    } 
} 

Read more about Prepared Statements

+0

entonces, ¿cómo sabríamos si los parámetros enviados son seguros? ¿Necesitamos revisarlos antes de la mano? – macha

+2

Los parámetros no pueden ser inseguros ya que no son parte de la consulta. Son solo datos brutos. – Crozin

+0

hey Sé que podría ser demasiado alto, ¿tiene alguna idea sobre cómo se analizaría la consulta y cómo se enviarían/​​sustituirían estos parámetros con marcadores de posición? – macha

1

preparar la declaración es manejar por MySQL, por lo pdo no escapan a la petición, PDO enviar la solicitud y "después de" el parámetro

+0

No sé por qué está siendo rechazado, esto es realmente cierto. – netcoder

+0

Esto no es realmente cierto, PDO por lo general emula las declaraciones preparadas, ya que las declaraciones preparadas del lado del servidor, aunque son compatibles, generalmente no son una buena idea. – MarkR

+0

@MarkR solo en modo de compatibilidad que ya está obsoleto –

-1

Habilitar el registro de consultas en general, y ver las consultas en realidad se están ejecutando en el servidor cuando se está ejecutando declaraciones simples - hacer algunas inserciones , por ejemplo, con cadenas que contienen citas incrustadas o nuls.

+0

No verá nada nuevo –

3

Para ponerlo derecho.

DOP tiene 2 modos de funcionamiento de las declaraciones preparadas:

  1. modo nativo. Consulta y datos que se envían a la base de datos se-pa-ra-te-ly. Lo que significa que los datos nunca se han agregado a la consulta. Entonces, no se puede hacer daño. Nunca. La consulta que se envía a la base de datos como está, con ? marcas (pero no hay marcadores de posición nombrados que se reemplazan por PDO con ? s)
  2. Modo de compatibilidad. PDO realiza una consulta antigua, al sustituir marcadores de posición con variables vinculadas depende del nombre de la variable. Cadenas que se citan/escapan, el resto es lanzado a su tipo.

Ambos métodos son perfectamente seguros.

El verdadero peligro comienza cuando se tiene una variable de identificador ...

+0

¿por qué es peligroso el identificador de variable? Pensé que era más seguro ya que incluso verificamos el tipo de datos. – macha

+0

@macha me refiero a un nombre de campo. Por ejemplo 'SELECT * FROM table ORDER BY $ column_name' es realmente peligroso –

+0

¡Muy bien! Gracias por responder. – macha

Cuestiones relacionadas