Comment puis-je prévenir l'injection SQL en PHP?

Obsolète Avertissement:
Cette réponse est un exemple de code (comme la question de l'exemple de code) utilise PHP MySQL extension, qui a été dépréciée en PHP 5.5.0 et enlevé entièrement en PHP 7.0.0.

Avertissement de sécurité: Cette réponse n'est pas en ligne avec les meilleures pratiques de sécurité. L'échappement est insuffisante pour prévenir l'injection SQL, utilisez préparées à la place. Utiliser la stratégie décrite ci-dessous à vos propres risques. (Aussi, mysql_real_escape_string() a été supprimé en PHP 7.)

Si vous utilisez une version récente de PHP, le mysql_real_escape_string option décrite ci-dessous n'est plus disponible (bien que mysqli::escape_string est l'équivalent moderne). Ces jours-ci le mysql_real_escape_string option n'a de sens que pour le code de legs sur une ancienne version de PHP.

---

Vous avez deux options s'échapper les caractères spéciaux dans votre unsafe_variable, ou à l'aide d'une requête paramétrée. Les deux devraient vous protéger contre l'injection SQL. La requête paramétrée est considéré comme la meilleure pratique, mais il faudra modifier pour une nouvelle extension MySQL en PHP avant de pouvoir l'utiliser.

Nous parlerons de l'impact plus faible de la chaîne échapper une première.

//Connect

$unsafe_variable = $_POST["user-input"];
$safe_variable = mysql_real_escape_string($unsafe_variable);

mysql_query("INSERT INTO table (column) VALUES ('" . $safe_variable . "')");

//Disconnect

Voir aussi, les détails de l' mysql_real_escape_string fonction.

À l'utilisation de la requête paramétrée, vous devez utiliser MySQLi plutôt que de la MySQL fonctions. Pour reprendre ton exemple, nous aurions besoin de quelque chose comme ce qui suit.

<?php
    $mysqli = new mysqli("server", "username", "password", "database_name");

    //TODO - Check that connection was successful.

    $unsafe_variable = $_POST["user-input"];

    $stmt = $mysqli->prepare("INSERT INTO table (column) VALUES (?)");

    //TODO check that $stmt creation succeeded

    //"s" means the database expects a string
    $stmt->bind_param("s", $unsafe_variable);

    $stmt->execute();

    $stmt->close();

    $mysqli->close();
?>

La touche de fonction, vous aurez envie de lire, il y aurait mysqli::prepare.

Aussi, comme d'autres l'ont suggéré, vous trouverez peut-être utile/plus facile à l'étape d'une couche d'abstraction avec quelque chose comme AOP.

Veuillez noter que le cas vous m'avez demandé est assez simple et que les cas plus complexes peuvent nécessiter des approches plus complexes. En particulier:

• Si vous souhaitez modifier la structure de la SQL basé sur la saisie de l'utilisateur, les requêtes paramétrées ne sont pas va aider, et la trajectoire de besoin n'est pas couvert par mysql_real_escape_string. Dans ce genre de cas, vous feriez mieux de passer l'entrée de l'utilisateur par le biais d'une liste blanche pour s'assurer que seuls des " sûr " les valeurs sont autorisés à traverser.
• Si vous utilisez des nombres entiers à partir de la saisie de l'utilisateur dans une situation et de prendre les mysql_real_escape_string approche, vous allez souffrir de ce problème est décrit par Polynôme dans les commentaires ci-dessous. Ce cas est plus délicat parce que les entiers ne serait pas être entouré par des guillemets, de sorte que vous pourriez traiter par la validation de la saisie de l'utilisateur ne contient que des chiffres.
• Il y a probablement d'autres cas, je ne suis pas au courant. Vous pourriez trouver cette est une ressource utile sur certains de la plus subtile des problèmes que vous pouvez rencontrer.

Je vous recommande d'utiliser AOP (PHP Data Objects) pour exécuter des requêtes SQL paramétrées.

Cela ne fait pas que protéger contre les injections SQL, il permet également d'accélérer les requêtes.

