Wie am besten fehlerhafte Eingaben in Verbindung mit SQL behandeln?

[2nd]

Moin,

ich mache mir gerade Gedanken über das Behandeln von manipulierten $_GET-Paramtern per URL. Angenommen ich übergebe in einem Link einen Parameter, der in meiner Datenbank der Schlüssel zum Tupel ist:

if (isset($_GET['parameter'])) $id = $_GET['parameter'];

$selectQuery = "SELECT * FROM table WHERE id = '$id'";

Soweit so gut, der Wert für "parameter" (z. B. 20) wurde vorher von meinem Script erzeugt und ist valide.

Es gibt ja Leute, die finden es toll, die URL-Parameter zu ändern, d. h. irgendjemand ändert z. B. die Zahl in der URL 20 in 220a.

Nun findet mein Query natürlich keine Daten dazu. Ich frage mich, was ich in dem Fall am elegantesten machen kann:

1.) wenn der Datensatz leer ist, auf eine HTML-Fehlerseite umleiten mit validem Link zurück? -> Nachteil: komische HTML Seite

2.) vorher einmal alle gültigen IDs in einen Array (PHP) einlesen und dann mit array_exists vor dem SELECT ... WHERE Query die ID aus der URL überprüfen und wenn nicht vorhanden dann ID automatisch auf den ersten gültigen Eintrag setzen? -> Nachteil: irgendwie Holzhammer oder?

3.) vor dem Datenquery einen COUNT() - Query zu machen und bei 0 Einträgen den ersten gültigen Tupel auslesen? -> Nachteil: 2 Querys hintereinander


Ich hätte es schon gerne, dass ich nicht auf eine Fehlerseite umleiten muss, sondern bei manipulierten $_GET Parametern automatisch den ersten gültigen Eintrag anzeige. Wie kann man das am elegantesten machen? Irgendwie sagt mir ja die 3. Methode am meisten zu! Was meint Ihr?

2nd

P.S.: Ja ich weiss, SELECT * macht man nicht, ist nur ein Bsp.

 

[2nd]

Vergessen, mit Sessions will ich nicht arbeiten: das ist entweder dann ein Cookie oder SessionID in der URL.

Klar könnte man den Übergabeparameter in einer Sessionvariablen fernab vom Nutzer speichern anstatt diesen per URL weiterzugeben, aber ich will keinen der beiden Fälle oben. Und hidden-$_POST Formularfelder sind dasselbe wie $_GET und ausserdem mir persönlich viel zu umständlich.

2nd

 

[koli.bri]

Ich würd, wenn wegen einer Parameter-Veränderrung auf die Startseite hinlenken.

Ist bei einigen Projekten ja möglich, da das Script selbst die Startseite ohne Parameter ist.
Dann müsste man den Inhalt aber nicht mehr von der Existenz der Parameter abhängig machen, sondern von deren Gültigkeit.

Also statt "if(Parameter übergeben)" ein "if(Tupel gelesen)"...
Kommt aber auch auf das Projekt an.
Bei Ebay oer ähnlichem zum Beispiel würde ich eine Fehlereite generieren. Vor allem, wenn man davon ausgehen kann, dass Tupel gelöscht werden.
gruß
Lukas

 

[kahler]

Auch wenn du es nicht hören willst: Nimm Sessions. Das ist die sauberste Lösung. Ich weiß nicht, was du dagegen hast, aber ob ich jetzt eine SessionID oder eine andere Variable in der URL stehen habe macht für mich eigentlich keinen Unterschied...


...und ein Session Cookie wird von allen Browsern anders behandelt als ein normales vom User erzeugtes.

 

[2nd]

Und wenn die Cookies ausgeschaltet sind, funktioniert das trotzdem mit den Sessions? Weil dann muss ich auch keine Variable in der URL übergeben...

2nd

 

[Jakob]

Ja, funktioniert auch ohne Cookies. Es wird dann (Standardeinstellung) eine Session ID per get-Parameter weitergegeben.

Sicherstellen, dass $id ein Integer ist, kannst Du auch so:

$id = (int)$_GET['parameter']

Aus Strings wird glaube ich 0, aus 220a wird 220.

 

[2nd]

is_numeric

funktioniert auch gut Wobei das Abschneiden von Chars von einer Zahl schon elegant ist...

Danke für die Info Jakob!

Dann mach ich das mit den Sessions, mir war nicht ganz klar, dass es mit clientseitigen Einschränkungen (Cookies aus) trotzdem funktioniert.

2nd

 

[Jakob]

is_numeric

funktioniert auch gut

Naja, wenn dann is_int().

is_numeric überprüft nur, dass eine Zahl numerisch ist. Welche Notation ist da egal. Hexadezimal- („2x3F“) sowie Exponentialzahlen („-4.294e2“) gehen da als true durch!

 

[wegus]

Eingabe und Validierung gehören in ein Script! Das ist die Lösung dazu!

Im Grunde macht man das mit einem einfachen Automaten, der zwischen Erstaufruf, Formular ausfüllen, validieren und Aktion ausführen unterscheiden kann.
Zudem sollte man grundsätzlich ALLE User-eingaben auf Typ und Intervall prüfen.
Variablen grundsätzlich per POST übertragen (GET ist eh limitiert)
In kritischen Fällen eine Checksummeüber Teile der Vorgaben berechnen (MD5) und später abgleichen.

