ASP-Website attackiert

[MarkX]

Moin,

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.

Zum Glück habe ich das sehr schnell gemerkt und hatte ein relativ aktuelles Backup der Datenbank, was ich dann eingespielen konnte.

Trotzdem stand ich natürlich kurz vorm Herzinfarkt und muß mir nun vorwerfen, mich nicht mit dem Thema SQL-Injection beschäftigt zu haben. Nun meine Fragen zu diesem Thema:

Was kann ich tun um dies in Zukunft zu verhindern?

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?

MfG
MarkX.

[Frank (no reg)]

Hi,

welche Datenbanktechnologie setzt du ein: MySQL, Access, MS SQL?

Grundsätzlich hilft unter ASP, die Abfragen zu parametrisieren. Dazu benötigst du das ADODB.Command Object, nur mit conn.Execute reicht es da nicht mehr.

Aus

sql = "SELECT * FROM tabelle WHERE feld='" & Request.Form("bla") & "'"

sollte dann werden

sql = "SELECT * FROM tabelle WHERE feld=@param1"
cmd = CreateObject("ADODB.Command")
cmd.CommandText = sql
cmd.Parameters.Add "@param1", Request.Form("bla")

oder so ähnlich ... bin jetzt grad noch nicht auf der Höhe meiner geistigen Fähigkeiten.

Keine Ahnung ob ein MySQL ODBC Treiber das ebenfalls unterstützt.

Gruss, Frank

[MarkX]

Moin,

vielen Dank für Deine Antwort.

welche Datenbanktechnologie setzt du ein: MySQL, Access, MS SQL?

MS SQL.

Grundsätzlich hilft unter ASP, die Abfragen zu parametrisieren. Dazu benötigst du das ADODB.Command Object, nur mit conn.Execute reicht es da nicht mehr.

Ok, danke für den Tipp. Hättest Du eventuell ein Quelle parat, wo dieses Verfahren gut dokumentiert ist? Wenn nicht, hab ich ja jetzt schon einmal was, wonach ich suchen kann. Prima!

MfG
MarkX.

[thebach]

Hallo MarkX

Ok, danke für den Tipp. Hättest Du eventuell ein Quelle parat, wo dieses Verfahren gut dokumentiert ist?

Ich verlinke an dieser Stelle einfach mal den Artikel "Gegengifte für SQL Injection" aus http://www.aspheute.com.

thebach

[MarkX]

Hallo thebach

Ich verlinke an dieser Stelle einfach mal den Artikel "Gegengifte für SQL Injection" aus http://www.aspheute.com.

Auf diesen Artikel bin auch gerade gestoßen. Leider wird mir die Funktionsweise parametrisierter Kommandos anhand dieses Beispiels nicht vollkommen klar. Das Beispiel wird mir zu wenig erläutert um es komplett zu verstehen.

MfG
MarkX.

[Yeti]

Hi,

der Vorteil von Parametern (der übrigens nicht auf ASP beschränkt ist ;-) ) liegt darin, dass du keinen String konkatenierst, sondern die Funktion des Datenbankadapters benutzt, "böse" Parameter zu überprüfen. Da werden dann z.B. Hochkommata richtig escapet, damit ein Injection-String wie '; SELECT password FROM user-- abgefangen wird.
Wenn du natürlich Eingabefelder auf der Seite hast, wo der eingegebene String anderen Usern angezeigt wird, musst du selbst darauf achten, dass dort kein böser Code reinkommen kann. Das läuft dann aber nicht mehr unter SQL Injection, denn dann sind die Eingaben ja für SQL gesehen korrekt.

Der Yeti

[Cheatah]

Hi,

Was kann ich tun um dies in Zukunft zu verhindern?

wenn Du einen Wert in einen Kontext bringst, musst Du ihn kontextspezifisch kodieren. Das heißt einerseits, dass SQL-Injection im klassischen Sinne nicht mehr möglich ist, denn aus

SELECT ... FROM ... WHERE foo='bar'; INSERT INTO ...

wird

SELECT ... FROM ... WHERE foo='bar'; INSERT INTO ...' [1]

Andererseits heißt es, dass HTML-Code, der auf "legalem" Weg von außen in Deine Datenbank gelangt, bei einer entsprechenden Ausgabe menschenlesbar auf der Seite steht, anstatt als HTML-Code interpretiert zu werden. Wenn Du dieses Prinzip stetig beachtest, existiert in dieser Hinsicht kein Problem.

Cheatah

