XSS Hack bei Galaxy-News

Die schöne neue Welt des Web2.0!
Ich bin ja selbst ein begeisterter Fan von all den neuen (bzw. alten) Möglichkeiten, die damit endlich umgesetzt werden können.
Interaktivität ohne Neuladen der Seite, ist schön was schönes.
Allerdings birgt dies auch neue Gefahren. Cross-Site-Scripting Hacks ... ich liebe dieses Wort und deshalb nur kurz XSS.
Damit ermöglicht man nämlich nicht nur den Benutzer einen leichteren Einstieg in eine Webseite, nein, auch die Bösen haben es wieder richtig leicht.
Ein schönes Beispiel um dies zu verdeutlichen ist der sog. Samy-Wurm der 2005 auf myspace.com im Umlauf war. Nachdem ich - wie alle bösen Jungs - einmal Zeit hatte wollte ich mal sehen, wie sich dies auf Browserspielseiten auswirken könnten.
Und siehe da: Ganz einfach.
Um zu erklären wie so etwas funktioniert möchte ich dies an einem Live-Beispiel hier auf der Galaxy-News einmal verdeutlichen.
[EDIT sagt: Bitte nciht. Danke.]
Ich würde mich aber vielmehr um Feedback freuen, ob und wie Ihr Euch bei der Entwicklung von Spielen vor XSS schützt und ob es da bereits irgendwelche (negativen) Ehrfahrungen bei Euch gab.

Wunderbar, funktioniert. Das Problem ist aber vielmehr, das hier eine Benutzereingabe nicht gefiltert wurde! @neit

Teilweise korrekt. SQL-Injections wären hier wohl nicht soeinfach geschehen, da zumindest nach Kommas geprüft wird. Allerdings Gegenfrage wonach sollte den dann noch geprüft werden.
Zumindest nach einem Script-Tag. Aber sobald das geschieht maskiere ich eben das Tag... und dann?
Wie unterscheidet man zwischen einer guten Benutzereingabe und einem bösen Code?

Alle Eingaben werden einfach nicht interpretiert. Damit hat der Schreiber auch die Gelegenheit, HTML-Code zu schreiben. Also, wenn er den Code, nicht das Resultat, zeigen will. Das wird hier aber definitiv nicht gemacht.

Ich hab mal editiert, bevor jemand Schindluder damit treibt. Ich bitte um Verständnis.

Grr....
Naja, aber immerhin sei der Hinweis erlaubt, dass es - auch auf den Seiten der GN - möglich ist, XSS zu betreiben, mit den Auswirkungen, dass eben Daten ohne zutun oder wissen des Benutzers ausgelesen und manipuliert werden können.
Soviel sollte man schon sagen dürfen.
Im übrigen freue ich mich jetzt schon über viele neue Freunde :-)

Da ich XSL-Transformationen als Template-Energie verwende, werden alle tags (zb. , usw.) automatisch entfernt, weil ich xsl:value-of verwende.
Ich nutze ausserdem die Filter extension von php 5.2 und habe eine Funktion geschrieben, die strip_tags(ich will das html weg haben und nicht nur escapet sind) auf die strings anwendet. Bei den integern wird entweder FILTER_VALIDATE_INT oder FILTER_SANITIZE_NUMBER_INT verwendet.

Normale Markupelement sind aber unter Umständen ja gewollt, bsp. bei einem Forum. Und bei XSL wäre der BBCode bei der XML-Ausgabe bereits in HTML umgewandelt. Ergo bleibe ich bei meinem Vorposting: Die Eingabe einfach "so-wie-sie-ist" einlesen und speichern. Also, wenn man PHP für XML nimmt: htmlspecialchars().
Wenn jemand den Quelltext seiner Eingabe auch so im Browser sieht, dann weiß er, dass keine Tricks helfen. Wenn aber Teilbereiche einfach unterschlagen (strip_tags) werden, gibt es vielleicht Tricks (je nachdem, wie man den Schutz implementiert hat).
Vielleicht will ich ja in meine Allianzbeschreibung "Die Guten" schreiben, vllt will ich ja ein Tutorial mit einem JS-Beispiel zeigen.. Warum verbieten?

Ja es ist wichtig, dass man auch HTML-Tags schreiben kann, die dann im Klartext angezeigt werden könne.
Aber für eigene Tags würde ich wie beim BBC-Code "[" und "]" nehmen.

Original von kevka
Ja es ist wichtig, dass man auch HTML-Tags schreiben kann, die dann im Klartext angezeigt werden könne.
Aber für eigene Tags würde ich wie beim BBC-Code "[" und "]" nehmen.

Ja klar.. aber ein Browser kann die nicht umwandeln. Ergo müssen der Outputgenerator jene in XML-Tags (genauer XHTML/HTML) umwandeln. Auch bei XSL.

Wenn man schon bestimmte HTML-Tags erlauben will, dann würde es sich anbieten erst alle zu filtern und dann wieder die zulassen, die gewünscht sind. Das verhindert, dass durch Tricks doch einige Tags durch den Filter fallen und ermöglicht eine wesentlich zuverlässigere Kontrolle darüber, welche Tags für Formatierungen erlaubt sind, und welche nicht.

