Do data received via Request using Doctrine need to be processed?

Question

I’m developing a new project, it’s the first time I’m using Doctrine with Silex and I am in doubt as to the receipt of information through forms.

I receive the data from forms through the Request of Symfony (Symfony\Component\HttpFoundation\Request) and wanted to know if I need to use some method to filter these data like filter_input, htmlspecialchars, strip_tags, etc.?

In my case I get this data like this:

$dados = $request->request->all(); 

and caught them in:

$dados['nome'] 

for example. I need to treat or not?

Answer 1

By code (source) of Request and consequently Parameterbag, can be used as follows which already get what is expected:

$id = $request->request->getInt('id'); 
$nm = $request->request->getAlpha('name');
$st = $request->request->getBoolean('status');

or specify its own filter:

$mail = $request->request->filter('id', 0, FILTER_SANITIZE_EMAIL);

in the case mentioned all(), the data are not processed, but as reported there is the option where it can be done with filter or the implemented getInt, getAlpha, getBoolean, getDigits and getAlnum internally using this type of code, example getBoolean:

public function getBoolean($key, $default = false)
{
    return $this->filter($key, $default, FILTER_VALIDATE_BOOLEAN);
}

The Doctrine - Security has a security part, but, this can be supplemented with the code exemplified just above, or even a Validation class, can bar most problems encountered in web development with data obtained upon request http.

_References:

• Request
• Parameterbag
• 34. Security - Doctrine

Answer 2

Completing @Virgilio Novic’s reply, what says to documentation of the Doctrine:

In general you should assume that Apis in Doctrine are not safe for user input. There are However some exceptions.

Free translation:

In general, you should assume that the Apis in Doctrine are not safe for user inputs. There are, however, some exceptions.

Exceptions can be seen in the following links:

• SQL Injection: Safe and Unsafe Apis for User Input)
• User input and Doctrine ORM.

Notice what the section says 12.2.1. Wrong: String Concatenation (concreteness of strings), you should never build your queries dynamically and concatenate user inputs into your SQL or DQL query. For Doctrine there is absolutely no way to find out which parts of SQL are user inputs and which are not.

For example:

<?php
$sql = "SELECT * FROM users WHERE name = '" . $_GET['username']. "'";

Although DQL is a wrapper around SQL that can protect against some security implications, the previous example is also a threat to DQL queries, which in the end will result in a query:

$dql = "SELECT u FROM User u WHERE u.username = '" . $_GET['username'] . "'";

In this scenario, an attacker can still pass a user name defined as 'OR 1 = 1 and create a valid DQL query.

So, how to make queries safer?

• Prepared Statements: you should always use it to perform your queries. It is a two-step procedure, separating the SQL query from the parameters. They are supported for SQL DBAL queries and DQL ORM queries.

Example DQL:

$dql = "SELECT u FROM User u WHERE u.username = :name";
$query = $em->createQuery($dql);
$query->setParameter("name", $_GET['username']);
$data = $query->getResult();

Example SQL:

$sql = "SELECT * FROM users WHERE username = ?";
$stmt = $connection->executeQuery($sql, array($_GET['username']));

See more information on how to use it here.

• Quoting/Escaping: Although previously said that string concatenation is wrong, there is a way to do it correctly using the method of Connection#quote. This method is only available for SQL, not DQL. For DQL it is always encouraged to use Prepared Statements not only for security, but also for cache reasons.

Example:

$sql = "SELECT * FROM users WHERE name = " . $connection->quote($_GET['username'], \PDO::PARAM_STR);

Data received via Request using Doctrine need to be treated?

Depends on the API being used as referred to in documentation, but in general if the query is being built based on user input, yes, it is necessary to handle all entries.