Profil-Exploit auf Steam: Warnung vor schwerer Lücke (Update)

Nutzer des Valve-Distributionsnetzwerks Steam sollten derzeit besonders vorsichtig agieren und davon absehen, die Profile anderer Nutzer aufzurufen. Das Risiko, aufgrund einer aktuellen Sicherheitslücke zum Opfer von Phishing oder bösartiger ... mehr... Sicherheit, Malware, Virus Bildquelle: White Web Services Sicherheit, Malware, Virus Sicherheit, Malware, Virus White Web Services

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
Ich finde immernoch, das die Browser-Entwicker endlich reagieren müssen und Inline-Javascript im DOM nicht mehr zulassen dürfen. Genau deswegen funktioniert XSS doch nur und nötig ist es auch nicht. Mit ein wenig Hirnschmalz kann alles über externe Script-Dateien gemacht werden. Auf die Entwickler von Webanwendungen scheint ja kein Verlass zu sein. Selbst bei einem Konzern wie Valve nicht.
 
@TroaX: Da stimme ich dir voll und ganz zu. Wenn man sich auch mal den Seitenquelltext von der Steam Seite anguckt, wird einem schlecht...
 
@L_M_A_O: Das ist aber auf den meisten Seiten so.
 
@TroaX: Um eine Funktion in externen Javascriptfiles zuzugreifen ist, aber JavaScript innerhalb des Documents nötig. Wie sonst könnte man eine JavaScript-Funktion starten?

<body onLoad="cookie_abfrage()">

Na, wie würde das wohl ohne JavaScript aussehen?
 
@SunnyMarx: In dem man einen Eventhandler für Body.onload in der Javascript-Datei registriert. Das Zauberwort lautet AddEventListener: https://wiki.selfhtml.org/wiki/AddEventListener
 
@TroaX: Danke für die Info. Soll man also jeden Button, den man irgendwie in ein Projekt einbaut, mit einem EventListener dauernd abfragen? Formulare zur Dateneingabe, die vor dem Absenden auf Korrektheit geprüft werden sollen, Links die mehrere iFrames betreffen, Funktionen die Bilder nach dem Upload aktualisieren, etc. pp... Soll man die also alle in eigene Files exportieren? Dann werden diese Daten aber ganz schön gigantisch, oder meinst Du nicht?
 
@SunnyMarx: Definitiv nein. Allein schon wegen der Übersicht sollten all diese Funktionen in eine eigene Datei gekapselt werden. Der einzige Unterschied zwischen Inline-Eventhandler und registrierten Handlern ist nur die Position im Code. Mit Inline nutzt du eine in einer JS-Datei implementierten Funktion, die du mit OnClick, OnLoad etc. aufrufst. Mit der externen Variante registrierst du auf das DOM-Element den Eventlistener in der gleichen Datei. Schaut man sich nur die JS-Datei an, sieht man nur eine Ansammlung von Funktionen ohne wirklichen Bezug zum DOM-Element. Mit AddEventListener siehst du direkt, worauf sich die Funktion bezieht. Das hilft ungemein beim implementieren größerer Funktionen.

Was den Traffic angeht, ist es kaum spürbar. Die JS-Datei brauchste sowieso und an Dateigröße legt die Datei nur minimal zu. Wenn man dann noch einen Minifyer verwendet, brauch man sich da keine Sorgen machen. Meiner Meinung nach sind die Inline-Eventhandler nur ein bequemes Stützrad-Werkzeug.

Den Code brauchst du sowieso. Egal wie du es drehst und wendest. Er verlagert sich nur. Und mit Serverseitigen Techniken kannst du sogar je nach Unterseite eine beliebige JS-Datei einbinden lassen. Du musst also nicht alles auf einmal ausliefern. Wie schon gesagt brauch man da nur ein wenig Einfallsreichtum. Würde aber ohne Inline-JS extrem viel Sicherheit gewinnen.

PS: Bevor ich es vergesse. AddEventListener macht haargenau das gleiche wie die Inline-Eventattribute. Findet der HTML-Parser ein entsprechendes Attribut, registriert es die Funktion als EventListener. Das gleiche macht der JS-Code direkt.
 
