Alternative à mysql_real_escape_string sans connexion à la DB

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

  • ca2.php.net/manual/en/function.addslashes.php
  • +1 je suis en train d'écrire MySQL classe moi-même et d'utiliser mysql_real_escape_string() pour le paramètre de liaison but. - Je éviter d'utiliser mysqli que pas tous d'hébergement de la soutenir. J'ai aussi d'éviter les multi-fichier & multi-bibliothèque de classe. Ce dont j'ai besoin est juste un pur & clean Classe unique. Merci!!!!
  • +1 pour moi aussi. Mon cas d'utilisation est une SugarCRM APi où j'ai besoin de pousser des fragments de SQL à la distance SugarCRM exemple par le biais de l'API. Méchant mais c'est, c'est ce que j'ai à travailler avec (aller frapper certains SugarCRM dev têtes ensemble). J'ai besoin d'échapper les chaînes dans SQL dans l'application qui utilise l'API et qui est totalement distincte de la base de données derrière la SugarCRM instance.
InformationsquelleAutor Viet | 2009-07-22
  1. 72

    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 êtes seulement 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.

    • +1 Merci pour la note. Je ne suis pas très sûr de la façon de tester contre les attaques par injection SQL à l'aide de caractères multi-octets.
    • J'ai reçu quelques vieux code pour mettre à jour. Il utilise mysql_escape_string sans connexion (encore à essayer de comprendre pourquoi). Depuis que la fonction est obsolète, je me demande comment je peux le remplacer. Il semble raisonnable que l'on peut spécifier le jeu de caractères" quelle que soit la fonction remplace sans ouverture de la connexion.
    • il est "correct", pour autant que le PHP ne pourrait jamais être appelé comme ça. 🙂 Sur le $paramètre de connexion: "en Option. Spécifie la connexion MySQL. Si non spécifié, la dernière connexion ouverte par mysql_connect() ou mysql_pconnect() est utilisé."
    • désolé mais.. quoi 😉 "impossible de construire quoi que ce soit plus sûr sans une connexion DB"
    • Impossible? Ce n'mysql_real_escape_string obtenir à partir de la connexion de base de données qui n'est pas des données de configuration qui peut être transmise à la main pour une fonction équivalente? Edit: viens de lire ci-dessous, il appelle une fonction de la bibliothèque au sein de MySQL, il y a donc de la transformation qui se passe en dehors de PHP. Il peut encore être portable, mais le garder à jour serait un projet en soi.
    • Que faire si la DB jeu de caractères est connu à l'avance?
    • Ouais si vous connaissez le jeu de caractères, ce qui empêche de faire le sortir sans une connexion?
    • Je sais que c'est une vieille question, mais nous avions encore une ancienne version de php [5.3.3 je crois] et il ne semblait pas besoin d'une connexion à MySQL pour exécuter mysql_real_escape_string(). Non, nous n'avons pas les identifiants mysql dans le fichier ini. Cependant 5.5.36 semblait avoir besoin d'une connexion..Avez quelque chose à changer?? Jusqu'à présent, je n'ai pas trouvé de documentation pour le changement.
    • Je suis également désolé pour le necropost.Ce sujet de php 7+? Il n'y a pas de mysql_escape_string
    • qu'est-ce que suppléant mysql_real_escape_string en PHP 7x ?
    • > Il est impossible de sortir en toute sécurité d'une chaîne sans une connexion DB...en utilisant le jeu de caractères approprié Cette affirmation est incorrecte. Si vous avez le contrôle de vos bases de données et serveurs, alors que vous venez de définir et à utiliser le jeu de caractères correct. Ce que tu veux dire, c'est que les gens ont tendance à gâcher ça.
    • la fonction mysql_escape_string a été dépréciée en PHP 4.3.0, et, ainsi que l'ensemble original de l'extension MySQL a été supprimé en PHP 7.0.0. php.net/manual/en/function.mysql-escape-string.php

    InformationsquelleAutor too much php
  2. 62

    Bien, selon les 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("\\\\","\
    function mres($value)
{
$search = array("\\",  "\x00", "\n",  "\r",  "'",  '"', "\x1a");
$replace = array("\\\\","\\0","\\n", "\\r", "\'", '\"', "\\Z");
return str_replace($search, $replace, $value);
}
    "    ,"\\n", "\\r", "\'", '\"', "\\Z");

    return str_replace($search, $replace, $value);
}
    • Merci. Je vous suggère quelque chose d'autre: la fonction escape($aQuery) { return strtr($aQuery, array( "\x00" => '\x00', "\n" => '\n', "\r" => '\r', '\\' => '\\\\', "'" => "\'", '"' => '\"', "\x1a" => '\x1a' )); }
    • pourquoi \x1a remplacé par \\\x1a plutôt que \\x1a? Est-ce une faute de frappe?
    • -1 C'est très dangereux. Si la connexion de base de données à l'aide d'un jeu de caractères multioctets, simple bytewise remplacements comme cela pourrait entraîner la corruption des données (y compris de s'échapper/guillemets)--cela peut être délibérément exploité par un utilisateur malveillant d'injecter des requêtes SQL.
    • Si vous obtenez le jeux de caractères tromper sur ce point il peut être dangereux. Pour les jeux de caractères multioctets, si mysql est l'aide que quelqu'un peux il suffit de mettre dans un octet pour annuler l' \\. Multiebyte charactersets peut souvent prendre n'importe quoi comme le deuxième octet, y compris \\ pour mysql habitude de le voir comme un standalone \\ mais une partie de la jeux de caractères multioctets. Je n'ai aucune idée de ce qui se passe avec l'UTF8. J'espère qu'avec [0xB0, '\\'] que sur la frappe d'un octet non valide \\ c'est tout juste s'arrête et recommence avec cet octet plutôt que de l'avaler.
    • Si je sais que le jeu de caractères est utf8, il est sûr à utiliser mb_strpos() (et mb_substr() pour créer un comportement analogue à substr_replace()) pour ce faire?
    • Notez que mb_substr() est plus lent qu'un pur-PHP de mise en œuvre de il pour de l'UTF-8 en particulier.

    InformationsquelleAutor zombat
  3. 25

    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 ...

    • +1 Merci pour l'effort supplémentaire. Je vais autour de pour en savoir plus à propos de multi-octets liés à des injections SQL.
    • Je suppose qu'il doit être $retour .= '\x' . dechex($ord); à la place
    • En règle générale, je préfère utiliser '\\', même dans une seule cité de cordes, tout simplement parce que un seul " \ " peut affecter le caractère suivant si vous n'êtes pas prudent. Je suis probablement juste être de nouveau le trouble obsessionnel-compulsif.
    • Cette fonction ne fait pas suivre mysql échapper à des règles et entraîne la perte de l'intégrité des données. "MySQL reconnaît les séquences d'échappement indiqué dans le Tableau 9.1, “Caractère Spécial des Séquences d'Échappement”. Pour toutes les autres séquences d'échappement, barre oblique inverse est ignoré. C'est le caractère d'échappement est interprétée comme si elle n'était pas échappé. Par exemple, “\x” est tout simplement “x”." - dev.mysql.com/doc/refman/5.6/en/...
    • Ne \xAA signifient réellement quelque chose de plus que le texte "xAA" dans MySQL est un littéral de chaîne? La documentation semble dire que \x n'a pas de signification particulière, de sorte que le \ sera ignoré. dev.mysql.com/doc/refman/5.0/en/string-literals.html
    • la regex de zombat est de 5-6 tim es plus rapide.

    InformationsquelleAutor too much php
  4. 6

    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 et Tom Lane 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 définir 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.

    InformationsquelleAutor Viet