Et en utilisant PDO plutôt que mysql_, mysqli_, et pgsql_ fonctions, vous faites de votre application un peu plus abstraite à partir de la base de données, dans de rares cas que vous devez passer des fournisseurs de bases de données.

Comme vous pouvez le voir, les gens vous suggérons d'utiliser les requêtes préparées tout au plus. C'est pas faux, mais si votre requête est exécutée juste une fois par processus, il y aurait une légère perte de performance.

J'ai été confronté à ce problème, mais je pense que je l'ai résolu en très manière sophistiquée - la façon dont les pirates de l'utiliser pour éviter à l'aide de citations. Je l'utilise en conjonction avec des émules déclarations préparées à l'avance. Je l'utilise pour prévenir tous sortes de possibles attaques par injection SQL.

Mon approche:

• Si vous prévoyez d'entrée d'être entier assurez-vous que c'est vraiment entier. Dans une variable de type langage comme PHP c'est ce très important. Vous pouvez utiliser, par exemple, cette solution simple mais efficace: sprintf("SELECT 1,2,3 FROM table WHERE 4 = %u", $input);

• Si vous vous attendez à rien d'autre de entier hex il. Si vous hex, vous pourrez parfaitement échapper à toutes les entrées. En C/C++ il y a une fonction appelée mysql_hex_string(), en PHP, vous pouvez utiliser bin2hex().

  Ne vous inquiétez pas échappé à la chaîne aura un 2x la taille de sa longueur d'origine, parce que même si vous utilisez mysql_real_escape_string, PHP a pour allouer de la même capacité ((2*input_length)+1), qui est le même.

• Cet hex méthode est souvent utilisée lorsque vous transférez des données binaires, mais je ne vois pas de raison de ne pas l'utiliser sur toutes les données pour éviter les attaques par injection SQL. Notez que vous devez ajouter des données avec 0x ou utiliser la fonction MySQL UNHEX à la place.

Ainsi, par exemple, la requête:

SELECT password FROM users WHERE name = 'root'

Deviendra:

SELECT password FROM users WHERE name = 0x726f6f74

ou

SELECT password FROM users WHERE name = UNHEX('726f6f74')

Hex est l'évasion parfaite. Aucun moyen de l'injection.

Différence entre UNHEX fonction et le préfixe 0x

Il y a des discussions dans les commentaires, donc je tiens enfin à préciser. Ces deux approches sont très similaires, mais ils sont un peu différentes à certains égards:

L' ** 0** préfixe peut être utilisé uniquement pour les colonnes de données telles que char, varchar, text, bloc, binaire, etc.

Aussi, son utilisation est un peu compliqué si vous êtes sur le point d'insérer une chaîne vide. Vous aurez à remplacer entièrement avec '', ou vous obtiendrez une erreur.

UNHEX() fonctionne sur tout colonne; vous n'avez pas à vous soucier de la chaîne vide.

---

Hex méthodes sont souvent utilisées comme des attaques

Noter que cet hex méthode est souvent utilisée comme une attaque par injection SQL, où les entiers sont juste comme les chaînes et les échappés juste avec mysql_real_escape_string. Ensuite, vous pouvez éviter l'utilisation de guillemets.

Par exemple, si vous venez de faire quelque chose comme ceci:

"SELECT title FROM article WHERE id = " . mysql_real_escape_string($_GET["id"])

une attaque peut vous injectez très facilement. Considérez les points suivants code injecté est retourné à partir de votre script:

SÉLECTIONNEZ ... where id = -1 union all select table_name de information_schema.tables

et maintenant il suffit d'extraire structure de la table:

SÉLECTIONNEZ ... where id = -1 union all select column_name de information_schema.colonne où table_name = 0x61727469636c65

Et puis il suffit de sélectionner toutes les données, celles veulent. N'est-ce pas cool?

Mais si le vendeur d'un produit injectable site hex-il, pas d'injection serait possible parce que la requête devrait ressembler à ceci: SELECT ... WHERE id = UNHEX('2d312075...3635')

Que vous pourriez faire quelque chose de simple comme ceci:

$safe_variable = mysqli_real_escape_string($_POST["user-input"], $dbConnection);
mysqli_query($dbConnection, "INSERT INTO table (column) VALUES ('" . $safe_variable . "')");

Cela ne va pas résoudre tous les problèmes, mais c'est un très bon tremplin. J'en ai laissé évidente des éléments tels que la vérification de la variable de l'existence, format (chiffres, lettres, etc.).

Obsolète Avertissement:
Cette réponse est un exemple de code (comme la question de l'exemple de code) utilise PHP MySQL extension, qui a été dépréciée en PHP 5.5.0 et enlevé entièrement en PHP 7.0.0.

Avertissement de sécurité: Cette réponse n'est pas en ligne avec les meilleures pratiques de sécurité. L'échappement est insuffisante pour prévenir l'injection SQL, utilisez préparées à la place. Utiliser la stratégie décrite ci-dessous à vos propres risques. (Aussi, mysql_real_escape_string() a été supprimé en PHP 7.)

Requête paramétrée ET la validation des entrées est le chemin à parcourir. Il ya beaucoup de scénarios pour lesquels l'injection SQL peut se produire, même si mysql_real_escape_string() a été utilisé.

Ces exemples sont vulnérables à l'injection SQL:

$offset = isset($_GET['o']) ? $_GET['o'] : 0;
$offset = mysql_real_escape_string($offset);
RunQuery("SELECT userid, username FROM sql_injection_test LIMIT $offset, 10");

ou

$order = isset($_GET['o']) ? $_GET['o'] : 'userid';
$order = mysql_real_escape_string($order);
RunQuery("SELECT userid, username FROM sql_injection_test ORDER BY `$order`");

Dans les deux cas, vous ne pouvez pas utiliser ' pour protéger l'encapsulation.

Source: L'Inattendu Injection SQL (Lors de l'évacuation n'Est Pas Assez)

Je préfère procédures stockées (MySQL a eu des procédures stockées depuis 5.0) à partir d'un point de vue sécurité - les avantages sont -

1. La plupart des bases de données (y compris MySQL) permettent à l'utilisateur d'un accès limité à l'exécution des procédures stockées. Fine-grain de sécurité de contrôle d'accès est utile pour prévenir l'escalade de privilèges d'attaques. Cela empêche compromis applications d'être en mesure d'exécuter SQL directement à l'encontre de la base de données.
2. Ils abstraction de la crue de la requête SQL à partir de l'application, de sorte que moins d'informations de la structure de base de données est disponible à la demande. Cela rend plus difficile pour les gens à comprendre la structure sous-jacente de la base de données et concevoir des attaques.
3. Ils acceptent uniquement les paramètres, de sorte que les avantages de requêtes paramétrées sont là. Bien sûr IMO - vous besoin de stériliser vos commentaires, surtout si vous utilisez SQL dynamique à l'intérieur de la procédure stockée.

Les inconvénients sont -

1. Ils (procédures stockées) qui sont difficiles à maintenir, et ont tendance à se multiplier très rapidement. Cela rend la gestion d'un problème.
2. Ils ne sont pas très approprié pour les requêtes dynamiques - si elles sont construites à accepter de code dynamique en tant que paramètres, puis beaucoup de les avantages sont annulés.

Je pense que si quelqu'un veut utiliser PHP et MySQL ou quelque autre serveur de base de données:

1. Réfléchir à l'apprentissage AOP (PHP Data Objects) – c'est un accès à la base de la couche de fournir une méthode uniforme de l'accès à plusieurs bases de données.
2. Réfléchir à l'apprentissage MySQLi
3. Utiliser les fonctions PHP natives comme: strip_tags, mysql_real_escape_string ou si la variable numérique, juste (int)$foo. Lire plus sur le type de variables en PHP ici. Si vous utilisez des bibliothèques comme PDO ou MySQLi, utilisez toujours PDO::quote() et mysqli_real_escape_string().

---

Bibliothèques exemples:

---- AOP

----- Pas d'espaces réservés mûrs pour l'injection SQL! C'est mauvais

$request = $pdoConnection->("INSERT INTO parents (name, addr, city) values ($name, $addr, $city)");

----- Sans nom des espaces réservés

$request = $pdoConnection->("INSERT INTO parents (name, addr, city) values (?, ?, ?);

----- Nommée espaces réservés

$request = $pdoConnection->("INSERT INTO parents (name, addr, city) value (:name, :addr, :city)");

--- MySQLi

$request = $mysqliConnection->prepare('
       SELECT * FROM trainers
       WHERE name = ?
       AND email = ?
       AND last_login > ?');

    $query->bind_param('first_param', 'second_param', $mail, time() - 3600);
    $query->execute();

---

P. S:

AOP gagne cette bataille avec la facilité. Avec le soutien de douze
les différents pilotes de base de données et les paramètres nommés, nous pouvons ignorer l'
petite perte de performance, et de s'habituer à son API. En matière de sécurité
point de vue, deux d'entre eux sont en sécurité tant que le développeur utilise
la façon dont ils sont censés être utilisés

Mais alors que les deux PDO et MySQLi sont assez rapide, MySQLi effectue
pas significativement plus rapide dans les benchmarks – ~2,5% pour les non-préparés
états, et ~6,5% pour ceux préparés.

Et s'il vous plaît tester chaque requête à votre base de données - c'est une meilleure façon de prévenir l'injection.

Si vous voulez prendre avantage de les moteurs de cache, comme Redis ou Memcached, peut-être DALMP pourrait être un choix. Il utilise pure MySQLi. Vérifiez ceci: DALMP Couche d'Abstraction de Base de MySQL à l'aide de PHP.

Aussi, vous pouvez préparer vos arguments avant de préparer votre requête, de sorte que vous pouvez construire des requêtes dynamiques et à la fin ont entièrement préparées requête. DALMP Couche d'Abstraction de Base de MySQL à l'aide de PHP.

À l'aide de cette fonction PHP mysql_escape_string() vous pouvez obtenir une bonne prévention dans une voie rapide.

Par exemple:

SELECT * FROM users WHERE name = '".mysql_escape_string($name_from_html_form)."'

mysql_escape_string Échappe une chaîne pour l'utiliser dans un mysql_query

Pour plus de prévention, vous pouvez ajouter à la fin ...

wHERE 1=1   or  LIMIT 1

Enfin, vous bénéficiez de:

SELECT * FROM users WHERE name = '".mysql_escape_string($name_from_html_form)."' LIMIT 1

La simple alternative à ce problème pourrait être résolu par l'octroi des autorisations appropriées dans la base de données elle-même.
Par exemple: si vous utilisez une base de données MySQL puis entrez dans la base de données par le biais du terminal ou de l'INTERFACE utilisateur fournie et il suffit de suivre cette commande:

 GRANT SELECT, INSERT, DELETE ON database TO username@'localhost' IDENTIFIED BY 'password';

Cela permettra de limiter l'utilisateur à obtenir enfermé avec la requête spécifiée uniquement. Supprimer l'autorisation de supprimer et de sorte que les données ne seraient jamais être supprimés de la requête tiré à partir de la page PHP.
La deuxième chose à faire est de rincer les privilèges de sorte que le MySQL actualise les autorisations et les mises à jour.

FLUSH PRIVILEGES; 

plus d'informations sur rincer.

Pour voir les privilèges de l'utilisateur de feu, la requête suivante.

select * from mysql.user where User='username';

En savoir plus sur SUBVENTION.

Concernant beaucoup de réponses utiles, je l'espère, pour ajouter des valeurs à ce fil.
L'injection SQL est une attaque qui peut être fait à travers l'utilisation d'intrants (Inputs qui rempli par l'utilisateur, puis utilisé à l'intérieur de requêtes), L'injection SQL modèles sont corriger la syntaxe de la requête, alors que nous pouvons appeler: mauvais requêtes pour de mauvaises raisons, nous supposons qu'il existe peut-être une mauvaise personne que d'essayer d'obtenir des informations secrètes (sans passer par le contrôle d'accès) qui affectent les trois principes de la sécurité (Confidentialité, Intégrité, Disponibilité).

Maintenant, notre but est de prévenir les menaces de sécurité telles que les attaques par injection SQL, la question (Comment éviter les attaques par injection SQL à l'aide de PHP), soit plus réaliste, le filtrage de données ou de compensation des données d'entrée est le cas lors de l'utilisation par l'utilisateur des données d'entrée à l'intérieur de cette requête, à l'aide de PHP ou tout autre langage de programmation n'est pas le cas, ou comme recommandé par plus de personnes à utiliser les techniques modernes telles que la déclaration ou tout autre outils qui soutiennent actuellement l'injection SQL de prévention, de considérer que ces outils n'est plus disponible? Comment sécuriser votre application?

Mon approche contre l'injection SQL est: l'effacement de l'utilisateur des données d'entrée avant de l'envoyer à la base de données (avant de l'utiliser à l'intérieur de la requête).

Filtrage des données pour la Conversion dangereux de données de sécurité des données)
Considérer que AOP et MySQLi pas disponibles, comment pouvez-vous sécuriser votre application? - Vous me forcer à les utiliser? Quelles sont les autres langues autres que PHP? Je préfère donner des idées, car il peut être utilisé pour la plus large de la frontière et pas seulement pour des langues spécifiques.

1. Utilisateur SQL (en limitant les privilèges d'utilisateur): la plupart des communes les opérations SQL sont (SELECT, UPDATE, INSERT), alors, pourquoi donner à JOUR privilège à un utilisateur qui en a pas besoin? Par exemple de connexion, et les pages de recherche sont uniquement à l'aide de SELECT, alors, pourquoi à l'aide de DB utilisateurs dans ces pages avec des privilèges élevés?
   RÈGLE: ne pas créer un utilisateur de base de données pour tous les privilèges, pour toutes les opérations SQL, vous pouvez créer votre régime comme (deluser, selectuser, updateuser) que les noms d'utilisateur pour l'usage facile.

voir Principe du moindre privilège

1. Filtrage des données: avant de construire la requête saisie de l'utilisateur doit être validé et filtrée, pour les programmeurs, il est important de définir quelques propriétés pour chaque utilisateur les variables d'entrée:
   type de données, le modèle de données, et les données de longueur. un champ est un nombre entre (x et y) doit être exactement validé à l'aide de règle précise, pour un champ est une chaîne de caractères (texte): le motif est le cas, par exemple, le nom d'utilisateur doit contenir seulement certains caractères permet de dire que [a-zA-Z0-9_-.] la longueur varie entre (x et n) où x et n (entiers, x <=n ).
   Règle: la création exacte des filtres et des règles de validation sont les meilleures pratiques pour moi.

2. Utiliser d'autres outils: Ici, je vais également d'accord avec vous que l'instruction préparée (paramétrées requête) et les procédures Stockées, les inconvénients ici est de ces moyens nécessite des compétences qui n'existent pas pour la plupart des utilisateurs, l'idée de base ici est de faire la distinction entre les requêtes SQL et les données qui sont utilisées à l'intérieur, les deux approches peuvent être utilisées, même à l'insécurité des données, car l'utilisateur-données d'entrée ici de ne pas ajouter quoi que ce soit à la requête d'origine tels que (tout ou x=x).
   Pour plus d'informations, veuillez lire OWASP SQL Injection de Prévention de la Feuille de Triche.

Maintenant, si vous êtes un utilisateur avancé, de commencer à utiliser ce moyen de défense que vous voulez, mais, pour les débutants, s'ils ne peuvent pas mettre en œuvre rapidement la procédure stockée et prépare la déclaration, il est préférable de filtrer les données d'entrée autant qu'ils le peuvent.

Enfin, considérons que l'utilisateur envoie ce texte ci-dessous au lieu d'entrer son nom d'utilisateur:

[1] UNION SELECT IF(SUBSTRING(Password,1,1)='2',BENCHMARK(100000,SHA1(1)),0) User,Password FROM mysql.user WHERE User = 'root'

Cette entrée peut être vérifié en début sans aucune déclaration préparée à l'avance et les procédures stockées, mais pour être sur le côté sûr, leur utilisation commence lorsque l'utilisateur-données de filtrage et de validation.

Le dernier point est de détecter un comportement inattendu qui nécessite plus d'effort et de la complexité; elle n'est pas recommandée pour la majorité des applications web.
Un comportement inattendu dans au-dessus de la saisie de l'utilisateur est de SÉLECTIONNER, de l'UNION, SI, SUBSTRING, l'indice de RÉFÉRENCE, SHA, racine une fois ces mots détectés, vous pouvez éviter l'entrée.

UPDATE1:

Un utilisateur a fait observer que ce post est inutile, OK! Voici ce que OWASP.ORG fournis:

Défense principale: le

Option #1: Utilisation des requêtes Préparées (Requêtes Paramétrées)

Option #2: Utilisation de Procédures Stockées

Option #3: Échapper à tout Utilisateur d'Entrée Fourni

Supplémentaires défenses:

Appliquer: Moins De Privilège

Également Effectuer: Blanc Entrée De La Liste De Validation

Comme vous le savez peut-être, revendiquant un article doit être pris en charge par un argument valide, au moins une référence! Sinon, c'est considéré comme une attaque, mauvaise revendication!

Update2:

Du manuel PHP, PHP: Préparé États - Manuel:

L'évasion et de l'injection SQL

Variables liées à la sera remplacé automatiquement par le serveur. L'
serveur insère leurs échappé à des valeurs, à des endroits appropriés dans les
modèle de déclaration avant l'exécution. Un indicateur doit être fourni à la
serveur pour le type de variable liée, pour créer une
la conversion. Voir la mysqli_stmt_bind_param() la fonction pour plus d'
de l'information.

Automatique s'échapper de valeurs au sein du serveur est parfois
considéré comme un élément de sécurité afin de prévenir l'injection SQL. Le même
degré de sécurité peut être réalisé avec des non-déclarations préparées à l'avance si
les valeurs d'entrée sont échappés correctement.

Update3:

J'ai créé des cas de test pour savoir comment PDO et MySQLi envoyer la requête au serveur MySQL lors de l'utilisation de l'instruction préparée:

PDO:

$user = "''1''"; //Malicious keyword
$sql = 'SELECT * FROM awa_user WHERE userame =:username';
$sth = $dbh->prepare($sql, array(PDO::ATTR_CURSOR => PDO::CURSOR_FWDONLY));
$sth->execute(array(':username' => $user));

Journal De La Requête:

    189 Query SELECT * FROM awa_user WHERE userame ='\'\'1\'\''
    189 Quit

MySQLi:

$stmt = $mysqli->prepare("SELECT * FROM awa_user WHERE username =?")) {
$stmt->bind_param("s", $user);
$user = "''1''";
$stmt->execute();

Journal De La Requête:

    188 Prepare   SELECT * FROM awa_user WHERE username =?
    188 Execute   SELECT * FROM awa_user WHERE username ='\'\'1\'\''
    188 Quit

Il est clair qu'une instruction préparée est également échapper aux données, rien d'autre.

Comme mentionné dans la déclaration ci-dessus The automatic escaping of values within the server is sometimes considered a security feature to prevent SQL injection. The same degree of security can be achieved with non-prepared statements, if input values are escaped correctly, donc, cela prouve que la validation des données telles que intval() est une bonne idée pour les valeurs entières avant d'envoyer une requête, en outre, de prévenir l'utilisateur malveillant de données avant l'envoi de la requête est correct et valide l'approche.

Reportez-vous à cette question pour plus de détails: AOP envoie raw requête à MySQL alors que Mysqli envoie requête préparée, à la fois de produire le même résultat

Références:

1. SQL Injection Feuille de Triche
2. L'Injection SQL
3. La sécurité de l'Information
4. Les Principes De La Sécurité
5. La validation des données

* * * * Avertissement: l'approche décrite dans cette réponse s'applique uniquement aux scénarios très précis, et n'est pas sécurisé car les attaques par injection SQL ne reposent pas seulement sur le fait d'être en mesure d'injecter X=Y.**

Si les attaquants tentent de pirater le formulaire via PHP $_GET variable ou avec l'adresse URL de la chaîne de requête, vous serez en mesure de les rattraper si ils ne sont pas sécurisés.

RewriteCond %{QUERY_STRING} ([0-9]+)=([0-9]+)
RewriteRule ^(.*) ^/track.php

Parce que 1=1, 2=2, 1=2, 2=1, 1+1=2, etc... sont les questions les plus courantes à une base de données SQL d'un attaquant. Peut-être aussi qu'il est utilisé par beaucoup de piratage des applications.

Mais vous devez être prudent que vous ne devez pas réécrire un coffre-fort requête à partir de votre site. Le code ci-dessus vous donne une astuce, à réécrire ou de redirection (cela dépend de vous) que le piratage spécifique à la dynamique de la chaîne de requête dans une page qui va stocker l'attaquant Adresse IP, ou MÊME les COOKIES, l'historique du navigateur, ou toute autre information sensible, de sorte que vous pouvez traiter avec eux plus tard par l'interdiction de leur compte ou de contact avec les autorités.

Une bonne idée est d'utiliser un 'object-relational mapper' comme Idiorm:

$user = ORM::for_table('user')
->where_equal('username', 'j4mie')
->find_one();

$user->first_name = 'Jamie';
$user->save();

$tweets = ORM::for_table('tweet')
    ->select('tweet.*')
    ->join('user', array(
        'user.id', '=', 'tweet.user_id'
    ))
    ->where_equal('user.username', 'j4mie')
    ->find_many();

foreach ($tweets as $tweet) {
    echo $tweet->text;
}

Il n'économise pas seulement à partir des injections SQL, mais à partir des erreurs de syntaxe trop! Prend également en charge des collections de modèles avec chaînage de méthode à filtre ou d'appliquer des mesures de résultats multiples à la fois et les connexions multiples.

J'ai écrit cette petite fonction il y a plusieurs années:

function sqlvprintf($query, $args)
{
    global $DB_LINK;
    $ctr = 0;
    ensureConnection(); //Connect to database if not connected already.
    $values = array();
    foreach ($args as $value)
    {
        if (is_string($value))
        {
            $value = "'" . mysqli_real_escape_string($DB_LINK, $value) . "'";
        }
        else if (is_null($value))
        {
            $value = 'NULL';
        }
        else if (!is_int($value) && !is_float($value))
        {
            die('Only numeric, string, array and NULL arguments allowed in a query. Argument '.($ctr+1).' is not a basic type, it\'s type is '. gettype($value). '.');
        }
        $values[] = $value;
        $ctr++;
    }
    $query = preg_replace_callback(
        '/{(\\d+)}/', 
        function($match) use ($values)
        {
            if (isset($values[$match[1]]))
            {
                return $values[$match[1]];
            }
            else
            {
                return $match[0];
            }
        },
        $query
    );
    return $query;
}

function runEscapedQuery($preparedQuery /*, ...*/)
{
    $params = array_slice(func_get_args(), 1);
    $results = runQuery(sqlvprintf($preparedQuery, $params)); //Run query and fetch results.   
    return $results;
}

Cela permet l'exécution des instructions dans un one-liner C#-ish Chaîne.Format:

runEscapedQuery("INSERT INTO Whatever (id, foo, bar) VALUES ({0}, {1}, {2})", $numericVar, $stringVar1, $stringVar2);

Il s'échappe en considérant le type de variable. Si vous essayez de paramétrer la table, la colonne des noms, il ne pourrait pas parce qu'elle met chaque chaîne de caractères entre guillemets, qui est une syntaxe non valide.

Mise à JOUR de SÉCURITÉ: La précédente str_replace version autorisée injections en ajoutant {#} jetons dans les données de l'utilisateur. Cette preg_replace_callback version n'a pas de problème si le remplacement contient ces jetons.