Absicherung auch bei Werten von Auswahlmenüs (select) ?

[hawkmaster]

Hallo zusammen,
ich habe meine PHP Scripte von den "mysql" Funktionen auf PDO umgestellt.
Bisher habe ich noch keine "Prepared Statements" verwendet, möchte dies aber überall machen wo Benutzereingaben möglich sind.
Frage:
Angenommen es gibt ein Auswahlmenü das Telephonnummern enthält:
<select name="sel_phoneno">
<option value="1" >1234</option>
<option value="2" >77664</option>
<option value="3" >58767</option>
<option value="4" >13345</option>
</select>

Ein Anwender wählt eine Nummer daraus aus. Diese wird dann in der Datenbank gespeichert bzw. erneuert.

$phonenumber = $_POST['sel_phoneno'];
$sql = "UPDATE phonedata SET PhoneValue = '$phonenumber' WHERE PhoneID = '{$phoneid}' AND PhoneLabel = 'Phone' ";
$DBO->exec($sql);

Sollte man auch hier in solchen Fällen zwingend immer die variablen Werte mit "quote" oder Prepared Statements absichern?

vielen Dank und viele Grüße
hawk

[EKKi]

Mahlzeit,

Sollte man auch hier in solchen Fällen zwingend immer die variablen Werte mit "quote" oder Prepared Statements absichern?

Ja - "All input is evil!" ... woher willst Du wissen, dass der Benutzer "Dein" Formular verwendet (und nicht vielleicht dessen HTML-Quellcode lokal abgespeichert und manipuliert hat)?

MfG,
EKKi

[hawkmaster]

Hallo zusammen,

vielen Dank für eure Hilfe und Tipps.

Ja - "All input is evil!" ... woher willst Du wissen, dass der Benutzer "Dein" Formular verwendet (und nicht vielleicht dessen HTML-Quellcode lokal abgespeichert und manipuliert hat)?

ja da hast du recht.
Ich kenne mich mit SQL Injection und Manipulationsmöglichkeiten noch zu wenig aus. Ich dachte daher zuerst das mit solch einem Select Menü ja keine Werte verändert werden können.
Bei einem Input Textfeld ist es mir schon klar das man event. "bösen" Code wie 1' or '1' = '1 eingeben kann.

Ok, dann werde ich auf jedenfall immer alle variablen Werte absichern.

vielen Dank und viele Grüße
hawk

[Tom]

Hello,

Ok, dann werde ich auf jedenfall immer alle variablen Werte absichern.

Genauso wichtig ist es, dass Du den User nur Datensätze ändern lässt, die Du ihm vorher auch zu diesem Zwecke angeboten hast. Das geht eben nur über die Session.

Ein harzliches Glückauf

Tom vom Berg

[Tom]

Hello,

Sollte man auch hier in solchen Fällen zwingend immer die variablen Werte mit "quote" oder Prepared Statements absichern?

ich denke mir, dass eine Absicherung von Auswahllisten immer über die Session des Users gehen sollte.
In den Sessiondaten wird dann die Übersetzung von value in ID des Datensatzes betrieben.
Values, die gepostet werden, und nicht in der Session vermerkt sind, werden gleich mit Fehlermeldung quittiert. Es kann sich dabei allerdings auch um einen versehentlichen Doppelpost handeln, also nicht zu dolle schimpfen ;-))

Ein harzliches Glückauf

Tom vom Berg

[dedlfix]

echo $begrüßung;

Angenommen es gibt ein Auswahlmenü das Telephonnummern enthält:
Sollte man auch hier in solchen Fällen zwingend immer die variablen Werte mit "quote" oder Prepared Statements absichern?

Ja, es ist völlig unerheblich, welche Art der Parameterübergabe jemand missbraucht.

Prepared Statements dienen nicht zur Absicherung. Hier tritt nur das Problem der Code-Injection aufgrund ihrer Arbeitsweise gar nicht erst auf. (Zumindest bei echten Prepared Statements. Bei den von PDO im Falle MySQL simulierten Prepared Statements kümmert sich PDO intern um ein ordnungsgemäßes Einfügen in das Statement.)

echo "$verabschiedung $name";

[Tom]

Hello,

ich habe meine PHP Scripte von den "mysql" Funktionen auf PDO umgestellt.

mich würde noch interessieren, mit wievielen unterschiedlichen DBMS deine Scripte zu arbeiten haben, oder warum stellst Du sie um?

Ich kann den vollen Nutzen von PDO noch nicht erkennen, wenn man schlanke Webanwendungen als Ziel hat.

Ein harzliches Glückauf

Tom vom Berg

[dedlfix]

echo $begrüßung;

Ich kann den vollen Nutzen von PDO noch nicht erkennen, wenn man schlanke Webanwendungen als Ziel hat.

Vielleicht zählt nicht nur der volle Nutzen sondern auch schon Teile, die einem das Leben einfacher machen. Siehe http://de.php.net/manual/en/pdo.connections.php Example #2. Mit zwei Zeilen Datenbank-"Krams" ist man schon in der Auswerteschleife (wenn man die Fehlerbehandlung mal nicht mitzählt). Ich finde PDO sehr anwenderfreundlich (obwohl ich es zugunsten von mysqli nicht selbst einsetze).

echo "$verabschiedung $name";

[hawkmaster]

HalloTom,

mich würde noch interessieren, mit wievielen unterschiedlichen DBMS deine Scripte zu arbeiten haben, oder warum stellst Du sie um?
Ich kann den vollen Nutzen von PDO noch nicht erkennen, wenn man schlanke Webanwendungen als Ziel hat.

