Suchscript PHP Datenbank

Hallo,
ich habe hier im Forum ein Tutorial gefunden, wie man eine Datenbank durchsuchen kann. Dieses kam mir nur ein wenig zu kompliziert durch, deshalb wollte ich fragen, ob solch eine Suche auch genauso gut ist:

<?php
$keyword = "Mustermann";
$abfrage = "SELECT * FROM tabelle WHERE a LIKE '$keyword' OR b LIKE '$keyword' OR c LIKE '$keyword'";
$ergebnis = mysql_query($abfrage)  OR DIE (mysql_error());
while($row = mysql_fetch_object($ergebnis))
   {
   echo "$row->id <br>";
   }
?>

Das Keyword kann natürlich auch per Formular übergeben werden. Was sagt ihr dazu?

[nikosch]

auch genauso gut ist

Genauso gut wie was? Das Beispiel, das nur Du kennst? Und nein - sicher ist es das nicht. Z.B. fehlen bei Dir Verbindungsaufbau, Fehlerverfolgung, Injection-Schutz.

Die Antwort ist nein.

[Extremefall]

Wie geht ein Injectionschutz? Hast du nen Link? Fehler habe ich geprüft und Verbindungsaufbau ist im anderen Part des Programmscripts.

[jGeee]

ehm, google.de? - oder sollen wir auch noch für dich googlen?! *g*
in der boardsuche findest hier übrigens auch passende themen, und im WIKI meine ich steht dazu auch was.

btw: hast du nikosch sein post überhaupt richtig gelesen und verstanden?

performancebedingt - je nach größe der tabelle - ist das sowieso nicht der beste weg, immer den LIKE-operator in diesem statement zu benutzen.. (für eine frontend-suche)..

btw2:
http://www.php.de/software-design/70...achigkeit.html

[nikosch]

Fehler habe ich geprüft

DU hast ein OR DIE drin, das gerade mal für den Zeitpunkt der Entwicklung ausreicht.

Das Keyword kann natürlich auch per Formular übergeben werden

Naja, bisher eher nicht.

[ByStones]

DU hast ein OR DIE drin, das gerade mal für den Zeitpunkt der Entwicklung ausreicht.

Was soll man dann machen ? Weil wenn man mal davon ausgeht, dass alle Parameter abgesichert sind, kommt immer ein korektes SQL-Statement zu stande, das (falss der User Schrott eingibt) im schlimmsten Fall ein leeres Ergebnis liefert. Aber dann reagieren ich doch auf das leere Ergebnis, oder soll ich auch auf kaputte SQL-Kommandos reagieren ?
Und wenn ja: Wie ?

[illuminatus]

Was soll man dann machen ? Weil wenn man mal davon ausgeht, dass alle Parameter abgesichert sind, kommt immer ein korektes SQL-Statement zu stande, das (falss der User Schrott eingibt) im schlimmsten Fall ein leeres Ergebnis liefert. Aber dann reagieren ich doch auf das leere Ergebnis, oder soll ich auch auf kaputte SQL-Kommandos reagieren ?
Und wenn ja: Wie ?

edit: mist. hab in deinem Beitrag etwas überlesen und weiß nich, ob ich dir mit diesem Ratschlag helfe... egal, ich lasses mal stehen.
-->
Wenn der User durch seine Eingaben deine SQL-Queries "kaputtmachen" kann, kann er sie auch manipulieren.
Und das ist eine Sicherheitslücke die es zu beheben gilt
Google mal SQL-Injections oder ähnliches, dann verstehst du, was du ändern musst.

[Asipak]

Was soll man dann machen ?

Exceptions!

[Dark Guardian]

Was soll man dann machen ? Weil wenn man mal davon ausgeht, dass alle Parameter abgesichert sind, kommt immer ein korektes SQL-Statement zu stande, das (falss der User Schrott eingibt) im schlimmsten Fall ein leeres Ergebnis liefert. Aber dann reagieren ich doch auf das leere Ergebnis, oder soll ich auch auf kaputte SQL-Kommandos reagieren ?
Und wenn ja: Wie ?

Der Query kann nicht nur fehlschlagen weil er fehlerhaft ist. Der Server kann Abstürzen oder ein Depp hat die Datenbankstruktur modifiziert und es fehlt eine Spalte die der Query aber verlangt, Tabellen wurdne umbenannt etc. pp.

Da kannst du dann noch so perfekte Queries schreiben....

Wenn du z.B. eine Liste von Datensätzen ausgeben willst kannst du einfach auf die Seite schreiben "keine Datensätze gefunden" -> was theoretisch auch nicht stimmt weil es gar nicht geprüft wurde, aber wenn du über eine Session Benutzerdaten aus der DB holen willst, anhand der Session weisst das es dazu Daten geben muss und diese zwingend nötig sind, aber kein DB Result wegen abgekratztem Server bekommst was tust du dann mit deinem "or die"? Im schlimmsten Fall haust du dem Benutzer deiner Anwendung eine SQL Fehlermeldung um die Ohren -> sehr unschön.

[nikosch]

Im schlimmsten Fall haust du dem Benutzer deiner Anwendung eine SQL Fehlermeldung um die Ohren -> sehr unschön.

Oder aber lieferst halbfertiges HTML aus - bei die ist nämlich Schluss mit der Ausgabe.

Eigentlich wurde ja schon alles gesagt: Niemand ist vor Fehlern sicher - nicht vor eigenen, nicht vor Sicherheitslücken, nicht von Problemen der Infrastruktur. Ein „kann eigentlich nicht passieren“ ist schon immer eine halbe Garantie zum Applikationsfehler. Das demonstriert Software wie Windows immer wieder eindrucksvoll mit Fehlermeldungen wie „unerwarteter Ausnahmefehler“ oder „should not happen...“.