Problem mit ' und $_POST

[galaxy2]

Hallo,

um nochmal auf mein Problem zurück zu kommen.
mit addslashes funktioniert nicht so ganz. Habe in meine Selectfeldfunktion nun folgende Zeilen ergänzt:

$wert_mit_sonderzeichen = addslashes($wert);
echo "<option value='$wert_mit_sonderzeichen' $selected>$wert</option>"; 

Nun steht aber im $_Post Array immer noch nicht der vollständige Wert, sonder folgendes: 'Hallo ich bin Backslash Backslash
Denke mal der Doppelte Backslash kommt zum einen wegen addslashes und zum anderen wegen magic_qutas_gpc=on. Schaffe es irgendwie nicht den kompletten string zu übergeben.

Dachte immer bei magic_quotas_gpc=on könnte man auf die Funktion addslashes verzichten, da alle Sonderzeichen entwertet werden .

Htmlcode sieht an der Stelle so aus:
<option value='Raymond Groen I\' nt Woud' selected>Raymond Groen I' nt Woud</option>

Kann mir da jemand weiterhelfen

[wahsaga]

Na ja, addslashes ist ja auch Quark in so einem Falle.

htmlspecialchars() wäre vorzuziehen - ggf. mit passendem zweiten Parameter.

[galaxy2]

Habe es nun anders hin bekommen. Habe

echo "<option value='$wert' $selected>$wert</option>"; 

druch

echo "<option value=\"$wert\" $selected>$wert</option>"; 

ersetzt und schon funktioniert es. ohne eine der beiden Funktionen.

Habe dazu mal generelle Fragen.

Datenbank Oracle9iR2

1) Ich lese die Daten aus der Datenbank in meine PHP/HTML Maske ein.
2) Dort werden sie dann auf Abänderung durch den Benutzer geprüft. Dabei wird das $_POST Array der Eingabefelder mit dem Array, welches die Query füllt, verglichen.
3) Gab es Abänderungen werden diese in der Datenbank gespeichert.

Das funktioniert auch so weit. Nur halt nicht mit Sonderzeichen. Angenommen in einem String ist ein ' Zeichen enthalten.
Habe magic_quotes=On stehen.

Beim auslesen aus der db muss ich doch jeden Wert mit addslashes bearbeiten um sie später mit dem $_POSTArray auf abanderungen vergleichen zu können.(Bei magic quotas=on)

Ziel soll es nun sen, das Die Daten ohne den führenden Backslash vor z.B diesem ' Zeichen in die Datenbank geschrieben werden. Jedoch ermöglicht dies wiederum eine sql-Injection. Wie löst man denn dieses Probelm. Hab schon mehrfach darüber gelesen, aber soweit ich das verstanden habe wurd immer mit addslashes in die in die DB geschrieben.
Bitte verbessert mich wenn ich mich irgendwo irre. Diesen Ablauf habe ich noch nicht so ganz mit den Sonderzeichen im Griff

[wahsaga]

Original geschrieben von galaxy2
Wie löst man denn dieses Probelm.

Schalte magic_quotes_gpc ab (oder lasse es abschalten, oder besorg dir einen Script-Schnippsel, der die einkommenden Daten davon befreit) - es ist Murks.

Nur dann, wenn du Daten in irgendeinem Kontext benutzt, der eine spezielle Maskierung von Sonderzeichen erfordert, dann nimmst du eine solche vor. Für die Ausgabe als HTML bspw. htmlspecialchars(), für die Absicherung vor dem Einfügen in SQL-Queries halt mit einer entsprechenden passenden Funktion (ich weiß nicht, ob es da bei Orcale in Kombination mit PHP noch was spezielles gibt, oder ob addslashes reicht).

Hab schon mehrfach darüber gelesen, aber soweit ich das verstanden habe wurd immer mit addslashes in die in die DB geschrieben.

Mach dir vor allem klar, dass diese Maskierung ausschließlich die Schnittstelle betrifft, über die die Daten an die DB übergeben werden.
Diese ist es, die unmaskierte Daten ggf. missverstehen könnte - der DB selber ist es furzegal, was in ihr drinsteht. Und deshalb speichert sie die Daten natürlich auch unmaskiert ab.

[galaxy2]

Jetzt steh ich auf dem Schlauch Also ich versuche das mal an einem Beispiel zu erklären:

Ich habe 2 Tabellen. Die erste heisst t_Freunde unt hat unter anderem den Namen als eine Splate. Nun steht dort ein Eintrag drin: D'allesandro

Die zweite Tabelle heisst Autos und ist die "Haupttabelle". Sie enthält eine Spalte Besitzer. In diese Spalte dürfen nur Personen eingetragen werden, welche in der Tabelle Freunde existieren. Also per Foreign Key abgesichert.

