Loading

Sicherheitslücke auf der Webseite von Team-Alternate #3

Posted in Uncategorized on August 22nd, 2013
Tags: , , ,

UPDATE: Heute am 27.08.2013 nach also ganzen 11 Tagen ist die Sicherheitslücke behoben.

Es ist mal wieder Soweit. Nachdem ich am 11.10.2012 das erste und am 28.06.2013 das zweite mal eine XSS-Lücke auf der Webseite von Team-Alternate gefunden habe, kommt hier nun die 3. Um vielleicht nochmal klar zustellen warum ich auf der Webseite von Team-Alternate war: Ich bin jedes mal auf die Webseite gegangen weil diese im Zusammenhang mit eSports erwähnt wurde. 2012 war das der Fall, weil ein Spieler von Team-Alternate (unso) Werbung gemacht hat und die beiden anderen Male weil carni (ein ESL-Moderator) auf Twitter etwas von der Seite verlinkt hatte.

Die alte Story?

Die alte Story findet Ihr in meinem Artikel: Sicherheitslücke auf der Webseite von Team-Alternate

Die ganze Story

  • 11.10.2012: Ich Melde das erste Mal die XSS-Lücke auf eurer Webseite. Betroffen war hier die Mitgliedersuche und die Variable “nick” per GET
  • 12.10.2012: Die Lücke wurde behoben.
  • 28.06.2013:Wieder bin ich direkt auf eine Lücke gestoßen: XSS, Variable criteria, Methode POST. Dennoch die selbe Lücke, denn es wird wieder einfach eine Benutzereingabe im Frontend 1zu1 ausgegeben.
  • 08.07.2013: Die Sicherheitslücke wurde gelöst und zwar nach ganzen 10 Tagen. Meiner Meinung nach etwas lange. Reagiert hat man damals erst auf meinen Tweet: https://twitter.com/googlesearchfoo/status/353927677545152513
  • 15.08.2013: Wieder eine Sicherheitslücke. XSS, Variable typ, Methode POST. https://twitter.com/googlesearchfoo/status/367971690052976640 Es handelt sich um die exakt gleiche Sicherheitslücke.
  • 21.08.2013: Heute versende ich das ganze nochmal als E-Mail, weil sich bisher leider bei euch noch nichts getan. Und das nach mehr als 5 Tagen. Leider kam ein Auto-Responder zurück :/
  • 27.08.2013: Die Sicherheitslücke wurde gelöst und zwar nach ganzen 11 Tagen.

Was stört am meisten daran?

Was mich am meisten an der ganzen Sache stört ist die Bearbeitungszeit und die Reaktion. Beim ersten mal wurde die Sicherheitslücke ja relativ schnell gelöst, doch im 2. Fall ist die Bearbeitungszeit meiner Meinung nach einfach zu lang. Außerdem finde ich die Nachhaltigkeit auch ziemlich schlecht. Warum prüft man als Webentwickler zumindest nach der 2. Meldung nicht einmal selbst die gesamte Seite? Es gibt ja das ein oder andere Tool mit dem man dieses Lücke auch leicht gefunden hätte. Zum Beispiel Skipfish.

Ich behaupte mal, dass Webseiten von eSport-Teams als relativ technik-nahe gesehen werden können und finde es daher noch mehr enttäuschend, dass so schlecht auf Sicherheitsmeldungen reagiert wird. Das zieht den Ruf dieses Bereiches einfach runter.

Was ist denn jetzt überhaupt los?

Wie Ihr oben an meiner “Timeline” erkennen könnt handelt es sich wiedermal um eine XSS-Sicherheitslücke. Im Prinzip ist das immer noch das gleiche Problem wie bereits 2012, nur das jetzt eine andere Variable verwendet wird. In der Variablen typ kann man also HTML-Code oder auch JavaScript-Code mitgeben, der einfach innerhalb der Webseite von Team-Alternate ausgeführt wird. So ist es möglich wie in meinem Beispiel zu sehen die Webseite von Team-Alternate sehr einfach zu manipulieren.

[ Leave A Comment »]

Sicherheitslücke auf der Webseite von Team-Alternate

Posted in Sidetopics on July 4th, 2013
Tags: , , ,