In der Summe reicht es meistens aus!

 

[2nd]

Jo, habe die ID-Übergabe jetzt gerade auf eine Session umgestellt und es funktioniert gut

@Wegus: Im GET Array übertrage ich nur Parameter aus Links also z. B. ?module=1&id=4 oder sowas. In meinen Skripten fang ich aber auch alle Zustände ab, die nicht im Gültigkeitsbereich liegen.

Was meinst du mit Intervall?

2nd

 

[wegus]

Intervall:

$kdnr ist eine Zahl, und z.B > 1000000 und < 9999999

oder $PLZ ist ein String aus Ziffern von 00000 bis 99999

oder $Name ist ein String mit mind. 5 Zeichen Länge und max. 50 Zeichen Länge...

?module=1&id=4

Genau das mach ich, soweit möglich, nie! Ich hab hier aber auch ein Intranet mit immer del gleichen 60 Mitarbeitern.
Geb ich denen Parameter in nem link, weiß ich was passiert. Schmiert das Skript dann wegen falschen Vorgaben ab,
hab ich gleichzeitig die Fehlermail auf dem Bildschirm und nen USer am Telefon der mir erklärt ich habe da nen Fehler
gemacht. Daher nehme ich den "Fehlern" ihre Spielzeuge und POSTe lieber

 

[2nd]

Wie postest Du Parameter? Also wie kriegst Du die in den $_POST Array ohne Formular, z. B. in einem Link?

2nd

 

[Jakob]

Ein kleines Formular und ein button statt einem Link. Links mit GET-Variablen können schlimme Folgen haben im Zusammenhang mit solchen „Web-Beschleunigern“, wie Google sie anbietet. Die schauen nämlich hinter die Links und laden schon mal vor. Wenn der Link aber jetzt heißt „?action=delete&id=2“ dann is das schlecht…

Kleine Zwischenfrage, wo wir gerade bei Validierung sind.
Habe ein Array mit integers. Wie prüfe ich am besten, dass dem auch so ist? Habe keine Funktion dafür gefunden. Muss ich durch's gesamte Array iterieren und jeden Eintrag überprüfen und ggf. ändern oder gibt es da was ähnliches wie (int)?

 

[2nd]

Ein kleines Formular und ein button statt einem Link. Links mit GET-Variablen können schlimme Folgen haben im Zusammenhang mit solchen „Web-Beschleunigern“, wie Google sie anbietet. Die schauen nämlich hinter die Links und laden schon mal vor. Wenn der Link aber jetzt heißt „?action=delete&id=2“ dann is das schlecht…

Ich kann doch nicht meine ganze Seite mit Formularbuttons aufbauen? Oder habe ich was falsch verstanden? Wie erstelle ich denn dann ein grafisches Menu? In den Links brauch ich ja die Parameter. Ich lege ein Bild für die Buttons fest?

z. B.:

<input type="image" src="absende.gif" alt="Absenden">

Oder mit <button>...</button>?

Abgefahren,

2nd

 

[wegus]

es gibt auch noch die Möglichkeit einen Link an eine Javascript-Routine zu verweisen, die dann den POST auslöst!

GET meide ich wie der Teufel das Weihwasser

 

[b.legt210]

Sich allein auf POST-Parameter zu verlegen ist aber auch nicht besonders elegant.
Grund: Suchmaschinen können keine Forumlare abschicken. Wären also sämtliche Links mit POST realisiert, würde Google exakt eine Seite finden und Schluß. Will ja auch niemand, oder?

 

[2nd]

Ehrlich gesagt, ist mir das auch zu umständlich mit den POST-Formularen für die Links. Und ich denke, wenn man GET Parameter auf Validität prüft, passiert auch nichts.

Und Javascript: Da bin ich ein Freund des Minimalismus. Warum soll ich solche Sachen reinbauen, die evtl. nicht funktionieren, weil der Client das ausgeschaltet hat?!?

Ich glaube, ich bleibe bei GET...

2nd

 

[moses_78]

es gibt auch noch die Möglichkeit einen Link an eine Javascript-Routine zu verweisen, die dann den POST auslöst!

GET meide ich wie der Teufel das Weihwasser

POST-Requests zu faelschen ist aber auch nicht
viel schwieriger als GET-Requests zu manipulieren,
weswegen es keinerlei Sicherheit bringt, POST zu
verwenden.

 

[Jakob]

Es geht hier schon um Intranet- und Adminbereiche, oder?

Mit den letzten Posts sieht's nämlich eher nach nem Frontend, also für den normalen Endnutzer, aus. Da ist meiner Meinung nach GET der Einfachheit im Vorteil. Da wird ja auch nichts wichtiges (auf Serverseite) veranstaltet. Bei Adminbereichen sieht das wegen der o.g. Gründe ganz anders aus.

 

[wegus]

POST-Requests zu faelschen ist aber auch nicht
viel schwieriger als GET-Requests zu manipulieren,
weswegen es keinerlei Sicherheit bringt, POST zu
verwenden.

stimmt, nur wissen das die meisten Client-Benutzer nicht