[1] Vorausgesetzt, bei Deinem DBMS findet die Maskierung per Backslash statt.

[MarkX]

Moin Cheatah,

wenn Du einen Wert in einen Kontext bringst, musst Du ihn kontextspezifisch kodieren.

Ok, bitte noch einmal langsam. Ich möchte das ganze jetzt mal komplett richtig verstehen. Der Kontext ist das SQL-Statment. Der Wert, den ich in diesen Kontext bringen will, ist in dem von Dir gewählten Beispiel "bar". Also beispielsweise ein String, der aus einem Formular übergeben wird oder aus einem URL-Parameter. Verwende ich nun diesen String in einem SQL-Statement besteht die Gefahr einer SQL-Injection.

Nun müßte ich also alle " und ' in diesem String mit \ maskieren, oder wie?

SELECT ... FROM ... WHERE foo='bar'; INSERT INTO ...' [1]

^
                              Wieso wird an dieser Stelle maskiert?
                              Das ist mir nicht ganz klar.

Andererseits heißt es, dass HTML-Code, der auf "legalem" Weg von außen in Deine Datenbank gelangt, bei einer entsprechenden Ausgabe menschenlesbar auf der Seite steht, anstatt als HTML-Code interpretiert zu werden...

Nun das wäre für mich kein Nachteil. Trotzdem die Frage: wie würde ich erreichen doch wieder interpretierbaren Code zu erhalten, wenn ich es wollte?

MfG
MarkX.

[Vinzenz Mai]

Hallo,

Nun müßte ich also alle " und ' in diesem String mit \ maskieren, oder wie?

nein, denn die Voraussetzung [1] ist nicht erfüllt.

MS SQL-Server maskiert einfache Anführungszeichen durch eine Verdopplung. [2]
Daher nicht:

SELECT ... FROM ... WHERE foo='bar'; INSERT INTO ...' [1]

sondern

SELECT ... FROM ... WHERE foo='bar''; INSERT INTO ...' [1]

Wenn Du statt dynamisch zusammengesetzter SQL-Statements Prepared Statements verwendest, dann erledigt das das DBMS für Dich.

Freundliche Grüße

Vinzenz

[1] Vorausgesetzt, bei Deinem DBMS findet die Maskierung per Backslash statt.

[2] Das ist im Handbuch ganz einfach zu finden.

[MarkX]

Moin,

SELECT ... FROM ... WHERE foo='bar''; INSERT INTO ...' [1]

Wenn Du statt dynamisch zusammengesetzter SQL-Statements Prepared Statements verwendest, dann erledigt das das DBMS für Dich.

Ok. Danke. Eine oberflächeliche Recherche brachte mich nun zu der Erkenntnis, daß "Prepared Statements" und "Parametrisierte Kommandos" auf das gleiche hinausläuft. Ist meine Vermutung korrekt?

MfG
MarkX.

[dedlfix]

echo $begrüßung;

MS SQL-Server maskiert einfache Anführungszeichen durch eine Verdopplung. [2]
Wenn Du statt dynamisch zusammengesetzter SQL-Statements Prepared Statements verwendest, dann erledigt das das DBMS für Dich.

Bei Prepared Statements gibt es nichts, das es zu erledigen gilt. Außerdem ist das DBMS dasjenige, das das "Entledigen" dieser Transportsicherung namens Maskierung tun muss.

Bei Verwendung von Prepared Statements müssen die Daten nicht in einen SQL-Statement-Kontext gebracht werden, also brauchen sie nicht maskiert zu werden. Das Statement inklusive Platzhalter geht zuerst den "Prepare-Weg". Anschließend werden die Daten an das P.S. übergeben und dieses per Execute ausgeführt. Was im DBMS bzw. in dessen API passiert, kann an dieser Stelle unbetrachtet gelassen werden. Davon auszugehen, dass die Daten vom P.S. maskiert würden, ist nicht richtig.

(Dass es Datenbankabstraktionsschichten wie PDO unter PHP gibt, die Prepared Statements mitunter nur simulieren, ist eine ganz andere Geschichte.)

echo "$verabschiedung $name";

[Cheatah]

Hi,

Ok, bitte noch einmal langsam. Ich möchte das ganze jetzt mal komplett richtig verstehen.

gerne.

Der Kontext ist das SQL-Statment. Der Wert, den ich in diesen Kontext bringen will, ist in dem von Dir gewählten Beispiel "bar".

Nein, er lautet "bar'; INSERT INTO ...".[2]

