Böses Cross-Site Scripting Technikwürze 84

Herzlich willkommen zu Technikwürze, eurem Design- und Webstandards-Podcast. Mein Name ist Sascha Postner und heute hört ihr die Ausgabe vierundachtzig am 6. August 2007 zum Thema Cross-Site Scripting.

Herzlich willkommen zu Technikwürze mit Daniel Jackzint und-

Und Sascha Postner.

Heute eine Ausgabe, in der wir über Cross-Site Scripting sprechen möchten. Das war schon lange angekündigt, hat sich aber immer weiter verschoben. Jetzt ist es nun endlich so weit. Es geht also auch um eine Art von Webstandard, nämlich um Sicherheit. Es ist diesmal wieder so wie bei der Ausgabe zu SSL.

Ich möchte gleich noch mal einsetzen, Sicherheit würde ich jetzt nicht als Webstandard ansehen, weil das viel zu unsicher ist, das ja.

Ja, okay. Also ein, ein Standard, den man, für sich selbst definieren sollte quasi. Und, wie bei SSL stehe ich hier als, dummer Tor und, bin eher in der Position, einfache Fragen stellen zu können, damit, sich alle Hörer nicht, zu, unwissend vorkommen. Denn ich hab ehrlich gesagt nicht so richtig viel Ahnung, was Cross-Site Scripting nun wirklich, ist.

Ja, also ich ha, höre nur immer davon, dass es schlecht ist und dass es was, wie der Name schon sagt, damit zu tun hat, dass zwei Seiten, sozusagen, wechselseitig in böse Beziehungen geraten und mir als, unbedarften Web-User suggeriert wird, dass ich eine Eingabe zum Beispiel auf einer Seite mache, und, dann aber diese Eingabe bei einer bösen Seite landet. Ist das so richtig?

Ja, das könnte man so sagen. Das ist ein, ein, Anwendungsgebiet von Cross-Site Scripting, wenn man das als Anwendungsgebiet bezeichnen könnte.

Es ist halt so, dass, dass die gute Seite, wenn wir jetzt von einer guten und einer bösen Seite sprechen, also Webseite, die gute Seite hat dann einen Programmierfehler, die es, die es dieser bösen, bösen Seite oder der bösen Macht ermöglicht, halt in diese gute Seite ent-entweder halt, Inhalte einzubringen, die halt nicht von, von dieser guten Seite sind, sondern von der bösen Seite oder von, von irgendwo anders her. Oder, halt Informationen von dieser guten Seite zu stehlen.

Also du weißt ja, Cookies sind, sind ja eigentlich seitenspezifisch und was eine gute Sache ist, weil, weil ich ja meine persönlichen Daten in meistens oder meistens sind halt persönliche Daten in diesen Cookies gespeichert oder halt Session-Informationen in diesen, in Cookies gespeichert und die möchte ich auch nur mit dieser Webseite teilen, die, für die der Cookie halt gespeichert ist.

Und mit Cross-Site Scripting kann man halt, kann halt diese eine böse Seite halt, diese Cookie-Informationen klauen und könnte dann zum Beispiel, deine E-Mails lesen, weil, weil es deinen, deinen, deinen Session-Key kennt und sich dann-

Von dem Webmailer dann eben.

Genau, ja. Und dann könnt, könnt es sich dann in den Webmailer einloggen, obwohl's ja gar nicht du bist.

Ja, okay. Also das heißt, es geht entweder darum, bösen, also schadhaften Code in eine Seite dauerhaft zu integrieren, ja. Oder, oder, hab ich das jetzt gerade falsch ver-- Also die, die zwei Wege, die du gerade aufgezeigt hast, wäre das ein, zum einen, persönliche Informationen auszulesen durch so einen Programmierfehler auf einer Seite oder halt irgendwie ihn halt zu injizieren, wie du, gesagt hast.

Genau, aber das, das-- Beides Mal ist das nur, da muss ein, ein Benutzer auf so einen bösen Link klicken- -und, dann wird, wird dann also dieser, dieser Schadcode, wie auch immer der geartet ist, entweder zeigt er halt dir diese, diese Falschinformation an oder klaut dir, klaut dir Daten. Dieser Schadcode wird dann in deinem Browser ausgeführt.