@TroaX: Also ich habe Inline-Javascript in meiner Plattform. Der kommt aus der Datenbank. Jeder Code, der in die Datenbank kommt, wird mit einem gesalzenen Hash versehen und beim einbinden in die PHP-Ausgabe (HTML) zuerst gegen geprüft. Ist der Code identisch mit dem Hash, wird er eingebunden. Ansonsten eben nicht.

Es kommt bei jeder Programmiersprache auch immer darauf an, wie gewissenhaft man Funktionen ein- und umsetzt. Aber die heutige Technologie, die benötigte Geschwindigkeit bei der Entwicklung lädt halt einfach dazu ein, es irgend wie ans Laufen zu bekommen, hauptsache man ist schneller als die Konkurrenz.

Bei meiner Plattform hab ich alle Zeit der Welt und kann mir die nötige Zeit nehmen, um eine Funktion Wasserdicht zu machen.
 
@SunnyMarx: Diese Hash-Überprüfung bringt nur nichts. Der Code kommt so aus der Datenbank, wie er reingekommen ist. Wenn der Hash verhindern soll, das der Code zwischendurch manipuliert wird, ist es absurd. Wäre das nämlich möglich, haste an einer andere Stelle bei der Implementierung nicht aufgepasst. Mit dem Hash verbrennst du nur Rechenzeit. Nicht umsonst heißt es "Alle Benutzereingaben müssen geprüft werden". Die Prüfung der Ausgabe macht kaum einen Sinn. Denn im Grunde wäre die Manipulation des Codes in der Datenbank nur mit einer schweren SQL-Injection Lücke möglich. Und wie gesagt haste da dann an der falschen Stelle gepennt ;)
 
@TroaX: Dann sag mir mal, wie man den Hash ändern will, wenn man das Salz nicht kennt und nur per SQL-Injection an die Datenbank ran kommt? Gibt keine Möglichkeit dazu. Und die PHP-Scripte, mit denen ich das steuern kann, haben Sperren über ein Rechtesystem. Fehlt das Recht, wird das Script nicht ausgeführt. Kommt man also auch nicht dran.

Und nun?
 
@SunnyMarx: Wenn es so abgesichert ist, war der Hash für die Katz.
 
@TroaX: Ist doch Blödsinn.

Wenn ich ne JavaScript-Funktion in die Datenbank schreibe, erzeugt das Script den Hashwert aus dem Script + Salz. Wird die JavaScript-Funktion in ein HTML eingebunden, wird erst das Script mit dem Hash-Wert verglichen. Passt das nicht, gibts einen Fehler.

Fakt ist, man kann das JavaScript nicht ändern, wenn man keinen Zugriff zur Datenbank hat. Und den Hash-Wert kann man nicht ändern, ohne Zugriff auf den Server per SSH, weils keinen FTP gibt. Root-Zugriff ist gesperrt und der SSH-Port geändert. Also viel Erfolg beim Angriff.

Und jetzt sag mir, wie man hier durch SQL-Injection an den JavaScript-Teilen etwas ändern soll...
 
@SunnyMarx: Du hast es nicht verstanden! Dein Hash-Gemache ist blödsinn!!! Wenn du alles andere abgesichert hast, ist das Erzeugen eines Hashes und dessen vergleich vollkommen witzlos!
 
@TroaX: Nein, ist es nicht. Safety first! Ist das Motto. Ich kann alles, so gut ich kann absichern. Das heißt aber nicht, dass es nicht doch ne kleine ausnutzbare Lücke geben könnte. Und wenn einer in die Datenbank einbricht, kann ich so auf jeden Fall sicher sein, dass die JavaScript-Files unangetastet bleiben. Punkt und aus.

Würden mehr Websites auf eine solide Sicherheitstechnik wert legen, anstatt sich auf fertige Bibliotheken zu verlassen, hätten wir weitaus weniger Probleme mit Datenraub.
 
@SunnyMarx: Ohja wir implementieren lieber selbst Laienmethoden, anstatt uns auf quelloffene und seit jahrzehnte bewerte Anwendungen und Dienste zu verlassen. Wir schreiben unsere Webserver und Datenbank-Dienste lieber selbst.