Ich lese nun daten dieser Tabelle Autos in einem PHP/Html Formular aus, ändere z.B das Auto(auch eine Spalte) ab und drücke auf einen Save-Butten. DaDie magic_quotas stehen auf on. Dabei wird nun von dem Formular aus ein update Befehl aufgerufen, welcher die Abànderung speichern soll.

In das Feld Besitzter wird von php aus der Wert aus £_POST['Besitzer'] geschreiben. Dieser Wert sieht nun so aus: D(Backslash)'allesandro.

Dies erzeugt nun eine Fehlermeldung beim update in der DB, denn den Besitzernamen mit dem Backslash gibt es in der Tabelle t_Freunde nicht.

Das ist genau das Problem was ich habe. Schalte ich hingegen magig_quotas aus und verwende auc kleine Funktion wie addslashes, dann ist eine SQL-Injection relativ einfach möglich.

Wie handhabt man den sowas? Das mit der Schnittstelle habe ich gar nicht verstanden. Der insert oder updateBefehl betrifft doch allein die DB.

[sagg]

Du willst bei dem Update sozusagen den Username nochmal mit den Namen in der Benutzertabelle vergleichen, richtig?
Dann nehm doch einfach die ID des Users, anstelle des Namen.

Oder hab ich dich falsch verstanden?

[wahsaga]

Original geschrieben von galaxy2
Jetzt steh ich auf dem Schlauch

Ach, jetzt ...?

DaDie magic_quotas stehen auf on.

Nein, tun sie nicht (mehr) - ich sagte dir ja, weg mit diesem Murks.

In das Feld Besitzter wird von php aus der Wert aus £_POST['Besitzer'] geschreiben. Dieser Wert sieht nun so aus: D(Backslash)'allesandro.

Nein, tut er nicht. Die dämlichen magic_quotes_gpc haben wir schließlich abgestellt.

Schalte ich hingegen magig_quotas aus und verwende auc kleine Funktion wie addslashes, dann ist eine SQL-Injection relativ einfach möglich.

Niemand sagt, dass du die Daten vor dem Aufnehmen in die Query nicht absichern sollst!
(Nur ob addslashes dazu bei Oracle ausreicht, weiß ich wie gesagt nicht.)

Das mit der Schnittstelle habe ich gar nicht verstanden. Der insert oder updateBefehl betrifft doch allein die DB.

*seufz*

Ein SQL-Statement übergibst du der Datenbank worüber? Über eine definierte Schnittstelle.
Nur diese hat die Möglichkeit, in einer Query irgendetwas falsch zu verstehen. Also müssen auch nur für diese die Eingabedaten maskiert werden.

INSERT INTP TABLE xyz (spalte) VALUE 'achtung'hochkomma'

Da im einzufügenden Wert achtung'hochkomma ein ' vorkommt, ist diese SQL-Anweisung natürlich fehlerhaft - die Schnittstelle der DB, der wir diesen String übergeben, kann ihn nicht richtig interpretieren.
Hinter Value steht wie erwartet ein String - aber danach kommt hochkomma', damit weiß sie nichts anzufangen.

INSERT INTP TABLE xyz (spalte) VALUE 'achtung[b]\[/b]'hochkomma'

"OK," sagt jetzt die Schnittstelle, "versteh ich - du möchtest den Text achtung'hochkomma in die Datenbank eingefügt haben.
Das mit dem \ hab ich kapiert, den hast du nur eingesetzt, damit ich dich nicht falsch verstehe - den muss ich entfernen, bevor die Datenbank das einträgt, weil das ja nicht wirklich zu den Daten gehört ...

Hey, Datenbank - nimm doch bitte den Text achtung'hochkomma, und speichere ihn irgendwo ab!"

"OK," sagt die Datenbank, "mach ich" - die beiden verstehen sich auch so, weil sie intern anders miteinander reden.


Jetzt deutlicher, wieso das Problem nur die Schnittstelle betrifft?

[galaxy2]

Jo. Alles klar.

Also meine ganze Fragerei zielt doch nur darauf ab wie ich die Daten korrekt prüfe und sie dann in die DB schreibe. Da helfen mir die letzten 3 Antworten auch nicht. Werde dann wahrscheinlich alle Eingaben mit preg_match prüfen und dort dann nur bestimmte Zeichen erlauben.

Was anderes fällt mir hier auch nicht ein.

Trotzdem Danke für alle Tipps;

Nur noch zu Info: wenn nun die Schnittstelle folgendes bekommt, dann sagt sie nicht "versteh ich", sondern versteh ich nicht.

INSERT INTP TABLE xyz (spalte) VALUE 'achtung\'hochkomma'

sie sagt nämlich immer noch String endet nicht richtig.

Ersetzt man es hingegen durch:

INSERT INTP TABLE xyz (spalte) VALUE 'achtung''hochkomma'

dann sagt sie alles ok und es wird in die db eingetragen