Okay, also das heißt, angenommen, ich hätte jetzt so was, es gäbe eine Cross-Site-Scripting-Lücke bei eBay zum Beispiel, dann würde ich die normalerweise nicht, oder betrifft mich das nicht, wenn ich jetzt eingebe www eBay.de und ich geh da drauf, sondern wenn ich zum Beispiel eben eine E-Mail bekomme oder auf einen Link klicke, der auf einer anderen Seite ist, dann ist da sozusagen irgendwie das Böse mit drin, ja?

Genau, ja. Also, das ist halt, ist halt die eine Cross-Site-Scripting-Variante. Das ist halt die clientseitige Cross-Site-Scripting-Variante, weil halt wirklich dieser Schadcode halt in dem Client injiziert wird.

Mhm, mhm.

Und dann gibt es halt noch die serverseitige, Cross-Site-Scripting-Variante. Das, ist im Grunde das Gleiche. Das findet nämlich, es auch nur durch, durch einen Programmierfehler von dieser guten Seite und, und, passiert allerdings dann nicht in dem Browser von, von dem Client, der, der das dann, halt aufruft, diese URL aufruft, diese böse URL aufruft, sondern, in dem, in dem Server direkt. Also da könnte man zum Beispiel SQL-Injection-Attacken, drunter ordnen.

Also d-das halt, wenn ich jetzt als Benutzername nicht, nicht jetzt Daniel Jackzint angebe, sondern Daniel Jackzint, Hochkomma, Semikolon, Delete, from Users oder so. Dann würde ich jetzt zum Beispiel, wenn ich diese Abfrage abschicke und- -, dann würde ich jetzt die komplette User-Tabelle löschen. Das passiert dann ja auf dem Webserver. Nicht auf, auf meinem Rechner.

Verstehe. Also ist es so 'n bisschen so, dass, dass, diese zwei Arten, also clientseitige oder serverseitiges Cro-Cross-Site-Scripting auch dann mit Client- oder serverseitigen Programmiersprachen zu tun hat? Also ist das eine hauptsächlich JavaScript related und das andere mehr zum Beispiel PHP oder, oder SQL related?

Ja, das kann man so sagen, weil einfach, die, diese, dieser Schadcode muss ja auf dem Server oder auf dem Client ausgeführt werden und auf dem Client, also in dem Browser, kannst du halt nur JavaScript ausführen. Oder könnt, könntest du vielleicht irgendwie noch an, kann man, kann man natürlich das auch irgendwie mit, Flash genauso machen wie Cross-Site-Scripting-Attacken oder so. Aber, aber es sind normalerweise ist halt, halt JavaScript halt da die, die Angriffssprache sozusagen.

Und, und halt bei, weißt du, beim Server da, auf dem Server wird ja kein JavaScript ausgeführt. Da musst du halt, da werden, wird halt entweder SQL-Befehle werden da angegeben oder, oder halt irgendwie PHP-Befehle oder irgendwelche, irgendeine serverseitige Programmiersprache halt.

Okay, vielleicht kann ich mal zwei Beispiele nennen und du kannst mir mal sagen, ob sich dabei wirklich um Cross-Site-Scripting handelt, weil, das eine, was mir aufgefallen ist und das höre ich jetzt schon aus dem, was du gerade gesagt hast, raus. Da war ich auf einer, am Auktionshaus für, Konkursware mit einem extrem schlechten Webseitensystem und unter anderem habe ich dort in die Suche nach etwas, etwas eingegeben und hatte tatsächlich ein Hochkomma mit in dem Suchbegriff.

Aber jetzt nicht, weil ich böse Sachen machen wollte und die Preise alle verändern, sondern weil ich irgendwie, in dem Begriff, den ich gesucht habe, ein Hochkomma vermutete, was dazu führte, dass die Ergebnisliste nicht wirklich eine Ergebnisliste war, sondern, ein SQL-Fehler, der ausgegeben wurde. Ist das dann potenziell so 'n Ding, wo man denken könnte: Na ja, also da ist die Wahrscheinlichkeit recht hoch, dass man da irgendwie was-

Ja klar, da kann, das kannst du ziemlich sicher ausnutzen, weil du dann ja mit diesem Hochkomma, das halt nicht, escaped wurde, das da wurde direkt weitergegeben an, an, an den SQL-String, der dann an den, an die Datenbankserver geschickt wurde. Damit hast du ja 'n Fehler verursacht. Heißt also, -

Wenn ich syntaktisch richtiger gebaut hätte.

Du könntest also, wenn du schlau bist und-

Okay, das ist ja auch noch-

