nicht angemeldet
echo $begrüßung;
gestern wurde unsere ASP Website von einem SQL-Injection-Angriff getroffen.
Dabei wurde ein String in fast sämtliche Felder aller Tabellen eingetragen. Der String beinhaltet ein "<script>"-Bereich, der ein unsichtbares i-frame integriert. Dadurch, daß die meisten Seiten aus dieser Datenbank generiert werden, erschien dann dieser Code auf unseren Seiten.
Das ist aber keine SQL-Injektion sondern eine HTML-Injection. SQL-Injection hat das Ziel, ein SQL-Statement so zu beinflussen, dass es etwas anderes ausführt als von seinem Autor beabsichtigt. Das Eintragen von Daten ist ein ganz normaler und erwünschter Vorgang. Das Prüfen der Daten auf gewünschten Inhalt ist auch nicht Bestand einer SQL-Injection-Absicherung.
Trotzdem stand ich natürlich kurz vorm Herzinfarkt und muß mir nun vorwerfen, mich nicht mit dem Thema SQL-Injection beschäftigt zu haben.
Auch gut, wenn du dich dem Thema zuwendest, aber das allein hätte den Angriff nicht verhindert.
Was kann ich tun um dies in Zukunft zu verhindern?
Jede Art von Kontextwechsel muss beachtet werden. Ein Kontextwechsel liegt immer dann vor, wenn du Daten irgendwohin ausgibst. Dabei musst du stets die Regeln dieses speziellen Ausgabemediums beachten.
Auf http://itshort.twoday.net/ scheint jemand eine Funktion anzubieten, die anhand einer Blacklist nach Strings sucht, die gefährlich sein könnten. Man müßte also alles prüfen bevor man Datenbankoperationen durchführt. Ist das der richtige Ansatz?
Nicht unbedingt. Was ist mit den Dingen, die auf der Blacklist vergessen wurden? Prinzipiell helfen Blacklists gegen ungewünschten Inhalt, solange die Blacklist gepflegt ist. Gegen das unerwünschte Ausführen von Code hilft nur den Kontextwechsel zu beachten, und die Daten so zu behandeln, dass sie nicht Code interpretiert werden können.
echo "$verabschiedung $name";