Schutz vor Cross-Site-Scripting

[Thema]

Hallo zusammen,

Folgendes Szenario:
Ich habe ein HTML-Formular "Wünsche und Anregungen", mit dem ich Wünsche und Anregungen sammeln und auf meiner Homepage anzeigen möchte.

Problem: in das input-Feld könnte ein böser User natürlich beispielsweise ein böses Java-Script einschleusen, das ich dann in der Datenbank speichere und bei der Anzeige auf meiner Homepage ausführe.

Mein Mittel dagegen:
Ich prüfe die Nutzer-Eingaben vor der Weiterverarbeitung / Speicherung, ob sie eines der folgenden Schlüsselwörter enthalten:

• INSERT
• CREATE
• TRUNCATE
• ALTER TABLE
• DROP TABLE
• SCRIPT
• DELETE

Auf diese Weise versuche ich zu verhinden, dass jemand Skripte oder SQL-Statements einschleusen kann.

Dazu habe ich nun zwei Fragen:

1. Ist dieses Verfahren praktikabel / sicher, oder gibt es andere / bessere Ansätze?

2. Reichen die von mir genanten Schlüsselwörter aus, oder kennt jemand noch andere Schlüsselwörter, die ich in meine Ausschlussliste einfügen sollte?

Vielen Dank vorab für alle Tipps,
Thomas

[Cheatah]

Hi,

Ich prüfe die Nutzer-Eingaben vor der Weiterverarbeitung / Speicherung, ob sie eines der folgenden Schlüsselwörter enthalten:

Blacklists sind ganz, ganz böse. Sie schützen Dich nur (bzw. höchstens) dann, wenn Du *alles* bedacht hast. Und sofern Du nicht zufällig der Spezies "Gott" angehörst, ist dies extrem unwahrscheinlich.

Auf diese Weise versuche ich zu verhinden, dass jemand Skripte oder SQL-Statements einschleusen kann.

Nein. Sorge lieber dafür, dass nichts, was der User eingibt, eine Gefahr darstellt, indem Du jeden Wert, den Du in einen beliebigen Kontext bringst, kontextspezifisch kodierst.

Cheatah

[Thomas]

Hi,

Nein. Sorge lieber dafür, dass nichts, was der User eingibt, eine Gefahr darstellt, indem Du jeden Wert, den Du in einen beliebigen Kontext bringst, kontextspezifisch kodierst.

Das Argument leuchtet mir ein.
Aber wenn ich bei einem Thema wie "Wünsche und Anregungen" einen Freitext zulasse (oder auch in einem Forum, Gästebuch usw.), kann ich da ja schlecht auf diesem Wege Gefahren abfangen.

Gibt es für Freitext andere sinnvolle Methoden?

Viele Grüße,
Thomas

[wahsaga]

hi,

Aber wenn ich bei einem Thema wie "Wünsche und Anregungen" einen Freitext zulasse (oder auch in einem Forum, Gästebuch usw.), kann ich da ja schlecht auf diesem Wege Gefahren abfangen.

Doch - wenn du eventuellen Code nicht so ausgibst, dass er ausführbar ist, sondern dass er als Text betrachtet/angezeigt wird.

gruß,
wahsaga

[Thomas]

Hi,

Doch - wenn du eventuellen Code nicht so ausgibst, dass er ausführbar ist, sondern dass er als Text betrachtet/angezeigt wird.

Ich hoff mal, das ist jetzt keine all zu blöde Frage, aber mit diesem Thema kenne ich mich noch nicht wirklich aus:

Und wie gebe ich den Text so aus, dass er nicht ausführbar ist?

Viele Grüße,
Thomas

[Cheatah]

Hi,

Und wie gebe ich den Text so aus, dass er nicht ausführbar ist?

wenn Du ihn in eine Datenbank ausgibst, also z.B. per UPDATE- oder INSERT INTO-Statement, führe eine SQL-Kodierung durch. Gibst Du ihn in HTML-Code aus, führe eine HTML-Kodierung durch. Gibst Du ihn in ein PDF-Dokument aus, führe eine PDF-Kodierung durch. Gibst Du ihn in ein Husseldiguggeldiwaggel aus, führe eine Husseldiguggeldiwaggel-Kodierung durch.

Cheatah

[Thomas]

Hi,

wenn Du ihn in eine Datenbank ausgibst, also z.B. per UPDATE- oder INSERT INTO-Statement, führe eine SQL-Kodierung durch.

Gibst Du ihn in HTML-Code aus, führe eine HTML-Kodierung durch. Gibst Du ihn in ein PDF-Dokument aus, führe eine PDF-Kodierung durch. Gibst Du ihn in ein Husseldiguggeldiwaggel aus, führe eine Husseldiguggeldiwaggel-Kodierung durch.

OK.

In meinem Fall speichere ich meine Daten in einer MySQL-Datenbank und zeige sie dann über HTML den Client an.

Ich weiß noch immer nicht so ganz, ob ich unter SQL- bzw. HTML-Kodierung das richtige verstehe.

Hab gerade ein bißchen gegoogelt und auch was dazu gefunden:

1. Schritt: SQL absichern
vor dem Ausführen des SQL-Statements mysql_real_escape_string($String) ausführen.

