Development

#7855 (Custom SQL syntax in Symfony Book is open to SQL injection attacks)

You must first sign up to be able to contribute.

Ticket #7855 (closed documentation: fixed)

Opened 4 years ago

Last modified 4 years ago

Custom SQL syntax in Symfony Book is open to SQL injection attacks

Reported by: rroblak Assigned to: fabien
Priority: major Milestone:
Component: model Version: 1.2.0
Keywords: Cc:
Qualification: Unreviewed

Description

The custom SQL syntax suggested in the Symfony Book 1.0 is vulnerable to SQL injection attacks. The concerned section is here: http://www.symfony-project.org/book/1_0/08-Inside-the-Model-Layer#chapter_08_sub_using_raw_sql_queries

Although I have only tested this on Symfony 1.0, I believe all versions of the documentation are incorrect since little has changed in this section of the book in the newer versions.

The following code demonstrates the vulnerability:

$connection = Propel::getConnection();
$query = "SELECT %s as user_id,
                 %s as email
          FROM %s
          WHERE %s='%s'";

$query = sprintf($query,
                 UserPeer::USER_ID,
                 UserPeer::EMAIL,
                 UserPeer::TABLE_NAME,
                 UserPeer::USERNAME,
                 "myuser'; UPDATE user SET email='vulnerable@example.com' WHERE user_id=1 AND username<>'");

$statement = $connection->prepareStatement($query);
$rs = $statement->executeQuery();

This is a serious problem as the Book is used by many as the definitive source of information for both Symfony and Propel. See http://propel.phpdb.org/trac/wiki/Users/Documentation/1.3/Upgrading for examples in Propel 1.2 and 1.3 of how to properly prepare custom SQL queries that are not open to injection attacks (search for "General DB API Changes").

Change History

12/09/09 09:39:22 changed by FabianLange

you are correct, ill fix this in the book. please let me know if we have such an example somewhere else

12/09/09 09:54:40 changed by FabianLange

  • status changed from new to closed.
  • resolution set to fixed.

(In [25116]) [doc] fixed incorrect usage of prepared statements (fixes #7855)