Alternative à mysql_real_escape_string sans se connecter à DB

Question

Je voudrais avoir une fonction se comportant comme mysql_real_escape_string sans se connecter à la base de données comme parfois je dois faire des essais à sec sans connexion DB. mysql_escape_string est dépréciée et est donc indésirable. Certaines de mes conclusions:

http://www.gamedev.net/community/forums/ topic.asp? topic_id = 448909

http://w3schools.invisionzone.com/index.php?showtopic=20064

Answer 1

Il est impossible d'échapper en toute sécurité une chaîne sans connexion DB. mysql_real_escape_string() et déclarations préparées ont besoin d'une connexion à la base de données afin qu'ils puissent échapper à la chaîne en utilisant le jeu de caractères approprié -. sinon les attaques par injection SQL sont encore possibles en utilisant des caractères multi-octets

Si vous êtes seulement test , vous pouvez aussi bien utiliser mysql_escape_string(), ce n'est pas 100% garanti contre les attaques par injection SQL, mais il est impossible de construire quoi que ce soit plus sûr sans connexion DB.

Answer 2

Eh bien, selon la mysql_real_escape_string de référence de la fonction: « mysql_real_escape_string () appelle la fonction de bibliothèque MySQL mysql_real_escape_string, qui échappe les caractères suivants: \ x00, \ n, \ r, \, », " et \ X1A"

Dans cet esprit, la fonction donnée dans le second lien que vous avez posté devrait faire exactement ce dont vous avez besoin:

function mres($value)
{
    $search = array("\\",  "\x00", "\n",  "\r",  "'",  '"', "\x1a");
    $replace = array("\\\\","\\0","\\n", "\\r", "\'", '\"', "\\Z");

    return str_replace($search, $replace, $value);
}

Answer 3

En opposition directe à mon autre réponse, cette fonction suivante est probablement sûr, même avec des caractères multi-octets.

// replace any non-ascii character with its hex code.
function escape($value) {
    $return = '';
    for($i = 0; $i < strlen($value); ++$i) {
        $char = $value[$i];
        $ord = ord($char);
        if($char !== "'" && $char !== "\"" && $char !== '\\' && $ord >= 32 && $ord <= 126)
            $return .= $char;
        else
            $return .= '\\x' . dechex($ord);
    }
    return $return;
}

J'espère que quelqu'un de plus compétent que moi peut me dire pourquoi le code ci-dessus ne fonctionnera pas ...

Answer 4

De plus amples recherches, j'ai trouvé:

http: //dev.mysql .com / doc / refman / 5.1 / fr / nouvelles-5-1-11.html

Correction de sécurité:

Un trou de sécurité SQL-injection a été trouvé dans le traitement de l'encodage multi-octets. Le bogue a été dans le serveur, l'analyse syntaxique de manière incorrecte la chaîne échappé à la mysql_real_escape_string () fonction C API.

Cette vulnérabilité a été découverte et rapportée par Josh Berkus et Tom Lane dans le cadre de la collaboration de la sécurité inter-projet du consortium OSDB. Pour plus d'informations sur l'injection SQL, s'il vous plaît voir le texte suivant.

Discussion. Une injection SQL trou de sécurité a été trouvé dans le traitement de l'encodage multi-octets. Un trou de sécurité d'injection SQL peut inclure une situation dans laquelle lorsqu'un utilisateur fourni des données à insérer dans une base de données, l'utilisateur peut injecter des instructions SQL dans les données que le serveur exécute. En ce qui concerne cette vulnérabilité, lorsque le caractère Escaping set-pas au courant est utilisé (par exemple, addslashes () en PHP), il est possible de contourner la fuite dans certains jeux de caractères multi-octets (par exemple, SJIS, BIG5 et GBK). En conséquence, une fonction telle que addslashes () ne sont pas en mesure d'empêcher les attaques par injection SQL. Il est impossible de résoudre ce problème sur le côté serveur. La meilleure solution est destinée aux applications d'utiliser le jeu de caractères conscient échappements offert par une fonction telle mysql_real_escape_string ().

Cependant, a été détecté un bug dans la façon dont le serveur MySQL parse la sortie de mysql_real_escape_string (). En conséquence, même si le caractère fonction set-courant mysql_real_escape_string () a été utilisé, l'injection SQL était possible. Ce bug a été corrigé.

Contournements. Si vous ne parvenez pas à mettre à jour MySQL vers une version qui inclut le correctif pour le bogue dans l'analyse syntaxique mysql_real_escape_string (), mais exécutez MySQL 5.0.1 ou plus, vous pouvez utiliser le mode NO_BACKSLASH_ESCAPES SQL comme une solution de contournement. (Ce mode a été introduit en MySQL 5.0.1.) NO_BACKSLASH_ESCAPES permet un mode de compatibilité standard SQL, où la barre oblique inverse est pas considéré comme un caractère spécial. Le résultat sera que les requêtes échouent.

Pour définir ce mode pour la connexion en cours, entrez l'instruction SQL suivante:

SET sql_mode='NO_BACKSLASH_ESCAPES';

Vous pouvez également définir le mode globalement pour tous les clients:

SET GLOBAL sql_mode='NO_BACKSLASH_ESCAPES';

Ce mode SQL peut également être activé automatiquement lorsque le serveur démarre en utilisant l'option de ligne de commande en mode --sql = NO_BACKSLASH_ESCAPES ou en réglant sql-mode = NO_BACKSLASH_ESCAPES dans le fichier d'options du serveur (par exemple, ou my.cnf my.ini, selon votre système). (Bug # 8378, CVE-2006-2753)

Voir aussi Bug # 8303.