nicht angemeldet
Hi,
das beantwortet eigentlich schon meine Frage:
Gibt es ein Tool, dass "böse" Requests generiert und die auf die Site
abfeuert, oder muss ich mir nur jede Interaktion mit der MySQL-DB im
Einzelnen ansehen.
Deine Antwort ist eindeutig die zweite Alternative. Die Schwierigkeit,
die ich dabei sehe, ist mir vorzustellen, wie der Schadcode aussehen
könnte.
Daher versuche ich mal "genauere Aussagen zu machen":
Die Site wird beim Aufruf dynamisch aus dem im Parameter $site_id
übergebenen Wert aufgebaut. $site_id ist in Jeden Fall ein Integer.
In meiner MySQL-DB/Tabelle 'content_online' ist das Feld 'site_id'
der PrimaryKey. Der aus der Tabelle (Inner Joined mit anderen
Tabellen) zurückgegebene Datensatz enthält z.T. HTML und z.T.
PlainText der auf der Seite (immer von index.php) dann ausgegeben
wird.
Das ist natürlich nicht alles ...
-
Unterseiten können über /index/?site_id=1 oder mit /Request/Uri/
aufgerufen werden. Mod_Rewrite leitet die Anfrage immer nach
/index.php weiter. Ist der Paramter site_id beim Aufruf nicht mit
übergeben worden, wird in einer MySQL-DB/Tabelle 'structure' nach
'/Request/Uri/' gesucht, um die damit verknüpfte site_id zurückzugeben. -
Bestimmten site_ids ein "dynamischer Container" zugeordnet. Das
heisst, dass der Content z.T. aus einem php-include-file kommt.
Wird. die Site bspw. mit site_id=145 aufgerufen, kommt include_145.inc.php
zur Ansicht. Das ist etwas komplexeres HTML und beinhaltet die
Suchmaske zum Einen und verarbeitet den Paramter $search_str nach
Abschicken dieses Formulars zum Anderen. $search_str wid wieder für
ein MySQL-Statement verwendet.
Wenn ich die Archillisferse einer, bzw. in meinem konkreten Fall dieser
Php/MySQL-Site also richtig verstehe, muss ich mir alle die Stellen
ansehen, in denen ich etwas aus $_GET (Kann man eine $_POST-Variable
eigentlich auch mit Schadcode belegen ausser über ein Eingabe-Feld?)
für ein SQL-Statement verwende, um SQL-Injection zu verhindern.
Sehe ich das richtig?
beste gruesse,
heinetz