Und dann also, also so einen Fehler vermeidest- Indem du halt, ja, man, man, gibt, es gibt sehr, sehr, sehr viele Möglichkeiten. Du könntest zum Beispiel einfach all-alles, den Rest als Kommentar sa-sagen und den Rest, wer danach kommt, als Kommentar wegmachen und dann einfach deinen, deinen Schadcode dann so oder so machen oder so. Aber es gibt da sehr, sehr viele Möglichkeiten. Deswegen ist halt auch ein, ein Punkt, um halt so-solche, solche Cross-Site-Scripting-Attacken zu, zu vermeiden.

Es ist, ist ja einfach, es ist ja immer 'ne programmiert, es ist immer 'n Programmierfehler und, man, man sollte alle Daten, die, die reinkommen, irgendwie von 'nem User reinkommen, als, als potenziell gefährlich betrachten oder als, als, evil betrachten.

Und, man sollte nicht da, da, da jetzt dazu hingehen und sagen: „Okay, ich, prüfe jetzt einfach, ob auf Hochkommata oder ich prüfe jetzt einfach, ob da jetzt 'n HTML-Code drin ist oder 'n Script-Tag drin ist oder so was.“ Weil es nämlich sehr, sehr viele Möglichkeiten gibt, die diesen, dieses Hochkommata anders zu schreiben oder dieses Script-Tag zu umgehen, dass ich da gar kein Script-Tag drinstehen habe, aber trotzdem JavaScript ausführe.

Deswegen sollte man da, da, dazu hingehen und, und, und halt einfach, abprüfen, ob das, was da eingegeben wurde, dem entspricht, was ich erwarte. Also einfach nur 'ne Positivüberprüfung machen. Also da-

Ja, das ist eine Sache, die ich schon sehr schnell gelernt hab, dass man eben zum Beispiel nicht hingeht und sagt, : „Ich filtere jetzt,, das und das und das und das raus, weil's böse ist“, sondern ich gehe halt einfach hin und sage: „Ich lasse nur das und das und das und das zu, weil's gut ist“, wo ich dann wesentlich mehr mit ausgeschlossen habe als, das, was da vielleicht in Zukunft noch mal entdeckt werden kann.

Dann müsste ich ja jedes Mal wieder ein neues, okay, ich filtere nicht nur, selbst wenn man's richtig könnte, nur Hochkommate aus und normale Anführungszeichen, sondern ich-- dann kommt irgendjemand, findet raus, dass man mit, Ös, Üs oder so auch noch irgendwas machen kann und dann muss ich das auch wieder ausfiltern. Und wenn ich das im Vorhinein schon gar nicht erst zugelassen hab, dann, das, dann, dann kann es ja nicht passieren.

Ja, stimmt. Da hat man allerching, allerdings noch natürlich das Problem, dass man vielleicht nicht, nicht alle Fälle, nicht alle Fälle beachtet hat und dann valide Eingaben nicht möglich sind. Aber na ja, das ist halt, denke ich, der, der bessere Weg, als, als dass du dann halt, dass du schadhafte Anfragen halt durchlässt.

Gut, dann sind wir ja froh, dass wir das Auktionshaus schon mal nicht genannt haben. Werde ich denen mal eine E-Mail schreiben, dass wir ihnen eine neue Webseite bauen sollten. Nein, aber, die, die andere Geschichte betrifft mich leider selber. Die hatte ich dir schon mal, per Telefon angedeutet.

Und zwar, hab ich auf einer sehr alten Webseite, die ich auch mit einem, Nicht-genannt-werden-wollenden-Content-Management-System, das es zwar immer noch gibt, das ich aber nicht mehr benutze, ver-verwirklicht habe. Und da gab es ein Modul, das,, sich Webgrab nannte, ja, wo man also sozusagen Inhalte anderer Webseiten auf die eigene Seite, ziehen konnte.

War dafür gedacht, dass man dann halt einfach 'ne Bildergalerie, die extern läuft, oder 'n Kontaktformular oder 'n Forum zum Beispiel auch einfach da reinsaugt in die eigene Seite, ohne da groß irgendwas anpassen zu müssen und konnte dann auch bestimmte Sachen raus, strippen irgendwie, also zum Beispiel Stylesheet-, Dateien oder so. Oder halt eben den Header oder was man auch immer so wollte.

Nun ja, ich hab dann irgendwie so irgendwann mal in meiner, Statistik festgestellt, dass das Anmeldeformular dieser Seite, die ich noch, zu Schulzeiten gebaut habe, überragend viel aufgerufen wird. Und ich hab dann irgendwann mal da angerufen und gefragt, ob die denn so, so super viele Anmeldungen haben und, das hatten sie nicht.

