Wie am besten fehlerhafte Eingaben in Verbindung mit SQL behandeln?

Dieses Thema im Forum "Web-Programmierung" wurde erstellt von 2nd, 11.09.2006.

  1. 2nd

    2nd Thread Starter MacUser Mitglied

    Beiträge:
    8.902
    Zustimmungen:
    242
    MacUser seit:
    25.07.2004
    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:

    PHP:
    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. ;)
     
  2. 2nd

    2nd Thread Starter MacUser Mitglied

    Beiträge:
    8.902
    Zustimmungen:
    242
    MacUser seit:
    25.07.2004
    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
     
  3. koli.bri

    koli.bri Gast

    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
     
  4. kahler

    kahler MacUser Mitglied

    Beiträge:
    234
    Zustimmungen:
    0
    MacUser seit:
    26.09.2005
    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.
     
  5. 2nd

    2nd Thread Starter MacUser Mitglied

    Beiträge:
    8.902
    Zustimmungen:
    242
    MacUser seit:
    25.07.2004
    Und wenn die Cookies ausgeschaltet sind, funktioniert das trotzdem mit den Sessions? Weil dann muss ich auch keine Variable in der URL übergeben...

    2nd
     
  6. Jakob

    Jakob MacUser Mitglied

    Beiträge:
    1.067
    Zustimmungen:
    21
    MacUser seit:
    05.01.2004
    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:
    PHP:
    $id = (int)$_GET['parameter']
    Aus Strings wird glaube ich 0, aus 220a wird 220.
     
  7. 2nd

    2nd Thread Starter MacUser Mitglied

    Beiträge:
    8.902
    Zustimmungen:
    242
    MacUser seit:
    25.07.2004
    PHP:
    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
     
  8. Jakob

    Jakob MacUser Mitglied

    Beiträge:
    1.067
    Zustimmungen:
    21
    MacUser seit:
    05.01.2004
    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!
     
  9. wegus

    wegus MacUser Mitglied

    Beiträge:
    15.041
    Zustimmungen:
    1.316
    MacUser seit:
    13.09.2004
    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!
     
  10. 2nd

    2nd Thread Starter MacUser Mitglied

    Beiträge:
    8.902
    Zustimmungen:
    242
    MacUser seit:
    25.07.2004
    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
     
Die Seite wird geladen...

Diese Seite empfehlen