Aber mal den Sarkasmus beiseite. Jeder kann es ja gerne Handhaben wie er möchte. Es ist definitiv nicht nötig. Wer in die Datenbank kommt benötigt keine Manipulation des Javascripts. In der Datenbank kann er wilde Sau spielen. Es gibt einen Grund, warum sich Webentwickler auf den Kommunikationsweg zwischen Nutzer und Webanwendung konzentrieren. Eine Sicherheitlücke in einem tieferen Ring lässt sich auf Seiten der höheren Anwendung nicht richtig absichern, da man nach Ausnutzung dieser einen Zugriff auf das System hat, der mindestens dem des PHP- bzw. Datenbank Systemnutzers gleichgesetzt ist. Niemand geht den Umweg über solche JS-Geschichten, wenn er mit seinem Exploit den Zugriff auf die volle Datenbank hat. Da gibt es interessantere Ziele.

Außerdem hat JS-Code normalerweise nichts in der Datenbank zu suchen. Davon mal ab, das bereits dieses Vorgehen sicherheitstechnisch bedenklich ist, ist der Nutzen davon sehr gering. Was spricht gegen das Auslagern in Dateien? Der Sinn erschließt sich wohl den wenigsten.
 
@TroaX: Quelloffen wie bei SSL und Heartbleed? :o) Joa. Das war mal geil. Quelloffen und ein Standard. Ein Fehler und die Welt gerät in Panik! Und es sind laut einem Artikel den ich neulich las, noch immer ca. 200.000 Server ungepatcht!

Soviel zu dem Thema. Und ich wette, wenn ich weiter grabe, tauchen noch zahlreiche Bibliotheken auf, die alle Standard und Quelloffen sind und durch ne Lücke kompromittierbar waren und vielleicht noch immer sind.

Dann verlasse ich mich lieber auf eigene Funktionen, die nicht jeder kennt und nicht jeder mit etwas Ahnung ausnutzen kann. Damit fühle ich mich bedeutend wohler, als mit Stangenware, die einen im Regen naggisch da stehen lässt.
 
@SunnyMarx: Sag ich ja. Dann schreib den ganzen Kram selber, anstatt gegen "vielleicht noch existierende" Sicherheitslücken an der falschen Stelle anzusetzen. Solche Sicherheitslücken sind in OpenSource Anwendung extrem selten. OpenSSL (welches als einzige Bibliothek betroffen war) ist vom Code her auch eine Katastrophe gewesen. Da hat schlicht auf Grund des schlechten Codes das quelloffene Konzept nicht funktioniert.

Aber das spielt keine Rolle. Sicherheitslücken kann es überall geben. In etablierten Bibliotheken und Anwendungen sind diese wie gesagt äußerst selten. Und wenn sie da sind, helfen einen Laienfunktionen in höherer Ebene auch nicht mehr. Und vor allem unnötige Rechenzeit in PHP dafür opfern bringt erst recht nichts. Da kannst du argumentieren wie du willst. Entweder man vertraut etablierten Systemen, schreibt das ganze selbst oder lässt es ganz bleiben. Aber versuchen, mit dem Bäcker von nebenan Krebs zu heilen, bringt garnichts. Und ich glaube auch nicht, das du gänzlich auf TLS/SSL wegen Heartbleed verzichtest. Wenn dem so wäre, haste dich direkt für jede weitere Diskussion disqualifiziert.
 
@TroaX: wie wäre es wenn man sowas einfach serverseitig klärt?
aufm handy nervt js wie die pest wenn man bspw in einigen foren etc nicht mal mehr den absenden button betätigen kann weil das js nicht laden konnte.
 
@My1: Das liegt einzig und allein in der Hand der Entwickler. Das große Problem ist, das Webentwickler einfach das Thema Netzwerk nicht verstehen. In der Webentwicklung (gerade bei mobilen Anwendungen) ist die Anzahl an auszuliefernden Dateien genauso wichtig wie der Traffic selbst. Wenn man sich mal auf dem Desktop die Anzahl der Dateien vieler Webseiten ansieht, die erstmal geladen werden müssen, sollte einem schon deutlich klarer sein, wo da das Problem liegt. Da werden 20, 30 oder gar 40 und mehr Dateien nachgeladen. Jede hat nur ein paar KB. Dafür sorgen die Latenzen der Verbindung für ein abartig großes Delay. Wenn eine EDGE oder GPRS-Verbindung eine Latenz von 200-500 ms hat, gilt dies für jede Datei. Je mehr Dateien an der Anwendung dran hängen, um so öfter summiert sich diese Latenz.