Und ich hab dann festgestellt, dass scheinbar, also weil die URL, die, dieses Webgrab-Modul halt integriert, die wird, - Noch nicht beim, beim, beim Aufrufen der Seite als Variable im, im, also als Query String quasi im, in der URL mitgegeben. Aber wenn man darin ein L-- wenn in dieser gegrappten Seite ein Link drin ist, dann wird die ursprüngliche Adresse darin scheinbar sozusagen, als verschlüsselte String angehängt.

Das heißt, wenn man dann einfach, im Vorhinein einen String halt anhängt, dann f-führt wahrscheinlich sowohl das Formular – ich hab's mir nicht weiter angeguckt – aber sowohl das Formular als auch alle Links auf der Seite völlig obstruse Dinge, und man ist, wahrscheinlich auf irgendwas ganz Bösem. Ja, auch das ist wahrscheinlich Cross-Site-Scripting, ja.

Ja doch, das ist, das könnte man sogar so, so zum Phishing benutzen, ne?

Ja, das ist auch leider so gelaufen, wie ich, von meinem Rechtszentrum im Nachhinein erfahren habe. Ja, also das, scheint tatsächlich dazu benutzt worden zu sein. Das ist jetzt Schande auf mein Haupt, aber, das wie gesagt, war mir vor, ich glaub, die Seite hab ich gebaut vor... Das muss, '99 gewesen sein. Also das sind mal locker acht Jahre her. Ja, vielleicht war's auch 2000. Egal.

Auf jeden Fall ist es länger als, es ist so um die Jahrtausendwende gewesen und dementsprechend, möge man mir das verzeihen und das zeigt einmal mehr, dass man sich vielleicht seine alten Schandtaten öfter mal angucken sollte, um nicht irgendwann dann da in 'ner Katastrophe zu stehen, ja.

Ja. Jetzt ist es doch passiert. Jetzt muss ich doch husten.

Ja, das können wir ja alle verstehen. Aber, vielleicht,, bevor wir jetzt weiter auf meinen, alten, Missetaten hier herumreiten, wär ja mal 'ne ganz andere interessante Sachen, Sache, nämlich worauf muss ich denn achten? Also, man hört zwar immer ja wieder von, dass eben auch so Seiten wie eBay oder irgendwelche Webmailer vielleicht irgendwelche Cross-Site-Scripting ermöglichen, noch viel schlimmer bei Banken.

Aber was mach ich denn, wenn ich jetzt meine kleinen Web, Anwendungen programmiere oder mal irgendwie an meinem Content-Management-System ein Modul hinzufüge? Ich hab ja mittlerweile so einige Standards, im Kopf, dass ich, das ich früher nicht hatte. Zum Beispiel, dass ich, Variablen erst mal als leer definiere, ja, damit die nicht irgendwie übergeben werden können noch, und überschrieben werden oder so.

Das mach ich alles mittlerweile, aber ich bin mir sicher, das, was ich so programmiere, ist teilweise schon sehr anfällig. Also worauf muss ich im Besonderen achten?

Oh, das, hängt natürlich auch 'n bisschen von der Programmiersprache ab, aber wir beide kennen uns wahrscheinlich am besten in PHP aus und-

Ich kenn mich nur in PHP aus. Dementsprechend ist das richtig.

Ja gut, eigentlich ist, ist, ist, tut man gut daran, alles, einfach diesen Grundsatz, zu Herzen zu nehmen, dass alles, was, was vom, vom Benutzer kommen, kommt, halt böse ist und, und, als, als solches betrachtet werden muss. Und, zum Beispiel ist auch dieses Web-Grab-Modul, das ist einfach fehlerhaft, wenn, wenn, wenn, wenn, wenn du da im, in der, in der URL halt auch verschüsselt, war ja wohl noch nicht so 'ne gute und große Verschlüsselung-

Wahrscheinlich nicht, ne.

-halt die URL der, der zu grappenden Seite ein-einbindest. Also das, das ist halt, das, das muss einfach gecrackt oder irgendwie, da, da der sportliche Ehrgeiz wird da, wird da hervorgerufen.

Nee, verstehe ich. Ja.

Und, wenn das eh noch 'n Open-Source-Projekt ist, dann hat man das ja noch, noch leichter, weil man da kann ja gucken, wie das verschüsselt wurde. Also das ist eigentlich- -so was darf man eigentlich nicht machen. Und, an sich, sollte man wirklich darauf achten, dass, dass, man so wenig, Daten, also, Daten, die der, die der Benutzer, wo der Benutzer irgendwas, kaputtmachen könnte, so wenig Daten wie möglich bei, beim Benutzer speichert.

