Problem mit URL-encode/decode

[rkauskh]

Hi

Ich übergebe den Suchstring

'%11%'

per GET. Nach dem urlencode sieht der betreffende Teil so aus:

%27%2511%25%27

Soweit in Ordnung, nur nach dem decode erkennt er die eingeschlossene 11 nicht als selbständige Zahl, sondern erzeugt das:

'%'

Die Prozentzeichen brauch ich aber als Platzhalter in einem SQL-Select. Wie kann ich dieses "Fehlverhalten" verhindern?

MfG
rk

[Pingu]

Die Prozentzeichen brauch ich aber als Platzhalter in einem SQL-Select. Wie kann ich dieses "Fehlverhalten" verhindern?

Ohne mich jetzt tief mit dem eigentlichen Problem zu beschäftigen (die Prozentzeichen), würde ich die allg. akzeptierten Platzhalter ("*" und "?") verwenden. Diese würde ich dann einfach für SQL übersetzen.

$sql = preg_replace( array( "%", "_", "*", "?" ), array( "\\%", "\\_", "%", "_" ), $query); 

Pingu

[rkauskh]

Hi

Das'ne gut Idee, die gleich mein zweites Problem mit den für Normaluser ungewohnten Platzhaltern mit erschlägt.
Ich teste das mal durch und wenn's klemmt komm ich wieder.

MfG
rk

[sticky bit]

per GET. Nach dem urlencode sieht der betreffende Teil so aus:

%27%2511%25%27

wird dann wohl als 4 Zeichen (%27, %2511, %25 und %27) interpretiert. Wie ist URL-Encode da definiert, soll da auch Unicode o. Ä. gehen oder nur ASCII? Wenn ja, hat man da wohl ein nettes Bsp. wieso sone Mischalphabetverwendung scheisse, pardon, problematisch sind. Wenn nein guck mal in die Buglisten von PHP und bring das, falls noch nicht bekannt, zur Sprache.

Als Workaround, mach einfach nen URL-Encode um alles, also auch die elf (bzw. die zwei Zeichen '1') so dass dann "%27%25%49%49%25%27" rauskommt, dann kann er nicht anders...

P.S.: Wenn du den String den Du aus dem GET bekommt so direkt in deinen SQL Query einbauen willst, dann informier Dich vorsichtshalber mal über SQL-Injections, das was ich hier sehe und schlussfolgere schreit nämlich gerade danach anfällig zu werden...

[rkauskh]

Hi

@sticky bit
Jepp, es ist genau so ein Mischalphabet. Ich dachte eigentlich wenn ich den kompletten String an urlencode übergebe kodiert er alles. Das dem nicht so ist, sieht man ja am Beispiel.
Ja der String sollte direkt in eine SQL-Query. Das das'ne blöde Idee ist hab ich selbst schon bemerkt. Hab testweise einfach mal die URL von Hand geändert. Geht prima. Ok, es wird "nur" der Teil nach der Where-Klausel übergeben. Also in etwa so:
Select * from $table where $suchstring;
Es geht um folgendes (vielleicht hol ich doch etwas weiter aus).
Die ursprüngliche Seite ist eine aus einem SQL-Query erzeugte HTML-Tabelle. Die Anzeige ist auf 15 Datensätze limitiert. An die DB werden 2 Anfragen gestellt. Einmal die Gesamtzahl der gefundenen Datensätze und einmal die 15 nächsten Datensätze ausgehend von einem Offset. Aus der Gesamtanzahl der Datensätze erzeuge ich die Anzahl der Seiten die als Links angezeigt werden. Klickt man nun auf Seite "2" (einfaches href) muß eine erneute Anfrage gestellt werden und dafür brauch ich ja wieder diesen Suchstring. Das href verlinkt auf dieselbe Seite, übergibt aber jetzt per $_Get den Offset von 15 und den Suchstring, damit dieser wieder verfügbar ist. Da Sonder-/Leerzeichen enthalten sind muß ich umkodieren und nach dem Neuaufruf der Seite enodieren, sonst geht die SQL-Query in die Hose.