Nun müßte ich also alle " und ' in diesem String mit \ maskieren, oder wie?

Alle Zeichen, die in dem Kontext eine Sonderfunktion besitzen. Dies sind hier mindestens "'" und "". In aller Regel sollte die Schnittstelle, die Du verwendest, eine entsprechende Funktion zur Maskierung bereit stellen; es ist nur selten weise, sie sich selbst herzustellen. Verwende die vorliegende Funktion, dann ist die Maskierung auch so, wie sie sein muss (s. Vinzenz' Posting).

SELECT ... FROM ... WHERE foo='bar'; INSERT INTO ...' [1]
                                      ^
                              Wieso wird an dieser Stelle maskiert?
                              Das ist mir nicht ganz klar.

[2] Jetzt klarer? :-)

Andererseits heißt es, dass HTML-Code, der auf "legalem" Weg von außen in Deine Datenbank gelangt, bei einer entsprechenden Ausgabe menschenlesbar auf der Seite steht, anstatt als HTML-Code interpretiert zu werden...
Nun das wäre für mich kein Nachteil. Trotzdem die Frage: wie würde ich erreichen doch wieder interpretierbaren Code zu erhalten, wenn ich es wollte?

Auf die Maskierung in diesem Fall verzichten - bzw. genauer gesagt den Kontext anders definieren ("HTML-Dokument" anstatt "HTML-Code"), so dass die Maskierung ein anderes Ergebnis liefert (nämlich sind Ausgabe und Eingabe identisch). Allerdings ist das doch ein Nachteil, denn genau hierbei findet die Ausführung des eigentlichen Schadcodes statt.

Cheatah

[MarkX]

Moin nochmal,

Nein, er lautet "bar'; INSERT INTO ...".[2]

Ahhh. Jetzt ja! Alles klar. Jetzt macht das ganze für mich Sinn. Manchmal sieht dann das Offensichtliche einfach nicht.

...  Verwende die vorliegende Funktion, dann ist die Maskierung auch so, wie sie sein muss (s. Vinzenz' Posting).

Danke. Das ist eine ganz entscheidende Information für mich. Dann werde ich also nicht erst anfangen jeden String mit einem Array an Blacklist-Einträgen zu überprüfen sondern mich auf "prepared statements" stürzen um der Lösung meines Problems näher zu kommen.

[2] Jetzt klarer? :-)

Glasklar.

... Allerdings ist das doch ein Nachteil, denn genau hierbei findet die Ausführung des eigentlichen Schadcodes statt.

Ok, ich werde mich jetzt erstmal um Maßnahmen kümmern, die es erschweren Schadcode überhaupt erst einmal einzuschleußen.
Wirklich sicher ist man sicherlich nie, aber ich habe erkannt, daß meine programmtechnische Herangehensweise wohl sehr naiv war, als ich die Seite zum Leben erweckte.
Ich betrachte diesen "Schuß vor den Bug" mal einfach als willkommene Gelegenheit wieder etwas dazu zu lernen. Und was gibt es Spannenderes, als neue Dinge zu lernen? Und wo ist man dafür besser aufgehoben als hier? :-)

Vielen Dank an alle Helfer!

MfG
MarkX.

[Cheatah]

Hi,

in aller Kürze:

Wirklich sicher ist man sicherlich nie,

Korrekt. Sicherheit ist kein Ziel, sondern ein Weg; man muss ihn stets weiter gehen.

aber ich habe erkannt, daß meine programmtechnische Herangehensweise wohl sehr naiv war, als ich die Seite zum Leben erweckte.

Es fehlte (mindestens) ein Grundprinzip, das zu verwenden auch ein wenig Disziplin erfordert.

Ich betrachte diesen "Schuß vor den Bug" mal einfach als willkommene Gelegenheit wieder etwas dazu zu lernen. Und was gibt es Spannenderes, als neue Dinge zu lernen? Und wo ist man dafür besser aufgehoben als hier? :-)

Du sprichst mir aus der Seele :-)

Cheatah

[Odium]

zusätzlich zu den genannten Varianten wollte ich mal fragen wo den der Eintrittsbereich war? Die verbinden sich ja in der Regel nicht direkt mit dem DBMS sondern schieben oft fremde Scripte als typische Get-Parameter in den Seiten in deinen Code.
Es lohnt sch also auch mal die http-Zugriffe des Webservers zu überprüfen ob da was mit '=http' in den LOgs auftaucht.
Gibt reichlich Standardscripte die naiv genug programmiert sind um ne fremde Adresse unterschieben zu lassen und von dieser dann blind zu includen.
Odium