Also per Cookie oder per URL oder dass so, dass der Benutzer überhaupt da rankommt. Also wenn-- das, das Beste ist halt einfach, das gibt's halt in jeder normalen Programmier- oder Skriptsprache, dass man das irgendwie, in, in der, in der Session für diesen Benutzer halt speichert. Da kommt der Benutzer einfach gar nicht ran. Also wenn, wenn ich jetzt, hm, fällt mir auch mal so 'n, so 'n kleinen Fall wo-

Ja, unwesentlich.

-wo, wo du, wo, wo man dann gespeichert hat, dass, dass, ob, ob man Administrator oder ist oder nicht ist, wurde in einem Cookie gespeichert, auch irgendwie verschüsselt, aber auch nicht so richtig verschüsselt. Und dass so was, so 'ne, so 'ne, so 'ne Information, die darf nie zu dem Benutzer gelangen, sondern die muss immer auf dem Server bleiben. Und da kann der Benutzer ja gar nix dran, gar nix mehr ändern dran.

Mhm. Das heißt also, wenn ich zum Beispiel in der PHP-Session die Informationen durchreiche, dann sind sie potenziell auf jeden Fall deutlich sicherer.

Ja, genau. Und, da ist natürlich auch nicht super sicher, weil, weil man könnte mal 'n, so 'n, könnte mal 'n so 'n Session-Hijacking machen, dann könnte man ja irgendwelche, wenn die Session von 'nem anderen klauen-

Mhm, mhm.

-indem man einfach irgendwie seine Session, Identifikation bekommt oder- -oder einfach nur, nur halt per Zufall welche ausprobiert.

Mhm, mhm.

Ja, aber da, die kann man, da, da kann man natürlich auch, Gegenmaßnahmen ergreifen. Ja, aber, aber jetzt noch, zurückgehend, was man gegen Cross-Site-Scripting, machen kann, -

Ist 'n bisschen unübersichtlich.

Es ist eigentlich, weil, weil man, weil man wirklich, wir können dann in, in den Shownotes auch, auch mal auf einen Link verweisen, von hackers.org oder ha Punkt c-k-e-r-s Punkt org. Da, da ist zum Beispiel, das sind zum Beispiel, glaub ich- Wahrscheinlich über hundert Möglichkeiten, beschrieben, wie man, wie man JavaScript-Code in, in Benutzereingaben verschlüss-- so, encodiert, also verschlüsselt irgendwie.

Also eben, du meinst in den Eingabefelder zum Beispiel von Benutzernamen-... oder Suchanfragen oder solche Sachen, ja.

Wie man da JavaScript-Code einbinden kann, sodass die meisten, JavaScript-Code-, Entdecker das nicht finden. Da gibt's halt hundert oder mehr Möglichkeiten.

Oh Mann, ja.

Also deswegen ist es, ist es ein wirklich, essenziell, dass, dass man, dass man wirklich, die Benutzereingaben sehr, sehr stark kontrolliert. Und wenn man das gemacht hat, dann, und dann ist, können nur noch eigentlich, andere Program-- also, nicht Programmierfehler, sondern, sondern, sondern halt, Fehler der Sprache. Also PHP ist da leider sehr an, sehr anfällig, dazu führen, dass, dass, dass trotzdem Cross-Site Scripting, Defekte-

Mhm. Weil einfach Fehler in der Programmiersprache so drin sind, dass einfach irgendwelche Buffer Overflows, ich hab keine Ahnung, was das ist, aber ich hör davon immer.

Ja, ja, nicht, nicht, nicht nur das. Das kann ja überall passieren, aber in, in PHP ist ja zum Beispiel dieses Register Globals, -... so, so beliebt dafür, dass, dass man Angriffe auf, auf, auf PHP-Software fährt, weil man, weil halt einfach-... damit, weil man vom, vom Browser aus halt einfach globale Variablen in so 'nem PHP-Skript verän, verändern kann. Und da muss man natürlich aufpassen. Ja.

Okay. Ja, also die, die Domain werden wir mit Sicherheit dann mal kurz angeben, es sei denn, ist das illegal?

Nö, nö, das ist nicht illegal.