Mit EDGE laden bei mir die meisten Seiten extrem lang. Vor allem dann, wenn der Cache des Browsers leer ist. Die meisten Entwickler leben wohl anscheinend in den Bandbreiten-Hochburgen dieses Landes. Wenn sie die Seiten in Berlin, Hamburg, München, Köln, Hannover usw. basteln und dort auch in den Netzen testen, dann merken sie diese Probleme auch nicht.

Aber trotzdem liegt es in deren Hand. Wenn sie sich da ein wenig mehr Mühe geben würden, dann müsste man diese Diskussionen einfach nicht führen. Bootstrap, JQuery, 10 oder 20 Plugins in einzelne Dateien, 10 verschiedene Style-Files und am Ende werden sie sowieso immer ausgeliefert. Meistens wird ohne Minifyer gearbeitet. Ich empfehle die Netzwerkanalyse von Chrome oder Firefox. Da sieht man die klaren Fakten schwarz auf weiß. Welche Dateien geladen werden, wie viele, wie viel Traffic, wie lange es dauert und was der Unterschied zwischen mit Cache und ohne ist. Da wird einem manchmal schlecht, wenn man da mal diverse Seiten prüfen.
 
@TroaX: sehe ich ähnlich. mein steamtool (mini-website um steam links direkt in der steamanwendung zu öffnen kann eigentlich nicht sehr viel kleiner werden:
http://ss.my1.info/470220n ich hab sogar den html output via PHP minified. inklusiver ner bootstrap css die aufs nötigste verkleinert wurde

aber persönlich geht mir js wirklich aufn zeiger weil halt wenn bspw das CSS nicht lädt sieht die seite grauenvoll aus aber sie funktioniert. Das kann man von vielem JS nicht behaupten.
 
@My1: Wie gesagt ist es eine Sache der Entwickler. Javascript wird häufig dafür missbraucht, dem Nutzer ein Look and Feel einer nativen Desktopanwendung zu verpassen oder es wird genutzt, einfache Elemente in komplexere zu verwandeln (JQuery Mobile oder UI).

Dabei werden natürlich die Requests nicht synchron zur Session, sondern im Hintergrund asynchron gesendet. Das ist alles aber nicht nötig.

Sie müssten im Grunde nur den gesamten Javascript-Code nehmen, alles in eine Datei packen, einen Minifyer drüberlaufen lassen und dann diese einzelne Datei ausliefern. Dadurch ist es deutlich performanter als mit vielen einzelnen Dateien zu arbeiten. Viele prüfen auch nicht, ob die Komprimierung aktiviert ist. Dadurch geht auch wieder unnötig Traffic ins Land.

Javascript würde ich jetzt generell nicht verteufeln. Es ist definitiv ein hausgemachtes Problem. Da kann JS nichts für. Es ist nur ein Werkzeug. Es will ja auch niemand einen Hammer verbieten, nur weil jemand statt Nägel die Knie anderer verhaut ;)
 
@TroaX: ich persönlich nutze JS soweit es geht nur wenn nötig, bspw U2F logon das nur mit u2f geht.

mMn sind webseiten eben das webseiten und keine "desktopanwendungen" und da unnötig code ins Land zu ziehen finde ich echt sinnfrei und nervig.

mMn sollte jede webseite auch ohne js funktionieren, gerne auch ein paar clicks mehr weil i-wo n dropdown net geht und man erst in die kategorie navigieren muss, aber es muss gehen.
 
@My1: Dropdown geht auch ohne JS ;)
 
@TroaX: I know aber bei vielenseiten und/oder frameworks nicht, siehe bspw bootstrap. CSS vergewaltigen ist ne Kunst, die ich schon sehr viel praktiziert habe. bspw spoiler via checkbox im nirvana (der trigger ist dann das label der checkbox) etc.
 
@My1: Frameworks beißen sich da sowieso gerne mal Gegenseitig. Das ist nichts neues :D
Kommentar abgeben Netiquette beachten!
Einloggen