[dedlfix]

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";

[MarkX]

Moin dedlfix,

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.

Aber genau das ist doch passiert. Ich dachte, das hätte ich auch so beschrieben.

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.

Dann habe ich den kompletten Thread bis dato mißverstanden und auch alle, die geantwortet haben, lagen falsch.

Auch gut, wenn du dich dem Thema zuwendest, aber das allein hätte den Angriff nicht verhindert.

Warum nicht?

Jede Art von Kontextwechsel muss beachtet werden...

Das hatte mir Cheatah bereits erfolgreich nahegelegt.

Nicht unbedingt. ... 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.

Richtig. Wenn es aber möglich wäre zu verhindern, daß _unerwünschter_ Code in meine Datenbank gelangt, bräuchte ich mir darüber keine Gedanken zu machen. Ich ging jetzt davon aus, daß das Verwenden von Prepared Statements mich diesem Ziel ein gutes Stück näher bringt.

MfG
MarkX.

[dedlfix]

echo $begrüßung;

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.
Aber genau das ist doch passiert. Ich dachte, das hätte ich auch so beschrieben.

Du hast beschrieben, dass jemand Inhalte in deine Datenbank bringen konnte, die zwar von dir nicht gewünscht waren, aber aus Sicht der Datenbank keine SQL-Injektion darstellt. Diese Daten konnten erst nach ihrem Auslesen, beim Einfügen in einen HTML-Kontext unerwünscht als Code interpretiert werden. So las sich für mich deine Beschreibung.

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.
Dann habe ich den kompletten Thread bis dato mißverstanden und auch alle, die geantwortet haben, lagen falsch.

Naja, sie sind auf das von die erwähnte SQL-Injection angesprungen. Das ist auch ein zu beachtendes Thema, aber eben nicht das einzige.

Auch gut, wenn du dich dem Thema zuwendest, aber das allein hätte den Angriff nicht verhindert.
Warum nicht?

INSERT INTO table (feld) VALUES ('<script type="text/javascript">...</script>')

ist keine SQL-Injection. Das ist ein gültiges SQL-Statement. Selbst wenn du " statt ' zur Stringbegrenzung verwendet hättest, und die " in den Daten ordentlich maskiert hättest (um sie eben gegen das Interpretieren als Sonderzeichen zu sichern), wäre es gelungen, den HTML-Code in deine Datenbank zu schreiben.

INSERT INTO table (feld) VALUES ("<script type=""text/javascript"">...</script>")

Das sind nur ganz normale Daten aus Sicht des DBMS.

Wenn es aber möglich wäre zu verhindern, daß _unerwünschter_ Code in meine Datenbank gelangt, bräuchte ich mir darüber keine Gedanken zu machen. Ich ging jetzt davon aus, daß das Verwenden von Prepared Statements mich diesem Ziel ein gutes Stück näher bringt.

Nein. Aus Sicht des DBMS handelt es sich ja nicht um Code sondern, wie gesagt, nur um Daten. Als Code wird er erst wieder interpretiert, wenn er in den HTML-Kontext gelangt. Dagegen hilft nur die HTML-gerechte Behandlung der Daten, indem man die HTML-eigenen Zeichen beachtet und entsprechend behandelt.

echo "$verabschiedung $name";

[MarkX]

Moin nochmal,

Nein. Aus Sicht des DBMS handelt es sich ja nicht um Code sondern, wie gesagt, nur um Daten. Als Code wird er erst wieder interpretiert, wenn er in den HTML-Kontext gelangt. Dagegen hilft nur die HTML-gerechte Behandlung der Daten, indem man die HTML-eigenen Zeichen beachtet und entsprechend behandelt.

Ich glaube ich verstehe, was Du meinst. Es geht ja letztendlich wahrscheinlich um manipulierte GET- oder POST-Daten. Wenn ich diese also vor der Verarbeitung in einem SQL-Statement so kodiere, daß aus " ein &amp; wird, habe ich kein Problem mehr?

Langsam qualmt mir der Kopf ganz schön. Bitte versuche Dich so einfach wie möglich auszudrücken. :-)

MfG
MarkX.

[Sven Rautenberg]

Moin!

Ich glaube ich verstehe, was Du meinst. Es geht ja letztendlich wahrscheinlich um manipulierte GET- oder POST-Daten. Wenn ich diese also vor der Verarbeitung in einem SQL-Statement so kodiere, daß aus " ein &amp; wird, habe ich kein Problem mehr?