Okay, ja, wir können ja jetzt nicht auf, irgendwelche Kopierschutzumgehungssoftware zum Beispiel verlinken. Ich dachte, bei solchen Sachen, vielleicht ist das auch nicht so gern gesehen. Aber ja, ich mein, wo man ja teilweise in irgendwelchen obskuren,, Auktionshäusern, teilweise Exploits für zigtausend von Dollarn kaufen kann, um dann halt irgendwie, Sachen zu hacken und da sind mit Sicherheit auch die ein oder andere Cross-Site-Scripting-Lücke mit drin..

Das stimmt, aber ich glaub, so was ist wahrscheinlich auch gar nicht illegal. Also, ein, eine Lücke zu verkaufen ist ja wahrscheinlich nicht illegal, nur sie anzuwenden wird ja wohl illegal sein. Also das hängt wahrscheinlich auch noch damit zusammen, wo du sie dann anwendest.

Das ist jetzt natürlich auch eine sehr interessante Diskussion und, vielleicht sind wir da auch einfach ein bisschen liberaler, als, als viele andere Menschen. Nein, okay.

Also für mich ist halt wirklich so das Problem, das ist so eine der großen, Ängste, die ich immer habe, wenn ich mal so an meinen kleinen, Modulchen rumprogrammiere oder so, dass ich denke, okay, ich mach hier jetzt grad, ich entwickel grad 'ne Bildergalerie und letztendlich kann man damit das halbe Rechenzentrum dann auf einmal übernehmen oder so, weil ich irgendwo eine Dropdown-Box eingebracht-- na ja, Dropdown-Box ist ein blödes Beispiel, aber, irgendwie 'ne Sucheingabe zum Beispiel ermöglicht habe.

Wie, was aber-- vielleicht kannst du das noch mal praktisch erklären, weil das scheint ja so mit so die, die Kernwaffe zu sein. Also wenn ich sage, zum Beispiel bei einem Suchfeld, ja, wie würd ich denn da überprüfen, ob das, das ist, was ich erwarte? Also sagen wir jetzt mal zum Beispiel bei einer ganz normalen Suche auf 'ner Seite. So, was würdest du da sozusagen als Abfrage dazwischenschalten, bevor der, das aus dem Suchfeld im Prinzip wirklich in der Datenbank gesucht wird?

Also hat man was mit regulären Expre-expressions, oder?

Ja, das kann man natürlich, also es ist wahrscheinlich das Einfachste, dass man, dass man dann halt 'n regulären Ausdruck angibt und, vorher prüft, ob, ob diese Eingabe diesem regulären Ausdruck entspricht. Muss man allerdings natürlich, 'n gescheiten regulären Ausdruck benutzen. Also-

Das kennen wir auch schon.

Ja, bei, bei, bei diesem, bei dem Suchfeld würd ich jetzt sagen, okay, das, da sind halt einfach nur alphanumerische Zeichen erlaubt, Umlaute, wenn wir in Deutschland sind und dann das Leerzeichen.

Mhm. Und das heißt, alle anderen Zeichen würdest du dann in dem Fall einfach, nicht zu 'nem Fehler führen, aber die willst du einfach weglassen. Also ein Bindestrich spielt einfach keine Rolle, wird wie ein Leerzeichen behandelt oder so.

Ja, das, das könnte man auch, also, ja, beim Suchfeld ist wahrscheinlich einfach das Einfachste, dass man einfach die, die Eingaben, die nicht valide sind, einfach, einfach als, als ein Leerzeichen, annimmt und, und gut ist. Bei, bei anderen Sachen sollte man ja schon eine Fehlermeldung geben: „Okay, hier-

Ja, aber Benutzernamen sind eben keine, sind auch eine andere-

Ja, aber, aber zum Beispiel 'nen, 'nen, 'nen, 'nen, einen Namen von einem Menschen. Wenn ich da jetzt irgendwie das, E-Akzent oder so-... den ich nicht hinzugefügt habe und, und jemand heißt halt, hat 'n Namen mit 'nem E-Akzent dran, drin-... dann, dann ist es ja schon gut, wenn ich ihm das jetzt sage: „Hey, du, das geht bei mir grad nicht."

Ist auch ein bisschen gemein, aber-

Das ist halt wieder das Problem, dann hast du halt nicht alle validen Eingaben halt als, als valide, halt markiert. Das ist halt, das ist halt da das große Problem, dass, dass man das halt machen muss.

Ja. Gibt's denn irgendwie als Abschluss, vielleicht gibt's denn irgendwie 'ne brauchbare, Möglichkeit, so was zu suchen?