$text = htmlentities($text);
$text = preg_replace("/<(\/?[a-zA-Z]+)
function allowTag($tag)
{
$allow = false;
switch($tag)
{
case 'b': case '/b': case 'i': case '/i': // usw.usf.
$allow = true;
}
return $allow ? "<$tag>" : ">$tag<";
}
So ungefähr ...

Original von knalli
Normale Markupelement sind aber unter Umständen ja gewollt, bsp. bei einem Forum. Und bei XSL wäre der BBCode bei der XML-Ausgabe bereits in HTML umgewandelt. Ergo bleibe ich bei meinem Vorposting: Die Eingabe einfach "so-wie-sie-ist" einlesen und speichern. Also, wenn man PHP für XML nimmt: htmlspecialchars().
Wenn jemand den Quelltext seiner Eingabe auch so im Browser sieht, dann weiß er, dass keine Tricks helfen. Wenn aber Teilbereiche einfach unterschlagen (strip_tags) werden, gibt es vielleicht Tricks (je nachdem, wie man den Schutz implementiert hat).
Vielleicht will ich ja in meine Allianzbeschreibung "Die Guten" schreiben, vllt will ich ja ein Tutorial mit einem JS-Beispiel zeigen.. Warum verbieten?

ok ich werde htmlspecialchars() nutzen.
Folgendes ist mir allerdings aufgefallen:
Wenn ich folgendes ans xsl template gebe

alert("hmm");

wird das und entfernt.
wenn ich allerdings folgendes ans xsl template gebe:

alert("hmm";

wird es genau so ausgegeben. Wenn ich allerdings das disable-output-escaping auf yes stelle, sollte er eigentlich gar nichts ändern(oder? Zitat: "yes" bedeutet, dass spezielle Zeichen, wie ">", nicht umgewandelt werden sollen, aber er ändert es wider in so:

alert("hmm");

ich muss wohl noch ein paar Tests machen.
*Edit* das mit dem disable-output-escaping=yes stimmt wohl so. die < werden in < usw. gewandelt. Ich habe das disable-output-escaping sowieso fast nicht benuzt.

Hm.. naja, ich würde bei einer XML-Ausgabe aber immer unterscheiden: Ist der Inhalt von einer Sache "XML" oder "Daten"? Ersteres dürfte eigene (valide, mindestens wohlgeformt) XML-Tags beinhalten, letzteres wäre maskiert.
Unter Umständen wäre ja auch eine Beschreibung in XML interessant, es würde mehr kreative Möglichkeiten bieten, vor allem im Zusammenspiel eines innovativen XSL. Andererseits bist du mit der zweiten Möglichkeit auf der sicheren Seite.
Die meisten verwenden aber kein XSL, sondern nutzen die Ausgabe direkt im (X)HTML - und dort sollten eben keine fremden Tags auftauchen.
Es gibt zwei wichtige Funktionen in PHP: htmlspecialchars() für das Maskieren der XML-Sonderzeichen "<", ">", "&" und noch irgendeinem, und htmlentities() für das maskieren einiger Zeichen mehr mit Entities (HTML + ISO beispielsweise).
Wenn dein System mit Entities arbeitet, kommst du um htmlentities nicht herum.. arbeitest du aber mit Unicode, dann brauchst du die ganzen Entities eigentlich gar nicht mehr.. (außer &, das wird ja durch htmlspecialchar auch gefiltert).

ich habe es jetzt so, das alle nicht interges aus dem Input(get,post,cookie) durch htmlspecialchars($string, ENT_QUOTES, 'UTF-8') gejagt werden.
Die xhtml Ausgabe sieht dann so aus, wie es htmlspecialchars maskiert hat.
Alle variablen die in ein Sql Statement eingebaut werden, werden vorher durch mysql_real_escape_string gejagt.
Ausserdem werden alle Variablen, die in Datei Operationen gebraucht werden, auch noch durch eine meiner Funktionen geschickt.
Ich denke das sollte reichen, um die gängigsten Angriffs Arten abzuwehren.
Ich nutze natürlich UTF-8.

Unter Umständen wäre ja auch eine Beschreibung in XML interessant, es würde mehr kreative Möglichkeiten bieten, vor allem im Zusammenspiel eines innovativen XSL. Andererseits bist du mit der zweiten Möglichkeit auf der sicheren Seite.

Beschreibung? Ich verstehe nicht ganz wie du das meinst?

Das kam mir in den Gedanken, als ich an XML dachte. Man könnte ja in die Beschreibung so Tags wie , , schreiben, die dann außerhalb des Beschreibungtextfeldes per XSL eine Bedeutung hätte.
Anderer Ansatz: Datenbankschreibparameter mit der Mysql Escape-Funktion maskieren und nur die Ausgabe "XML-sicher" machen.

Klasse, ich hoffe nur, ich habe Euch damit nicht Euer Wochenende versaut.
Beim herausfiltern von solchen gefährlichen script-Anweisungen gilt es aber nicht nur auf -Tags zu achten. Denkbar wären auch andere, böse Varianten.
z.B.
Auch darauf sollte geprüft werden.

Das ist doch einmal ein schönes Tool. Danke für diesen Hinweis, dass kannte ich nicht. Ich werde mich einmal dran machen so etwas auch für ASP.NET umzusetzen, zumal es von der Idee her wirklich toll ist.
Allerdings auch hier wieder ein warndener Hinweis. Wie immer wenn man Standardtools verwendet, kann es auch leichter passieren, dass es für Hacker interessant wird sich daran zu versuchen. Also sollte man beim Einsatz eines solchen Tools immer darauf achten, ob da nicht doch irgendwelche Exploits bekannt werden und stets zu aktuellste Version verwenden. Alles altbekannte Weisheiten, aber leider stelle ich immer wieder fest, dass nicht jeder seinen akutellsten und gefixten Linux-Kernel, PHP-Version oder Windows-Update aufgespielt hat.
Grundsätzlich gilt auch, dass solche Informationen wie und mit welchem Tool ein System geschützt wird, nicht unbedingt in einem öffentlichen Forum gepostet werden sollte :-) Jetzt weiss ja jeder wo und wie er ansetzen muss.
Aber nochmal danke für die Info. :-) Ich denke, dass sollte man weiterempfehlen.