nicht angemeldet
Hi!
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.
Es gibt keinen Request, der eindeutig als böse definiert werden kann. Es kommt immer auf die Umstände der jeweiligen Sicherheitslücke oder einer Kombination aus solchen an, was angestellt werden kann oder was nicht. Auch eine harmlos aussehende Abfrage kann ungewollt sein, weil man über sie sie vielleicht sensible Daten erhält, die man an anderer Stelle ebenfalls harmlos aussehend nutzen kann.
Deine Antwort ist eindeutig die zweite Alternative. Die Schwierigkeit, die ich dabei sehe, ist mir vorzustellen, wie der Schadcode aussehen könnte.
Der Schadcode ist im Prinzip irrelevant. Wichtig ist nur, dass alle als Daten und nicht als Code vorgesehenen Daten solche bleiben. Und das bleiben sie nur, wenn sie bei einem Einfügen in Code entsprechend der Notationsregeln für Stringliterale oder Zahlenliterale - oder was auch immer an dieser Stelle des Codes konkret benötigt wird - notiert werden. Schau mal in den Kontextwechsel-Artikel, Abschnitte 1 bis 4 sollten das Prinzip erläutern.
Die Site wird beim Aufruf dynamisch aus dem im Parameter $site_id übergebenen Wert aufgebaut. $site_id ist in Jeden Fall ein Integer.
Genauer gesagt: soll ein Integer sein. Alle bei einem Web-Request übergebenen Werte sind generell Strings. Integer und andere Typen werden sie nur bei entsprechender Behandlung (Typecast oder Parsen). (Kleine Ausnahme bilden speziell gestaltete Parameternamen, die unter PHP zur Bildung von Arrays führen.)
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 potentiell kritisch. Je nachdem, wie der HTML-Code zusammengestellt wurde, was mit ihm noch geschieht, bevor er zum Browser gelangt und welche Rolle dabei die anderen Daten spielen, muss genau betrachtet werden. Besonders unangenehm wird es, wenn Anwender selbst Code eingeben dürfen, der direkt in die Ausgabe gelangen oder gar von PHP evaluiert werden soll.
- 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.
Sehr allgemein beschrieben, da kann ich erstmal nichts weiter zu dem bereits von mir Gesagten hinzufügen.
- 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.
Hier muss sichergestellt sein, dass nichts anderes als die vorgesehenen Dateien ausgewählt werden können. Eine Prüfung gegen eine Liste mit genau definierten Werten wäre eine typische Lösung.
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.
Klingt nach dem üblichen Kontextwechseln, die einfach nur beachtet werden müssen.
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.
Du musst nicht die Quelle betrachten, du musst immer das Ziel im Auge behalten. Egal wo die Daten herkommen, am Ziel muss alles syntaktisch einwandfrei eingefügt werden. Dazu musst du wissen, welche Zeichen im Ziel eine Sonderbedeutung haben und wie diese notiert werden müssen, damit sie diese Sonderbedeutung nicht haben und nur Datenbestandteil bleiben. Knifflig wird es, wenn mehrere Ziele ineinandergeschachtelt werden, beispielsweise Javascript und HTML.
Diese Zielbetrachtung kann man sich nur dann sparen, wenn die Daten aus verlässlicher Quelle kommen. Da muss aber sichergestellt sein, dass der gesamte Prozess vom Entstehen bis zum Zieleinfügen sicher ist. Das geht effizient und sicher nur bei sehr kurzen Verarbeitungswegen, beispielsweise ein String-Literal im PHP-Code stehend das in eine Ausgabe (SQL, HTML, wasauchimmer) eingefügt werden soll. Da kann man sehen: "Keine Sonderzeichen drin - keine Behandlung notwendig." Als Faustregel: Überall, wo man die einzufügenden Daten nicht direkt sehen kann, muss eine Behandlung erfolgen. Welche konkret nötig ist, ist fallabhängig.
Betrachte auch immer nur das nächstliegende Ziel. Um Ziele, die weiter entfernt liegen, muss sich der Code kümmern, der dort am nächsten dran ist. Sonst verliert sich leicht die Übersicht, was schon behandelt wurde und was nicht.
Lo!