Probleme mit mysli::real_escape_string in Verbindung mit magic_quotes_gpc

[tim-gt]

Hallo!

Ich verwende in meinem Skript auf dem FrontController ganz zu Beginn folgende Funktion, die mir alle Backslashes entfernt:

  public static function formatMagicQuotesRemove(){
    if(get_magic_quotes_gpc()){
      if(!empty($_GET)){
        $_GET = self::stripArray($_GET);
      }
      if(!empty($_POST)){
        $_POST = self::stripArray($_POST);
      }
      if(!empty($_COOKIE)){
        $_COOKIE = self::stripArray($_COOKIE);
      }
    }
  }
  private static function stripArray($arr){

    foreach($arr as $key=>$value){
      if(is_array($arr[$key])){
        $arr[$key] = self::stripArray($arr[$key]);
      }
      else{
        $arr[$key] = stripslashes($arr[$key]);
      }
    }

    return $arr;

  } 

Wie ihr seht entfernt sie einfach alle Backslashes, wenn magic_quotes_gpc auf on ist. In meiner .ini siehts so aus, aber ich will ja .ini-unabhängig programmieren:

; Magic quotes for incoming GET/POST/Cookie data.
magic_quotes_gpc = On

; Magic quotes for runtime-generated data, e.g. data from SQL, from exec(), etc.
magic_quotes_runtime = Off