Ja, also bei mir war's jetzt wie gesagt dadurch, dass ich einfach geguckt habe und auf meinem Server überraschend viele Aufrufe von einer Seite irgendwie, gesehen habe und gedacht hab: „Ja, also das ist eigentlich nicht so, das, das kann nicht sein." Also so viele Teilnehmerplätze haben die in ihren Kursen gar nicht, wie, wie die, Anmeldungen offensichtlich hier vollziehen würden. Gibt's irgendwie 'n, 'ne Möglichkeit, auf Cross-Site Scripting zu schauen?

Wo kann ich in meinen Logfiles irgendwo was sehen?

Natürlich, die sind, die sind in deinen Logfiles ja verzeichnet, weil die, die laufen ja über, über normale GET-Requests ab. Deswegen stehen, stehen die auf jeden Fall in deinem Logfiles drin und du könnt, kannst sie dann im Nachhinein Nachvollziehen, was dann da passiert ist.

Stehen in den Logfiles auch normalerweise die, die, Query, Query Strings heißen die, glaub ich, ne? Die Sachen, die man dann so mit, also wenn ich dann jetzt was-

Für, für GET-Requests und das, das passiert ja, wenn du auf 'n Link klickst. Da stehen die in den Logfiles drin. Also für POST-Requests, steht das nicht drin, aber- Da, da, also, also fünfzig Prozent der Cross-Site Scripting-

Weil ich hab tatsächlich in meiner Statistik wohl gemerkt, ich hab jetzt nicht, aber die ist, die basiert ja auf den Logfiles. Da hab ich dann nicht weiter nachgeguckt. Da war dann immer wirklich nur der Seiten, die Seiten-URL zu sehen in meinem speziellen Fall und nicht noch hinten, hinten dran, -

Ja, dann wurde das aber abgeschnitten, ja, aber eigentlich in den Logfiles steht das ja schon drin.

Können wir dann nach der Sendung mal reinschauen und dann- Ja, ich bin dann doch noch mal neugierig. Das ist jetzt nämlich grade erst zwei Wochen her, dass ich das irgendwie behoben habe und so. Nee, okay, also das heißt, man kann schon so 'n bisschen das mal nachvollziehen. Also wenn man-

Ja, ja also ich man-- Was, was dann möglich wäre, vielleicht, dass man einfach nach, nach langen URLs sucht, die dann aufgerufen wurden in deinem Server. Weil ja solche, solche, Schad-- so 'n Schadcode muss ja auch 'n bisschen, ist ja 'n bisschen größer und der braucht halt 'n bisschen, 'n bisschen mehr Platz in der URL halt. Das könnte man vielleicht machen.

Ein, man, was man natürlich machen kann, ist, nach, nach irgendwie nach, nach der spitzen Klammer auf oder zu oder so zu suchen, aber das ist halt natürlich, nur bei sehr schlecht gemachten Cross-Site Scripting-Attacken dann so der Fall.

Ja, okay. Ha, na ja, das, ist jetzt zwar nicht sehr hilfreich, weil man jetzt nicht so viel an die Hand, bekommt, aber, ich denke, wenn das halt wirklich 'ne sehr populäre Lücke ist, zum Beispiel wie bei mir, da waren das halt einfach mal, ich glaub, das waren sechzehntausend Aufrufe oder so. Also möchte ich nicht wissen, was da phishingtechnisch abgegangen ist. Ja, das ist, glaube ich nicht das Allerbeste, das jetzt hier zu erzählen, aber, na ja.

Oder bist du gewinnmäßig beteiligt, oder?

Nee, nein, nicht. Also ich, hoffe auch, wie gesagt, ich weiß ja nicht, was dann da jetzt genau gelaufen ist, aber ich hoffe, dass da nicht so viel passiert ist und dass es einfach immer nur so Versuche waren und dass in irgendwelche Pornospam-Messages integriert war oder so und die Leute dann immer da draufgekommen sind und gedacht haben, okay, hier für 'n Kurs anmelden, was soll 'n das jetzt? Keine Ahnung.

Egal, aber, es zeigt einfach, dass, man wirklich sehr aufpassen muss und, auf der Hut sein sollte. Und vielleicht ist das ja auch das, passend-- Hast du noch eine abschließende Warnung oder?