Momentan ist nur MySQL gefragt. Es gibt jedoch die Idee die Webanwendung auch in Zukunft event. für den MSSQL Server zu nutzen.
Der andere grund für PDO war "Sicherheit" und Prepared Statements.

vielen Dank und viele Grüße
hawk

[Tom]

Hello Hawk,

Momentan ist nur MySQL gefragt. Es gibt jedoch die Idee die Webanwendung auch in Zukunft event. für den MSSQL Server zu nutzen.
Der andere grund für PDO war "Sicherheit" und Prepared Statements.

Wie wird denn dann sowas wie "Limit" übersetzt für den M$SQL-Server?
Ich vermute, dass man ohnehin sehr viel nachbessern muss und es einfacher wäre, diese Schicht (ähnlich  DAL) selber aufzubauen, um die notwendigen Workarounds vorsehen zu können.

Oder kann PDO diese "Übersetzungsprobleme" schon selbstständig behandeln?

Ein harzliches Glückauf

Tom vom Berg

[dedlfix]

echo $begrüßung;

Wie wird denn dann sowas wie "Limit" übersetzt für den M$SQL-Server?
Ich vermute, dass man ohnehin sehr viel nachbessern muss und es einfacher wäre, diese Schicht (ähnlich  DAL) selber aufzubauen, um die notwendigen Workarounds vorsehen zu können.
Oder kann PDO diese "Übersetzungsprobleme" schon selbstständig behandeln?

Natürlich nicht. Es übersetzt nicht. Es ist nur ein Durchreicher. Die Vereinheitlichung bezieht sich nur auf die Bedienung von PDO, nicht auf die damit abgefeuerten SQL-Statements. Für sowas braucht es dann den Data Access Layer, der den Anwender komplett ohne SQL-Handling auskommen lässt.

Es fängt schon damit an, dass das Thema Zeichenkodierung komplett unbeachtet gelassen wurde. Für MySQL beispielsweise muss man sich mit dem bekannten, extra abzufeuernden SET NAMES behelfen. Wie das für andere DBMS zu geschehen hat, entzieht sich meiner Kenntnis. Jedenfalls kommt man hier wohl nicht um eine DBMS-spezifische Erweiterung herum.

echo "$verabschiedung $name";

[hawkmaster]

Hallo dedlfix,

Für sowas braucht es dann den Data Access Layer, der den Anwender komplett ohne SQL-Handling auskommen lässt.

Es fängt schon damit an, dass das Thema Zeichenkodierung komplett unbeachtet gelassen wurde. Für MySQL beispielsweise muss man sich mit dem bekannten, extra abzufeuernden SET NAMES behelfen.

Ich bin von meinem Kenntnisstand noch weit davon entfernt meine Scripte eins zu eins auf ein anderes DBMS (als MySQL) zu portieren. Daher auch nochmals die Nachfrage.

Was ist denn der "Data Access Layer"? bzw. wie setzt man den ein?

Was meinst du mit "Set Names" und extra abfeuern?

vielen Dank und viele Grüße
hawk

[dedlfix]

echo $begrüßung;

Was ist denn der "Data Access Layer"? bzw. wie setzt man den ein?

Das ist eine Schicht, die nach außen hin nur noch die gewünschten Daten zur Verfügung stellt. Sie kümmert sich um das Bedienen der Datenablage, ohne dass die eigentliche Anwendung davon etwas mitbekommt. Mann kann damit beispielsweise das Speichermedium austauschen (beispielsweise von Datenbank zu XML oder Datei oder Webservice oder sonstwas), und die eigentliche Anwendung bleibt unberührt. Sie hat vorher nur eine definierte Datenstruktur bekommen und bekommt sie hinterher auch wieder. Es muss nur der DAL in Richtung des Speichermediums angepasst werden.

Was meinst du mit "Set Names" und extra abfeuern?

Man kann beim PDO-Verbindungsaufbau nicht angeben, welche Kodierung man verwendet, um mit dem DBMS zu kommunizieren. Es gibt auch keine Methode, die das für alle DBMS gleichermaßen kapselt. Also muss man ein exec() oder query() mit SET NAMES ... verwenden, um die gewünschte Kodierung festzulegen.

echo "$verabschiedung $name";

[Teufelchen]

<select name="sel_phoneno">
<option value="1" >1234</option>
<option value="2" >77664</option>
<option value="3" >58767</option>
<option value="4" >13345</option>
</select>

Sollte man auch hier in solchen Fällen zwingend immer die variablen Werte mit "quote" oder Prepared Statements absichern?

Es ist keine Schwierigkeit, die Seite mit deinem Formular lokal zu speichern, mit einem Texteditor obigen Code zu bearbeiten und anschließend mit den bösen Werten an deinen Server zu schicken.
Hättest du noch eine Prüfung der Referer:-Zeile, müsste man sich etwas mehr Mühe geben und eine entsprechende HTTP-POST-Anfrage manuell zusammenbasteln, aber nichtsdestrotrotz ist die Übermittlung von POST-Formulardaten kein Geheimnis, von jedermann nachzulesen und für Technikgewandte auch recht leicht nachzuvollziehen.

Kurz: Ja.

Du bist übrigens nicht der Einzige, der so eine Sicherheitslücke hat. Auch in diesem Forum konnte man bis vor einigen Jahren mit der eingangs genannten Vorgehensweise beliebige Themenbereiche benutzen.