2. Schritt: HTML absichern
vor dem Anzeigen (bzw. evtl. auch schon vor dem Abspeichern in die Datenbank htmlspecialchars($String) ausführen.

War das gemeint?
Habe ich auf diese Weise dann in meinem Fall alle Cross-Site-Scripting-Gefahren gebannt?

Viele Grüße,
Thomas

[Cheatah]

Hi,

Ich weiß noch immer nicht so ganz, ob ich unter SQL- bzw. HTML-Kodierung das richtige verstehe.

[...]

War das gemeint?

ja, ganz genau das.

Habe ich auf diese Weise dann in meinem Fall alle Cross-Site-Scripting-Gefahren gebannt?

Sofern die entsprechenden Funktionen korrekt arbeiten und Du jeweils die für den Kontext richtige Funktion auswählst (und das Verfahren konsequent anwendest): ja.

Cheatah

[Thomas]

Hi,

Habe ich auf diese Weise dann in meinem Fall alle Cross-Site-Scripting-Gefahren gebannt?

Sofern die entsprechenden Funktionen korrekt arbeiten und Du jeweils die für den Kontext richtige Funktion auswählst (und das Verfahren konsequent anwendest): ja.

OK, super. Hat mir sehr geholfen.

Ich habe eine include-Datei "eingabe_check.php", durch die ich jede Usereingabe laufen lasse, bevor ich sie weiterverarbeite bzw. in der datenbank speichere.

Momentan wird in dieser Datei gegen meine Blacklist geprüft.

Wenn ich jetzt also in dieser Datei die Blacklist (bzw. trotzdem drin lassen, um z.B. ordinäre Wörter abzufangen) rausnehme und dann noch die zwei genannten Funktionen anwende sollte meine Seite dann also abgedichtet sein.

Vielen Dank für die Hilfe,
Thomas

[Cheatah]

Hi,

Wenn ich jetzt also in dieser Datei die Blacklist (bzw. trotzdem drin lassen, um z.B. ordinäre Wörter abzufangen) rausnehme und dann noch die zwei genannten Funktionen anwende sollte meine Seite dann also abgedichtet sein.

ja. Tipp: Wenn Du eine Klasse hast, die die Datenbankzugriffe regelt, kannst Du in dieser leicht alle nötigen Kodierungen und Umwandlungen (Datentypen, NULL, ...) durchführen.

Cheatah

[dedlfix]

echo $begrüßung;

2. Schritt: HTML absichern
   vor dem Anzeigen (bzw. evtl. auch schon vor dem Abspeichern in die Datenbank htmlspecialchars($String) ausführen.

In die Datenbank sollten nur Roh-Daten eingetragen werden, da dann auch die String-Funktionen des DBMS richtig arbeiten können. Außerdem ist es schwerer, bereits für Medium X vorbehandelte Daten ins Medium Y auszugeben (falls diese Anforderung später mal auftaucht), denn dabei muss erst die X-Kodierung entfernt werden, was nicht in jedem Fall verlustfrei möglich ist.

echo "$verabschiedung $name";

[Cheatah]

Hi,

vor dem Anzeigen (bzw. evtl. auch schon vor dem Abspeichern in die Datenbank htmlspecialchars($String) ausführen.
In die Datenbank sollten nur Roh-Daten eingetragen werden,

ah, den Teil hatte ich glatt überlesen. Danke für's Aufmerksammachen. Ich ergänze Deine Ausführungen um eine Bemerkung, die an meine Ausführungen in https://forum.selfhtml.org/?t=144849&m=939709 anknüpft:

Eine Datenbank ist _kein_ HTML-Kontext. Beim Abspeichern in eine Datenbank ist eine HTML-Kodierung also nicht kontextspezifisch, sondern rein willkürlich.

Cheatah

[Cheatah]

Hi,

Aber wenn ich bei einem Thema wie "Wünsche und Anregungen" einen Freitext zulasse (oder auch in einem Forum, Gästebuch usw.), kann ich da ja schlecht auf diesem Wege Gefahren abfangen.

doch, ganz exakt das kannst Du damit. Durch eine kontextspezifische Kodierung sorgst Du (u.a.) dafür, dass der Wert in seiner Bedeutung identisch bleibt - also dass ein Text ein Text bleibt und nicht plötzlich zu einem Befehl wird.

Cheatah

[Maxx]

Hallo,

Ich prüfe die Nutzer-Eingaben vor der Weiterverarbeitung / Speicherung, ob sie eines der folgenden Schlüsselwörter enthalten:

• INSERT
• CREATE
• TRUNCATE
• ALTER TABLE
• DROP TABLE
• SCRIPT
• DELETE

wie Cheatah schon sagte: blacklists sind böse. Aber! das heißt nicht, dass du mit einer Whitelist auf der sicheren Seite bist.
Das dachten die Entwickler von mySpace nämlich auch.
Sie ließen nur einige Tags <a>, <img>, und <div> zu.

Ein simples <div style="background:url('javascript:alert(1)')"> war dann der Anfang vom Ende.
Nachzulesen unter http://namb.la/popular/tech.html

Grüße,

Jochen