Alternative à mysql_real_escape_string sans connexion à la DB

Question

J'aimerais avoir une fonction se comporte comme mysql_real_escape_string sans connexion à la base de données au temps dont j'ai besoin pour faire des essais de séchage sans connexion DB. mysql_escape_string est obsolète et, par conséquent, n'est pas souhaitable. Certains de mes résultats:

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

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

Answer 1

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

Si vous ne sont que des tests, alors vous pourriez aussi bien utiliser mysql_escape_string(), il n'est pas garanti à 100% contre les attaques par injection SQL, mais il est impossible de construire quoi que ce soit plus sûr sans une connexion DB.

Answer 2

Eh bien, selon le mysql_real_escape_string fonction de la page de référence: "mysql_real_escape_string() appelle MySQL bibliothèque de la fonction mysql_real_escape_string, qui s'échappe les caractères suivants: \x00, \n, \r, \, ', " et \x1a."

Avec cela à l'esprit, alors la fonction donnée dans le deuxième 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 plus 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 fonctionne pas ...

Answer 4

De plus amples recherches, j'ai trouvé:

http://dev.mysql.com/doc/refman/5.1/en/news-5-1-11.html

Correctif De Sécurité:

Une injection SQL trou de sécurité a été trouvée dans l'encodage multi-octet de traitement. Le bug a été dans le serveur, de façon incorrecte, l'analyse de la chaîne s'est échappé avec le mysql_real_escape_string() de l'API C de la fonction.

Cette vulnérabilité a été découvert et signalé par Josh Berkus josh@postgresql.org et Tom Lane tgl@sss.pgh.pa.us dans le cadre de l'inter-projet de collaboration en matière de sécurité de l'OSDB consortium. Pour plus d'informations sur SQL injection, veuillez consulter le texte suivant.

Discussion. Une injection SQL trou de sécurité a été trouvée dans l'encodage multi-octet de traitement. Une injection SQL trou de sécurité peuvent comprendre une situation dans laquelle, lorsqu'un utilisateur a fourni des données à insérer dans une base de données, l'utilisateur peut injecter du SQL dans les données que le serveur va exécuter. En ce qui concerne cette vulnérabilité, lorsque le jeu de caractères n'est pas au courant échappement est utilisé (par exemple, addslashes() en PHP), il est possible de contourner le s'échapper dans certains multi-byte character sets (par exemple, SJIS, BIG5 et GBK). En conséquence, une fonction telle que addslashes() n'est 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 pour les applications à utiliser jeu de caractères conscient de s'échapper offert par une fonction mysql_real_escape_string().

Cependant, un bug a été détecté dans la façon dont le serveur MySQL analyse de la sortie de mysql_real_escape_string(). En conséquence, même lorsque le jeu de caractères-connaissance de la fonction mysql_real_escape_string() a été utilisé, SQL injection a été possible. Ce bogue a été corrigé.

Solutions de contournement. Si vous êtes incapable de mise à niveau de MySQL pour une version qui inclut le correctif pour le bug de mysql_real_escape_string() de l'analyse, mais de l'exécuter MySQL 5.0.1 ou version ultérieure, vous pouvez utiliser le NO_BACKSLASH_ESCAPES mode SQL comme une solution de contournement. (Ce mode a été introduit dans MySQL 5.0.1.) NO_BACKSLASH_ESCAPES permet une compatibilité avec la norme SQL-mode, où les anti-slash n'est pas considéré comme un caractère spécial. Le résultat sera que les requêtes échouent.

Pour choisir ce mode pour la connexion en cours, tapez l'instruction SQL suivante:

SET sql_mode='NO_BACKSLASH_ESCAPES';

Vous pouvez également définir le mode à l'échelle mondiale 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 --sql-mode=NO_BACKSLASH_ESCAPES ou par la mise en sql-mode=NO_BACKSLASH_ESCAPES dans l'option de serveur de fichier (par exemple, mon.cnf ou my.ini, selon votre système). (Bug#8378, CVE-2006-2753)

Voir aussi le Bug n ° 8303.