Heute mal in einer ganz anderen Sache. Ich habe am letzen Freitag, den 28.06.2013 eine Sicherheitslücke auf der Webseite von Team-Alternate gefunden und natürlich auch sofort an den Webseitenbetreiber gemeldet. Da jetzt, genau 6 Tage nach meiner Meldung, immer noch nichts passiert ist, schreibe ich mal etwas dazu auf meinem Blog.

Was habe ich gefunden?

Gefunden habe ich eine simple XSS-Sicherheitslücke. Diese sind sehr einfach auszunutzen muss man ja nur eine Variable die auf der Seite genutzt wird bestimmte Daten mitgeben. Betroffen ist das Suchfeld auf der Webseite von Team-Alternate-Archive-Seite. In dem Suchfeld kann man einen Suchbegriff eingeben, der dann auch noch 1 zu 1 auf der Webseite wiedergegeben wird. Ein gefundenes Fressen also.

Das ganze hat aber bereits eine Vorgeschichte: Bereits letztes Jahr am 11.10.2012 habe ich eine ähnlich Lücke gefunden. Dabei ging es allerdings um das Suchformular auf der Mitgliederseite. Damals war es sogar noch einfacher als heute, so konnte man den eigenen evtl. schädlichen Inhalt einfach in der URL mitgeben. Das hat Team-Alternate jetzt abgefangen. Die Nutzung der URL-Variable funktioniert also nicht mehr.

Allerdings ist die Lücke immer noch da, wenn man die Variable ganz einfach per POST füllt. Also ist es auch heute immer noch möglich einen von mir selbst bestimmten Inhalt auf der Team-Alternate-Webseite darzustellen. Ich habe dazu mal eine kleine Demo angelegt in der man sieht wie das ganze funktioniert (Quellcode) und wie es auf der Seite von Team-Alternate dargestellt wird. Die Demo findet Ihr hier.

Was ist so schlimm daran?

Wer meine Demo sieht, wird vielleicht glauben es sei nicht so schlimm, weil ich ja ein Formular von meiner eigenen Seite absenden. Dazu kann ich nur sagen: Das Formular kann man auch automatisiert absenden. Es muss keine Aktion vom Benutzer erfolgen und dann landet der Benutzer ganz einfach auf der original Webseite von Team-Alternate die einen von mir bestimmten Inhalt hat. Das könnte ein Exploit sein oder zum Beispiel ein Phishing-Formular. Jemand, der Team-Alternate kennt und auf deren original Seite über meinen Link landet wird nicht stutzig werden, wenn dort auf einmal ein Formular mit der bitte um Zugangsdaten auftaucht. Alternate setzt seine Besucher damit also einer großen Gefahr aus und dass bewusst bereits seit 6 Tagen.

Ist die Lücke schwer zu beheben?

Nein. Das ist Sie ganz und gar nicht. Eines der Grundprinzipien der Webentwicklung habe ich einmal auf dem Botfrei-Blog beschrieben. Felder die dazu dargestellt werden, dass ein Besucher der Webseite frei Daten eingeben kann müssen entsprechend im Programmcode der diese Eingaben behandelt verarbeitet werden. In Richtung SQL-Server werden die Daten im Falle von PHP dazu mysql_escape_string entsprechend umgewandelt. Eine ähnliche Funktion gibt es aber auch für Benutzereingaben die ich auf der Webseite selbst darstellen will. Bevor man die Eingabe ausgibt wandelt man deren Inhalt (wieder ein Beispiel in PHP) einfach mit der Funktion htmlspecialchars um. Diese Funktion ist genau dazu gedacht.

Gibt jetzt ein Benutzer in dem Suchfeld Werte eine wie “<img” werden diese nicht mehr 1 zu 1 auf der Seite dargestellt und damit vom Webbrowser als HTML interpretiert sondern als “&lt;img” an den Browser weitergegeben der daraus einfach den Text “<img” macht und diesen auch als Text darstellt.

So Alternate: Jetzt seid Ihr an der Reihe. Wie lange braucht Ihr noch um diese Lücke zu schließen?

UPDATE: Nachdem ich die Sicherheitslücke am 28.06.2013 per E-Mail gemeldet hatte und danach versucht habe Alternate über Facebook zu erreichen habe ich am 07.07.2013 getwittert. Darauf reagierte Alternate und hat die Sicherheitslücke am 08.07.2013 nach ganzen 10 Tagen geschlossen.

[1 Comment »]
Blogverzeichnis - Blog Verzeichnis bloggerei.de Blogverzeichnis