Nein, falsch.

Angenommen, der Benutzer kriegt ein Formular und darf sich z.B. einen Benutzernamen frei ausdenken, um sich anzumelden. Jeder normale Benutzer nennt sich dann

Benutzername

aber ein Angreifer nennt sich

<script src="http://evildomain/evilscript.js"></script>

Solange der Benutzername in das DB-Feld reinpaßt, ist dieser Vorgang komplett in Ordnung. Selbstverständlich mußt du beim Eintragen dafür sorgen, dass auch Benutzernamen wie

bar'; DELETE * FROM tabelle;

nicht "durchkommen", die Gefahr von SQL-Injection ist natürlich abzuwehren (das wurde im Thread ja schon besprochen.

Aber wenn du jetzt auf deiner Homepage ein Skript platziert hast, welches die neuen User des letzten Tages listet, und einfach nur den Usernamen als nackten Text da reinschreibst, entsteht (ich nehme mal die drei von oben):

<p>Neue User heute: Benutzername, <script src="http://evildomain/evilscript.js"></script>, bar'; DELETE * FROM tabelle;</p>

Da bindest du jedem anderen Besucher also ein böses Javascript ein!

Würdest du die Benutzernamen aber als Text verstehen, und den Wechsel von "Text" zu "HTML" berücksichtigen, müßten alle Zeichen, die in HTML Sonderbedeutung haben (<, >, ", &), als Entity geschrieben werden.

Und das Resultat ist dann absolut ungefährlich für die anderen Seitenbesucher

<p>Neue User heute: Benutzername, &lt;script src=&quot;http://evildomain/evilscript.js&quot;&gt;&lt;/script&gt;, bar'; DELETE * FROM tabelle;</p>

Es sieht halt nur "Scheiße" aus, wenn solche Benutzernamen auftreten. Insofern wäre es vermutlich eine gute Idee, die Wahl des Benutzernamens vor der Genehmigung und dem Eintrag in die Datenbank noch auf zusätzliche Mindestanforderungen zu prüfen, wie z.B. Verzicht auf Sonderzeichen und Leerzeichen, oder gar die Eingrenzung auf den Bereich [A-Za-z0-9].

- Sven Rautenberg

[MarkX]

Moin,

Würdest du die Benutzernamen aber als Text verstehen, und den Wechsel von "Text" zu "HTML" berücksichtigen, müßten alle Zeichen, die in HTML Sonderbedeutung haben (<, >, ", &), als Entity geschrieben werden.

Ganz konkret: wie wandle ich Text zu HTML. Wie mache ich es, daß automatisch aus allen & ein &amp; wird?

MfG
MarkX.

[Odium]

Servus,

Ganz konkret: wie wandle ich Text zu HTML. Wie mache ich es, daß automatisch aus allen & ein &amp; wird?

bin mir nicht sicher ob ein DBMS so etwas direkt kann, allseits beliebt ist aber die Scritpsprache zu verwenden die die daten aus dem request entgegennimmt und dann deine db connected.
hier etwas für php:
http://www.php.net/manual/de/function.htmlspecialchars.php
asp/net muss siwas doch auch haben, falls nicht dann kannste ja ne eigene funktion machen die bestimmte zeichen in strings wandelt und das ergebnis zurückgibt, so viel zeichen sind es ja nicht...

andre_h

[MarkX]

Nabend,

asp/net muss siwas doch auch haben, falls nicht dann kannste ja ne eigene funktion machen die bestimmte zeichen in strings wandelt und das ergebnis zurückgibt, so viel zeichen sind es ja nicht...

Stimmt auch wieder. Alles klar! Vielen Dank nochmal für die wertvollen Tipps!
Schönes Wochenende!

MfG
MarkX.

[dedlfix]

echo $begrüßung;

Nein. Aus Sicht des DBMS handelt es sich ja nicht um Code sondern, wie gesagt, nur um Daten. Als Code wird er erst wieder interpretiert, wenn er in den HTML-Kontext gelangt. Dagegen hilft nur die HTML-gerechte Behandlung der Daten, indem man die HTML-eigenen Zeichen beachtet und entsprechend behandelt.
Ich glaube ich verstehe, was Du meinst. Es geht ja letztendlich wahrscheinlich um manipulierte GET- oder POST-Daten. Wenn ich diese also vor der Verarbeitung in einem SQL-Statement so kodiere, daß aus " ein &amp; wird, habe ich kein Problem mehr?

Jein. Es ist kein Problem, Zeichen, die im HTML-Kontext eine besonderen Bedeutung haben, wie beispielsweise <, > oder &, in eine Datenbank zu schreiben. Es ist sogar oftmals besser, die Daten in ihrer Originalform zu speichern, nicht in einer Form, die bereits an irgendein Ausgabemedium angepasst ist. Zum einen kann man dann beispielsweise direkt danach suchen, und Stringlängenfunktionen geben ein "richtigeren" Wert zurück ('A & B' sind 5 Zeichen. HTML-codiert dagegen 9 ('A &amp; B')). Zum anderen hast du es umso schwerer, falls mal ein neues Ausgabemedium hinzukommt, das eine ganz andere Behandlung verlangt. Deswegen solltest du immer erst direkt vor der Ausgabe an ein anderes Medium die auszugebenden Daten für dieses Medium behandeln.

Wenn du nun sowohl SQL-Injection in Richtung Datenbank als auch HTML-Injection in Richtung Browser verhinderst, bist du auf der sicheren Seite. Was du damit nicht verhinderst, ist ein Anzeigen dieser ungewünschten Eingabe, die zwar blöd aussehen mag, aber unschädlich ist. Wenn jemand "Schei...benkleister" schreibt, du aber keine solchen Ausdrücke magst, ist das im Prinzip das gleiche Problem. Es ist das ärgerlich, aber sicherheitstechnisch unbedenklich. Es reicht in beiden Fällen, den betroffenen Datensatzu zu löschen.

Unabhängig von den genannten Sicherungsmaßnahmen, die auf jeden Fall anzuwenden sind, kann man als Vorbeugemaßnahme gegen unerwünschten Inhalt eine Prüfung der Daten beim Entgegennehmen hinzufügen, z.B. gegen eine Blacklist.

echo "$verabschiedung $name";

[Odium]

Servus,

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.

exakt. Ich wollte nur noch mal mein Posting in Erinnerung bringen. Ich habe die Erfahrung gemacht das derartige Angriffe selten von Hand stattfinden auch wenn man dies in deinem Fall vielleicht nicht ausschließen kann. Oft laufen automatisíerte Suchen nach bekannten Schwachstellen die dann auch automatisiert genutzt werden. Daher mein Tipp nochmal das du deinen eigenen Code oder den einer bekannten Standardsoftware nach einer Möglichkeit des Codeeinschleusen untersuchst. Das SQL absichern ist auch sinnvoll allerdings sollte die Tür für einfaches XSS dann schon geschlossen sein.

Odium

[MarkX]

Moin Odium,

exakt. Ich wollte nur noch mal mein Posting in Erinnerung bringen. Ich habe die Erfahrung gemacht das derartige Angriffe selten von Hand stattfinden auch wenn man dies in deinem Fall vielleicht nicht ausschließen kann. Oft laufen automatisíerte Suchen nach bekannten Schwachstellen die dann auch automatisiert genutzt werden. Daher mein Tipp nochmal das du deinen eigenen Code oder den einer bekannten Standardsoftware nach einer Möglichkeit des Codeeinschleusen untersuchst. Das SQL absichern ist auch sinnvoll allerdings sollte die Tür für einfaches XSS dann schon geschlossen sein.

ich habe Dein Posting nicht übersehen. Danke nochmal für Deine Hilfe. Du hast auch vollkommen recht. Es war ein automatisierter Angriff. Das hat meine Recherche im Netz nach dem eingeschleusten Code ergeben. Eine Quelle behauptet, daß von diesem Angriff bereits 1,5 Mio. Seiten betroffen sind.

Dein Tipp, mir die Logfiles anzusehen, hat leider nichts Erhellendes zu Tage gefördert. Ich stimme Dir auf jeden Fall zu, daß ich meinen Code nach Schwachstellen untersuchen muß, sowohl was die Behandlung von SQL-Operationen betrifft als auch Lücken, die ein einschleußen von HTML-Code ermöglichen.
Ich weiß leider nicht an welcher Stelle ich ansetzen muß. Das kann mir auch leider keiner abnehmen. Meinen Code kenne ja nur ich selbst.

Ich wünschte langsam, ich hätte Standardsoftware wie Typo3 oder ähnliches eingesetzt, statt die Seite komplett selbst zu entwickeln. Aber es ging ja doch einige Jahre gut...

MfG
MarkX.