; Use Sybase-style magic quotes (escape ' with '' instead of \').
magic_quotes_sybase = Off

Alle SQL-Abfragen werden, bevor sie ausgeführt werden, dann natürlich mit mysqli::real_escape_string escaped. Nun habe ich folgendes Problem:

1. Fall
-------
Verwende ich die oben vorgestellte statische Methode nicht, gibts bei Eingabe von \ und " keinen Error, dafür aber bei ', so wird z.B.

"Daten und deren Darstellung können keine rechtlichen Ansprüche irgendwelch'er Art abgeleitet"

zu dieser SQL-Abfrage:

"Daten und deren Darstellung können keine rechtlichen Ansprüche irgendwelch\\'er Art abgeleitet"

und dies produziert einen Error (1064).. check the... etc.


2. Fall:
-------
Verwende ich oben genannte Methode, führt die Eingabe von " und ' nicht mehr zu einem Error, dafür aber jetzt die Eingabe von \:


'C:\Tomcat\webapps\etc\pub\'

bleibt aber so bei
'C:\Tomcat\webapps\etc\pub\'

Und trotzdem gibts wieder einen 1064-Fehler.

Ich kann mir echt nicht erklären, wieso im 2. Fall noch ein Fehler passiert. Ach ja, die Daten werden vor der Query so behandelt:

$value = '\''.$this->con->real_escape_string($value).'\'' 

PS: Ich muss vielleicht noch anmerken, dass wenn ich ein Formular den String te\st eingebe, funktioniert das, wenn ich aber test\ eingebe, kommt es zu oben beschriebenem Fehler im 2. Fall.

[h3ll]

Zeige den erzeugten Query-String und die exakte und komplette Fehlermeldung von MySQL.

[combie]

Ich sehe das Problem nicht!

Wenn eingeschaltet, dann zu Anfang magic_quotes rekursiv rückgängig machen. Und bei DB Zugriffen alles sauber escapen. Das muß so gehen!

[tim-gt]

Also, in meinem Formular gebe ich folgenden Wert ein:

C:\Tomcat\webapps\etc\pub\

Die Meldung ist die:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''C:\Tomcat\webapps\etc\pub\'' at line 2 (1064)

Querystring:

UPDATE mm_core
              SET WebOfficePub = 'C:\Tomcat\webapps\etc\pub\'

[h3ll]

Also, in meinem Formular gebe ich folgenden Wert ein:

C:\Tomcat\webapps\etc\pub\

Die Meldung ist die:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''C:\Tomcat\webapps\etc\pub\'' at line 2 (1064)

Querystring:

UPDATE mm_core
              SET WebOfficePub = 'C:\Tomcat\webapps\etc\pub\'

Hier wurde kein real_escape_string() ausgeführt. Definitiv nicht. Irgendwie wurde das umgangen. Die PHP-Errors lasst du dir eh anzeigen, oder?

[tim-gt]

Ich sehe das Problem nicht!

Wenn eingeschaltet, dann zu Anfang magic_quotes rekursiv rückgängig machen. Und bei DB Zugriffen alles sauber escapen.

Dann hast du nicht alles gelesen, oder ich bin zu dumm. Gerade das macht ja meine Mehode, die magic_quotes rekursiv rückgängig machen. Und die DB-Zugriffe escape ich ja "sauber" mit mysqli::real_escape_string

Gehts noch sauberer?

[combie]

Ich kann dieses nur bestätigen:

Hier wurde kein real_escape_string() ausgeführt. Definitiv nicht.

Entweder zeigst du den falschen PHP Ausschnitt, oder deine escape Methode ist kaputt.

[tim-gt]

Hier wurde kein real_escape_string() ausgeführt. Definitiv nicht. Irgendwie wurde das umgangen. Die PHP-Errors lasst du dir eh anzeigen, oder?

Wenn ich bei der Eingabe bei


C:\Tomcat\webapps\etc\pub\ den letzten Backslash wegnehme, funktioniert es, nur wird es dann zu

C:Tomcatwebappsetcpub

[wahsaga]

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''C:\Tomcat\webapps\etc\pub\'' at line 2 (1064)

Querystring:

UPDATE mm_core
              SET WebOfficePub = 'C:\Tomcat\webapps\etc\pub\'

Sieht nicht so aus, als ob du wirklich Escaping angewendet hättest ...

[h3ll]

Dann hast du nicht alles gelesen, oder ich bin zu dumm. Gerade das macht ja meine Mehode, die magic_quotes rekursiv rückgängig machen. Und die DB-Zugriffe escape ich ja "sauber" mit mysqli::real_escape_string

Gehts noch sauberer?

Offensichtlich tut dein Programm nicht das, was du denkst.

Kleines Beispiel:

$db = new mysqli('localhost', 'root', '', 'test');

$value= 'C:\\Tomcat\\webapps\\etc\\pub\\';

var_dump($value);
// string(26) "C:\Tomcat\webapps\etc\pub\"

$value = "UPDATE mm_core SET WebOfficePub = '" . $db->real_escape_string($value) . "'";

var_dump($value);
// string(67) "UPDATE mm_core SET WebOfficePub = 'C:\\Tomcat\\webapps\\etc\\pub\\'" 

Geht einwandfrei.

[tim-gt]

Ich kann dieses nur bestätigen:

Die Errors lasse ich mir anzeigen, mit einer selbst geschriebenen Debug-Klasse. Diese übernimmt auch den Querystring, der effektiv zur Abfrage verwendet wurde. Siehe Bild.

[h3ll]

Lass dir den Wert direkt vor und nach real_escape_string() ausgeben. Wenn beide gleich sind, dann funktioniert die real_escape_string() Methode nicht. Ist das übrigens die Original-Methode von PHP oder irgendwas selbst gebasteltes? Und wenn selbst gebastelt, warum nicht das von PHP verwenden, wo man auch sicher weiß, dass es funktioniert?

[tim-gt]

Nein, das ist die Originalmethode, aber ich verwende sie so:

Ich habe folgendes:

$sql = 'SELECT ID, Name
        FROM core_user
        WHERE ID = :0';
    $st = $this->db->prepare($sql);
    $st->execute('5'); 

Die $args in Methode execute($args) werden dann so behandelt:

foreach ($args as $key=>$value){
      $exp = '!:'.$key.'\b!';

      $this->sql = preg_replace($exp,'\''.$this->con->real_escape_string($value).'\'',$this->sql);  
      if(preg_last_error() !== 0){
        throw new ExcDBQuery(NULL, $oldsql, preg_last_error(), 'Querystring konnte nicht ersetzt werden.');
      }
    } 

$this->sql wird dann in der Methode execute() ganz normal mit $mysqli->query($this->sql) ausgeführt.

Was mir einfach nicht einleuchten will, ist, dass wenn ich sdfsdf\asdfsdf übergebe, kein Error kommt, wenn ich aber asdfsf\ übergebe, als den Backslash am Schluss, dann schon. Und dass alle anderen Sonderzeichen '," dennoch funktionieren.

PS: $this->con->real_escape_string ist nichts anderes als $mysqli->real_escape_string

[h3ll]

Lass dir folgendes ausgeben:

var_dump($value);
var_dump($this->con->real_escape_string($value));
var_dump($this->con); 

[tim-gt]

Sorry, ich will jetzt nicht alle meine Methoden erklären. $db->prepare ist nicht das gleiche wie $mysqli->prepare, da $db kein MySQLi-Objekt ist. DB ist eine Wrapperklasse, die mit der Methode prepare über eine andere Methode connect eine Verbindung zur Datenbank herstellt und dann ein DBStmt Objekt erzeugt. Im DBStmt Objekt geschieht dann alles relevante. In Sachen string-Umwandlung ist die Passage, die ich vorhhin hingeschrieben habe, die einzige, die irgend etwas relevantes tut. Ausser es gäbe sonst noch eine mysqli-Methode, die automatisch Strings escapen würde.

Und ich arbeite nicht mit Prepared Statements, sonst müsste ich ja die :0 und so weiter nicht direkt ersetzen, was mir übrigens lieber ist. Wahrscheinlich wärs mit PS sogar leichter, aber um das geht es ja jetzt nicht.