Böses Cross-Site Scripting
Technikwürze 84
Meta: S1 · E84 · Typ full · Veröffentlicht · Aktualisiert
Moderation: Sascha Postner, Daniel Jagzent
Zusammenfassung
Wer sich im Internet bewegt, der sieht sich mit "Cross-Site Scripting"-Lücken konfrontiert. Egal ob man als Anwender oder als Entwickler unterwegs ist. Schlimm wenn man da nichtmal genau weiß was XSS überhaupt ist und wie man sich schützen kann. Daniel Jagszent klärt Sascha Postner und die Hörer auf.
Inhalt
Böses, böses Cross-Site Scripting
Immer wieder stolpert man in der einschlägigen Zeitschriften über den Begriff Cross-Site Scripting, wird zeuge dämonisierender XSS Verfluchungen der IT-Kollegen am Kaffeeautomaten oder erhält Warnungen vor Code Injections bei populären Webanwendungen per Email.
Da Moderator Sascha Postner absolut keine Ahnung hat worum es sich handelt, aber just selber Opfer einer XSS Lücke in einem ehemals verwendeten Script geworden ist, erläutert Daniel Jagszent ihm und den Höreren worum es geht. Auch einige grundlegende Basis-Tipps zum Abdichten der eigenen Anwendung fehlen nicht.
Erwähnt sei, dass es dank des schier unübersichtlichen Themas keine umfassenden Einblicke geben kann, sondern eher eine kurze Einführung in die Scheunentore die man mit schlechter Webentwicklung aufreißt.
Ergänzend etwas Linkliteratur zum Thema
- Heise Security Einführung in XSS
- kurzes PDF als Einführung (Uhlmann,2003)
- englische Erklärung mit Codebeispielen (Shiflett,2003)
- wie immer: Wikipdia mit weiteren sehr schönen externen Links am Ende des Artikels
Workshop
Wer nun anschließend wissen will ob er das Problem wirklich verstanden hat und seine eigenen Cross-Site Scripting Fähigkeiten einmal testen möchte, der schaut sich diese Schnitzeljagd für XSS an.
Kommentare (9)
Ich finde es gut, dass ihr auch Sicherheitsthemen ansprecht, die meiner Meinung nach leider nur sehr selten behandelt werden.
Cross-Site Scripting bezieht sich allerdings eigentlich nur auf Angriffe, die durch Injizierung von Schadcode beim Client ausgeführt werden, also typischerweise JavaScript-Schnipsel. Die anderen genannten Sicherheitsgefahren (SQL-Injektionen, Session Hijacking) wären also eher Themen für sich.
Allgemein sollten jedoch jegliche offensichtliche und versteckte Benutzereingaben durch eine Kombination aus Validierung (Erkennen von Fehleingaben), Filternung (Entfernen der Fehleingaben) und Maskierung (Entschärfen der Metazeichen) verarbeitet werden. Denn die meisten Sicherheitsgefahren (so etwa Cross-Site Scripting, SQL-Injektionen) werden durch fehlende oder ungenügende Maskierung der Metazeichen ermöglicht.
Das Thema wäre gut, würden die beiden Redner es auch den Laien, die davon betroffen sein werden, es verständlich erklären. Leider finde ich die Erklärungen ziemlich umständlich und für einfache Benutzer nicht nicht nachvollziehbar.
Ich fand es ganz gut erklärt. Ich verstehe als Programmierlaie das ein oder andere mehr. Hätte mir zwar mehr Hinweise zur Vorbeugung erwartet, aber nachdem ich jetzt mal selber etwas weitergelesen habe (und leider feststelle, dass meine PHP Entwicklungen furchtbar anfällig sind) muss ich sagen, dass das für einen Podcast echt schwer gewesen wäre.
Danke auf jeden Fall für die Hilfe zur Selbsthilfe! ;)
Danke für diese Folge - sie hat mir das Thema XSS nähergebracht und hat dafür gesorgt, dass ich ab jetzt ein bisschen mehr auf die ein oder andere XSS-Lücke achten werde. Die einfachsten Sicherheitsmaßregeln kannte ich (wie wahrscheinlich viele hier) zwar schon, aber die ein oder andere Lücke war dabei, dir mir neu war.
Gegen Probleme mit der Validierung von Benutzereingaben bzw. mit Injections bietet Ruby on Rails gute Mittel — die eingebauten Validierungsoptionen sind beispielhaft…
Wie immer interessant – jedoch weiss ich eigentlich immer noch nicht, was Cross Side Scripting eigentlich ist.
Es wurde eher auf Programmier-Aspekte/Vorbeugung eingegangen, als zuvor eine die Thematik allgemein zu erklären.
Bin diesmal leider nicht wirklich schlauer geworden – aber dennoch herzlichen Dank und weiter so!!!
Jim
Also entweder ich hab was überhört, oder ihr habt 2 Sachen vergessen:
about und im PHP dann include($_GET['page'].'.php');
Jetzt rufen wir die Seite mal so auf: http://www.meine.seite.de/index.php?page=
Was passiert dann? Genau, http://www.boese.seite.de/script.php wird includet und der Code ausgeführt. Und jetzt kommt nicht, dass der Code auf dem anderen Server ausgeführt wird. Dieser hat villeicht garkeinen PHP Parser oder es wurde z.B. per .htaccess deaktiviert. Schon kann man auch auf die Datenbank zugreifen u.s.w.
Julian
Leider hap ich ein paar Fehler gemacht.
Julian