Why does the PDO guide say SQL injection is still possible with PDO?

Question

http://php.net/manual/en/pdo.prepared-statements.php

If the application uses exclusively prepared statements, the developer can be sure that SQL injection will not happen (however, if other parts of the query are created with unescaped input, SQL injection is still possible).

What are the possible scenarios when some of the data is not displayed? Is this possible if all the other data goes to the database using PDO?

I am thinking of a scenario where another input is processed using mysql_ * functions, rather than using mysql_real_escape_string. Is there anything else that could be a threat?

Many thanks. Relations

Answer 1

This means that you cannot use unreliable values ​​directly, for example. as the name of a column or table — or as a LIMIT parameter.

For example, it is safe:

$query = "SELECT * FROM tbl WHERE col = ?"; 

while this is not so:

 $query = 'SELECT * FROM tbl WHERE col = ? LIMIT ' . $_GET['limit']; $query = 'SELECT * FROM tbl WHERE ' . $_GET['field'] . ' = ?'; $query = "SELECT * FROM tbl WHERE col = ? AND othercol = '" . $_GET['other'] . "'"; $query = 'SELECT * FROM ' . $_GET['table'] . ' WHERE col = ?'; 

Basically, prepared statement placeholders are intended to be used where you would use the escaped value in single quotes in a classic query.

In case you are wondering why databases usually do not support placeholders for things like table names: in addition to the fact that dynamic table and column names are not common, the database engine usually optimizes the prepared statement when preparing it. This, however, cannot be done correctly without knowing which tables / columns are available.

Answer 2

Consider this:

 $sql = "SELECT * FROM ".$_GET['tablename']." WHERE somecol = ?"; 

Since I filled the table name with unshielded user input, it would be possible to go through, for example, public_table p LEFT JOIN hidden_table h ON h.id = p.id and get results that you didn’t want me to, even if you avoided the value passed to somecol comparison .

The fact is that although prepared statements safely avoid entering any user that you pass in ? in a query, they cannot escape the data that already existed in the row before passing it to prepare() .

Answer 3

This means that you are not luring PDO into thinking - a magic pill ... if you do not use prepared statements, you will still be vulnerable.