Nein, also man, man kann halt einfach nur, diesen Kampf gewinnen, indem man andauernd die Updates von all seinen Softwaren ein, einspielt. Weil, weil es halt einfach so viele Möglichkeiten gibt, diese Cross-Site Scripting, Attacken auszuführen. Das ist, dass man eigentlich immer mal wieder eine neue Möglichkeit entdeckt und- -die muss halt erst wieder, muss halt erst wieder gegengerüstet werden in der Software und da musst du halt das Update für einspielen.

Das ist, ein guter Ratschlag, den ich mir auch sehr zu Herzen nehmen werde, weil hätt ich nämlich, die aktuellen, hätt ich das Content-Management-System damals mit dem Projekt begraben und hätte auf die aktuelle Version des Nachfolger-Content-Management-Systems, upgegradet, wär das nicht passiert. Zugegebenerweise wusste ich damals gar nicht mehr, dass ich's noch auf meinem Server hab. Aber egal.

Gut, okay, dann, raten wir euch einfach, auf der Hut zu sein und, immer schön fleißig eure Software upzudaten, sowohl auf den Servern, das heißt also sowohl PHP als auch, ähmmm, euer, eure eigene Software quasi..

Ja, stimmt. Wenn wir da wieder auf die Client-Seite zurückgehen, wir benutzen ja so, sozusagen alle Firefox wahrscheinlich, ne.

Nun.

Da, da könnten, da ist dann vielleicht auch die Extension NoScript zu empfehlen für direkt für Cross-Site Scripting, At-- also gegen Cross-Site Scripting-Attacken, weil die ja wirklich, auch so generische Filter eingebaut hat, u-um Cross-Site Scripting-Attacken zu erkennen. Ist natürlich wieder das Problem, da werden Cross-Site Scripting-Attacken erkannt und, und nicht die validen Eingaben erkannt. Das heißt also, dass, dass da nicht alle rausgefunden werden, aber, aber-

Also es schützt mich aber jetzt sozusagen, es ist jetzt keine Möglichkeit, des Entdeckens von Cross-Site Scripting im Sinne von hier könnte es passieren, sondern das, schützt mich nur als Benutzer quasi- -damit ich nicht selber Opfer einer Cross-Site Scripting-

Genau, dass du keine Daten verlierst oder, - -nicht die Seite-

Niemand mein eBay-, Pass-Passwort. Ja, okay. Ja, verstehe. Gut, dann, drücken wir euch allen mal die Daumen, dass es euch nicht so ergeht wie mir und dass mir nicht so viel passiert ist. Ja, wie immer gilt, und das funktioniert ja mittlerweile in den Kommentaren ganz hervorragend.

Also wenn ihr irgendwelchen, welche Falschaussagen von uns entdeckt oder, Anmerkungen habt, selber irgendwelche Geschichten, Beispiele für Cross-Site Scripting, was euch passiert ist, dann postet es doch bitte in den Kommentaren. Wenn ihr auch vielleicht den einen oder anderen Link habt, wo man, sich gut informieren kann oder, was mich zum Beispiel sehr interessieren würde, irgendwie ein gut gemachtes, Alert-Portal.

Hast du da noch irgendwas, wo man, wo so aktuelle Cross-Site Scripting-Lücken aufgeführt werden, wo man drauf achten muss? Also ich mein, außer bei Heise, wo ja eigentlich auch immer alles drin steht. Heise Security.

Heise Security würde ich da ei-eigentlich, weiß ich da eigentlich nur oder ja. Natürlich, wenn man da am Puls der Zeit bleiben, bleiben möchte, dann kann, könnte man natürlich die Full-Disclosure-Mailing-Liste abonnieren. Da werden solche, werden halt Sicherheitslücken, also-

Wie viel, wie viel so am Tag?

Ach, weiß ich nicht. Also ich guck da auch nur mal ab, ab und zu rein. Also ich hab die jetzt nicht abonniert, aber ich denke mal, das, das ist irgendwie zwanzig Meldungen am Tag oder vielleicht mal fünf Meldungen am Tag oder so.

Joa, ich sollte vielleicht einfach gar nicht mehr programmieren und, das einfach den Profis überlassen. Also das ist vielleicht besser, als die Zeit damit zu verbringen. Okay. Gut, dann bedanken wir uns auf jeden Fall fürs Zuhören und hoffen, euch den einen oder anderen Hinweis geliefert zu haben. Vielleicht die Leute, die nicht wussten, was Cross-Site Scripting sind, wissen's vielleicht jetzt. Ich bin auf jeden Fall schlauer geworden.

Sehr gut. Jetzt jeder recht.

Genau und, wir freuen uns a-aufs nächste Mal.