@Pingu
Hab's probiert, aber ich erhalte dann:
Warning: No ending delimiter '%' found in /srv/.../search.php on line 38

Warning: No ending delimiter '_' found in /srv/.../search.php on line 38

Warning: No ending delimiter '*' found in /srv/.../search.php on line 38

Warning: No ending delimiter '?' found in /srv/.../search.php on line 38

Was heißt das?


Nebenfrage: Ist die erläuterte Vorgehensweise überhaupt sinnvoll oder sollte ich mich sofort davon verabschieden und lieber neu anfangen? Welches Prinzip der Weitergabe/Wiederverwendung des Suchstrings nimmt man hier?

MfG
rk

[Pingu]

Sorry, mein Fehler. Ich habe Dir eine Perl RegEx untergejubelt ohne den Suchstring richtig zu definieren.

Die einfache Variante sollte richtig natürlich so lauten:

 $sql = str_replace( array( "%", "_", "*", "?" ), array( "\\%", "\\_", "%", "_" ), $query); 

oder mit einer Perl RegEx wäre es richtig so:

 $sql = preg_replace( array( "/%/", "/_/", "/*/", "/?/" ), array( "\\%", "\\_", "%", "_" ), $query); 

Übrigens wenn es z. B. MySQL ist und Du mysql_query() verwendest, dann brauchts Du mit SQL-Injection keine Angst haben, da mysql_query() immer nur eine Query verarbeiten kann (alles nach dem Semikolon wird ignoriert). Wie es bei den anderen aussieht weiß ich natürlich nicht.

Pingu

[rkauskh]

Hi

Die DB ist PostgreSQL 7.4.x.
Ich überlege trotzdem ob und wie man das eleganter lösen könnte. Leider muß ich auf Cookies und Javascript verzichten, da beides auf den Clients im Normalfall deaktiviert ist.
Die Perl RegExp hab ich probiert, da meckert er dann was von wegen

Warning: Compilation failed: nothing to repeat at offset 0 in /srv/./search.php on line 46

In Zeile 46 steht eine While-Schleife. Die hat nix zu tun, weil die SQL-Query schon scheitert. Wenn ich mir nach preg_replace den Inhalt der Variablen ansehe, ist der seltsamerweise unverändert. Es stehen die normalen Platzhalter drin, die eigentlich ersetzt sein sollten.

Mit str_replace funktioniert es.

Du brauchst dich nicht entschuldigen. Bin froh das sich jemand die Zeit nimmt meine Anfängerfragen zu beantworten.

MfG
rk

[sticky bit]

Übrigens wenn es z. B. MySQL ist und Du mysql_query() verwendest, dann brauchts Du mit SQL-Injection keine Angst haben, da mysql_query() immer nur eine Query verarbeiten kann (alles nach dem Semikolon wird ignoriert). Wie es bei den anderen aussieht weiß ich natürlich nicht.

Unfug, reicht schon sowas wie SELECT * FROM persoenliche_daten WHERE benutzer = '$benutzer' um wenn $benutzer z. B. ' OR 1 = 1 -- enthält, dem Benutzer Sachen zu zeigen die er nicht sehen können soll, da brauchts keinen zweiten Query.
Es muss nicht immer gleich DROP TABLE xyz sein, Daten ausspioniert zu bekommen ist eh oft unangenehmer für den Geschädigten als diese "nur" zu verlieren, dafür gibts Backups, was aber mal publik ist wieder geheim zu machen geht nicht...

[undefined]

Hi

Ich übergebe den Suchstring

'%11%'

per GET. Nach dem urlencode sieht der betreffende Teil so aus:

%27%2511%25%27

Soweit in Ordnung, nur nach dem decode erkennt er die eingeschlossene 11 nicht als selbständige Zahl, sondern erzeugt das:

'%'

Die Prozentzeichen brauch ich aber als Platzhalter in einem SQL-Select. Wie kann ich dieses "Fehlverhalten" verhindern?

MfG
rk

Du hast ein zeichensatz Problem, das dürfte wohl eher dein Problem Lösen. http://de.php.net/manual/de/function...t-encoding.php
und http://dev.mysql.com/doc/mysql/en/ch...onnection.html