Sicherheitslücke JavaScript

bugcatcher hinterfragte u.A. Folgendes:

Zitat

Ähm. Java wird vor dem (A)usführen geprüft?[...]

Richtig. Meinen bisherigen Kenntnissen nach, stellt die JVM (Java Virtual Machine) für Java-Programme weitgehendst eine einheitliche Ausführungsumgebung zur Verfügung, die sowohl von maschinenabhängigen, als auch von betriebssystemabhängigen Eigenschaften der jeweils eingesetzten Maschine abstrahiert (abgeleitet) unabhängig ist und somit universal gilt und deshalb auch nicht von einzelnen Browsern unterschiedlich interpretiert werden kann. Für Java gelten bereits systemübergreifende Spezifikationen - für JS dagegen (noch) nicht.

Siehe in Bezug auf JVM i.d.F. Bytecode-Verifier – Class-Loader – Security-Manager der JVM-Spezifikation vor dem Hintergrund des „maschinenunabhängigen Zwischencodes“.

bugcatcher fragte u.A. darüberhinaus noch Folgendes:

Zitat

[...]Javascript ist nicht sicher, weil es nicht standardisiert ist?[...]

Du hast richtig gelesen.

bugcatcher erfragte dann noch Folgendes:

Zitat

[...]Und Java hat (,) weil es auf Betriebssystemebene ausgeführt wird (,) nichts mit Javascript zu tun?[...]

Noch einmal – Java-Programme haben mit Java-Script (i.d.F. Browserinterpretationen) nichts gemein.

Java unterliegt als eine objektorientierte Sprache (siehe Datenkapselung / Sprachkonzepte / Nutzungsbeschränkungen) – meiner Ansicht nach – sogar einer noch höheren Sicherheitsstufe als C ++.

bugcatcher stellte im Anschluss noch Folgendes fest:

Zitat

Ich glaub(e) ich dreh(e) mich nochmal´ne Runde im Bett rum. Ich glaub(e) ich träume gerade schlecht...

Wake up to reality...

Oliver

C++ ist ebenso wie Javascript selbst eine objektorientierte Sprache. Und um das eine mal klar zu stellen. Javascript ist sogar noch mehr objektorientierter als Java selbst. Damit ist deine Begründung für die angeblich höhere Sicherheit von Java wenig brauchbar.

Das Java als Plugin ausserhalb des direkten Browserumfeldes ausgeführt wird, ist richtig. Nach der Begründung währen auch Acrobatreader, Quicktime oder Flash sicherer als Javascript. Dabei haben gerade Java und Flash im Browser-Umfeld mehr Rechte als Javascript überhaupt per Design zugesichert wird. Beispielsweise haben Flash und Java Policies die es den Plugins erlauben sogar auf die Verzeichnisstruktur der Hostsysteme zuzugreifen (sofern die Rechte mit denen der Browser gestart wurde reichen). Javascript bietet dieses per Design nicht. Einzig über die Chrome-Umgebung im Firefox werden solche Zugriffe möglich, allerdings setzt das Sicherheitslücken im Browser voraus, die Zugriffe auf die Chrome-Ebene erlauben. Von Webseiten sind diese Zugriffe per Spezifikation nicht gestattet, zudem gehören diese Funktionen im Firefox in der Tat nicht zum Javascript-Standard, sondern sind eine Erweiterung von Mozilla. Der Einsatz einer anderen Virtual Machine bei Java (gibt/gab auch mal eine von MS selbst) stellt keinerlei Garantie dar, dass diese sich an den von SUN vorgegeben Standard hält (im von der MS Java VM war das z.B. auch nicht der Fall).

Um dein Wissen zu erweitern, weise ich hiermit auch mal eben darauf hin das Javascript sehr wohl standardisiert ist. Ich würde an deiner Stelle einmal unter dem Begriff ECMAScript nachschlagen.

Java und Flash sind zudem die statistisch gesehen viel häufig auftretenden Einfalltüren für Unrat, selten ist dafür Javascript selbst verantwortlich.

Ich lasse mich gerne auf eine Diskussion ein, welche Sprachimplementierung vielleicht sicherer für den Anwender ist, aber dann bitte mit brauchbaren Argumenten. Die Zusammenhänge die du hier aufbaust sind einfach Unsinn.

Firefox basiert auf dem XUL-Runner, ist im Grunde damit auch nichts anderes als ein VM für Javascript, wie halt die VM für Java. Zudem wird Code zudem sicherer, je weiter er vom Systemkern entfernt arbeitet und je weniger Rechte er erhält. Java erhält hier mehr und arbeitet auch näher am Kern. Daher wäre das wenn es um Sicherheit geht, eher ein Minuspunkt für Java und nicht Javascript.

Und wie angedeutet, hat die Objektorientierung weniger Aussagekraft über die Sicherheit. Und selbst wenn, auch hier ist Javascript moderner. Dort ist im Grunde alles ein Objekt, selbst eine Variable. Das kann Java nicht von sich behaupten.

Java ist zudem ein Zwischending zwischen kompilierter und interpretierter Sprache. Die Scripte in Java werden zum Großteil zur Laufzeit interpretiert. Einzig die VM ist tatsächlich für das jeweilige Betiebsystem/Hardware kompiliert. Übrigens ein Grund warum Java von der Geschwindigkeit mit anderen Hochsprachen (wie z.B. C++/C#) nicht mithalten kann. Wenn man Firefox wiederum als VM ansieht (siehe XUL-Runner), was nicht so weit von der Wahrheit entfernt ist, dann ist der Unterschied zwischen Java und Javascript von der Implementierungsebene nicht sehr groß.

Nur das Javascript schon von vorne herein so konzipiert wurde, dass es keinen Zugriff auf Elemente ausserhalb der Browser-, bzw. Webseitenumgebung haben soll. Java wurde als vollwertige Sprache entwickelt, die sehr wohl Zugriff auf alle Systemkomponenten bieten kann. Fehlende Funktionalität auszunutzen ist ungleich schwerer als entsprechend dafür vorgesehene Funktionen durch einen Exploit auszunutzen.

Javascript ist standardisiert. Und im Kern agieren die Browser dort auch alle identisch. Zumindest nicht weniger identisch als in anderen Sprachen für die es mehr als einen Compiler bzw. VMs gibt. Jetzt kann man trefflich darüber streiten was sicherer ist. Ein Compiler/VM-Monopol, oder halt eine Vielzahl von Implementierungen. Sollte in der Monopol-Version ein Fehler gefunden werden, haben alle diesen Fehler (siehe Flash/Java). Wird ein Fehler in einer Implementierung gefunden werden, die nur eine von vielen ist, so ist nur diese und dessen Nutzer betroffen. Hat beides vor und Nachteile.

Hatte ich eigentlich schon darauf hingewiesen das Java eine Javascript-Bibliothek mitbringt? Basiert auf der alten Mozilla-Implementierung Rhino. Ist standardisiert. Selbst der Name Javascript gehört SUN, also dem Entwickler von Java. ; )

Was es in Javascript immer mal wieder gibt sind im Sprachstandard nicht vorhandene Erweiterungen der jeweiligen Browserhersteller. Diese Stellen oft auch Sicherheitsrisiken dar. Z.B. hat Firefox ja auf Chrome-Ebene Javascript-Funktionen implementiert, mit denen der Browser sehr wohl auch auf Systemressourcen zugreifen kann, sofern der Browser entsprechende Rechte hat. Diese Funktionen stehen wie gesagt (sofern es keine Lücke im Rechtesystem gibt) Webseiten nicht zur Verfügung. Und auch hier: die Lücken wären auf den jeweiligen Browser beschränkt.

Wie gesagt. In meinen Augen ist deine Argumentation reichlich komisch geraten und kaum eine deiner Begründungen passt irgendwie zu dem was sie begründen soll. Vielleicht täte dir eine Runde drüber schlafen auch nicht schlecht?

Buggy: Full ack.

(Außer diesem kleinen Detail:)

Zitat von bugcatcher

Übrigens ein Grund warum Java von der Geschwindigkeit mit anderen Hochsprachen (wie z.B. C++/C#) nicht mithalten kann.

C# hat im Prinzip den selben Zwischenschritt wie Java (da nennt sich der "Bytecode" nur "Intermediate Language".) Langsamer müssen beide heutzutage dank JIT-Compiler aber nicht unbedingt sein. Es kommt in vielen Fällen mehr drauf an, wie gut die Standardbibliothek (bzw. der im Programm verwendete Teil) der Sprache optimiert ist. Die Geschwindigkeiten der Sprachen selbst unterscheiden sich (meistens) nicht stark genug, um da noch was rauszureißen.

Das ist allerdings inzwischen wirklich wahr (zumindest wenn man C# in den Fokus nimmt. C/++ wird immer noch komplett kompiliert und ist daher nach wie vor schneller. Wenn auch nur noch geringfühgig). Zudem sind die Systeme heutzutage auch viel zu leistungsfähig, als das die geringen Unterschiede noch auffallen.

bugcatcher erklärte u.A. Folgendes:

Zitat

[...]Um dein Wissen zu erweitern, weise ich hiermit auch mal eben darauf hin das Javascript sehr wohl standardisiert ist. Ich würde an deiner Stelle einmal unter dem Begriff ECMAScript nachschlagen.[...]

Danke für das Feedback. Doch daran glaubst Du nicht wirklich? Für JS kann es – ausser dem geschlossenen Intranet - keinen standardisierten Weg der sicheren Script-Umsetzung geben, da die Interpretationsmöglichkeiten der unterschiedlichen Browser-Kombinationen dies nicht zulassen können. Siehe z.B. die aktuellen Diskussionen der HTML5 Inkompatibilitäten innerhalb der sog. „A-Grade Browser“.

bugcatcher stellte u.A. Folgendes dar:

Zitat

[...]Javascript ist sogar noch mehr objektorientierter als Java selbst. Damit ist deine Begründung für die angeblich höhere Sicherheit von Java wenig brauchbar.[...]

Falsch. Innerhalb Java´s stellen die verschiedenen Objekte, Klassen und Instanzen unterschiedliche Konzepte dar, während dagegen bei JS alle Objekte gleichzeitig auch Instanzen sind. Hast Du darüberhinaus eigentlich schon mal etwas von „clientseitiger Interpretations-Fragmentierung“ (Fehlende Kontrolle des Clients) gehört?

bugcatcher stellte darüberhinaus u.A. Folgendes dar:

Zitat

[...]Java und Flash sind zudem die statistisch gesehen viel häufig auftretenden Einfalltüren für Unrat, selten ist dafür Javascript selbst verantwortlich.[...]

Blödsinn.Wie kommst Du darauf? Unter direkter Nutzereinwirkung stellten die durch JS herbeigeführten Integer-Overflows, bzw. die über den Event-Handler möglichen Darstellungsveränderungen von HTML-Seiten (Spoofing) in der Vergangenheit ein weitaus grösseres Gefahrenpotential dieser Scriptsprache dar.

Oliver

Zitat von Oliver222

Doch daran glaubst Du nicht wirklich? Für JS kann es – ausser dem geschlossenen Intranet - keinen standardisierten Weg der sicheren Script-Umsetzung geben, da die Interpretationsmöglichkeiten der unterschiedlichen Browser-Kombinationen dies nicht zulassen können. Siehe z.B. die aktuellen Diskussionen der HTML5 Inkompatibilitäten innerhalb der sog. „A-Grade Browser“.

Du wirfst hier Implementierung und Spezifikation einfach zusammen. Oder du verwendest das Wort "standardisiert" sehr branchenunüblich. Als Argument zur Begründung deiner Ausführung in beiden Fällen völlig indiskutabel.

Zitat von Oliver222

Falsch. Innerhalb Java´s stellen die verschiedenen Objekte, Klassen und Instanzen unterschiedliche Konzepte dar, während dagegen bei JS alle Objekte gleichzeitig auch Instanzen sind.

Tja. Dann sei genauer in deinen Aussagen? Ich war nicht derjenige der mit Begriffen wie "objektorientierte Sprache" um sich wirft und offensichtlich was ganz anderes meint, als was seine Begriffe implizieren. Wenn du einen Unterschied herausstellen willst, mach es richtig oder lasse es. Aber wunder dich nicht, wenn dich keiner versteht oder man dir eine fehlerhafte Argumentation vorwirft.

Zitat von Oliver222

Hast Du darüberhinaus eigentlich schon mal etwas von „clientseitiger Interpretations-Fragmentierung“ (Fehlende Kontrolle des Clients) gehört?

Nein, aber du darfst mich gerne aufklären, wo hier zwischen einer beliebigen JavascriptVM und der JavaVM der Unterschied liegt. Ich schätze eine ausführlichere Erläuterung wäre ohnehin für dieses Thema dienlicher.

Zitat von Oliver222

Blödsinn.Wie kommst Du darauf? Unter direkter Nutzereinwirkung stellten die durch JS herbeigeführten Integer-Overflows, bzw. die über den Event-Handler möglichen Darstellungsveränderungen von HTML-Seiten (Spoofing) in der Vergangenheit ein weitaus grösseres Gefahrenpotential dieser Scriptsprache dar.

Auch hier wird wieder viel Unterschiedliches in einen Topf geworfen (zumindest kommt mir das aufgrund der Formulierungen so vor). Magst Du mir deine Definition von "Gefahrenpotential" nennen, damit ich deine doch sehr flache Abhandlung in irgendeinen Kontext stellen kann?

Irgendwie kommen mir in deinem Text zu viele Sammelbegriffe zum Einsatz die in meinem Buch nicht die Bedeutung haben, die Du ihnen hier zuschreibst. Es mag sogar sein, dass ich deine ursprüngliche Aussage sogar zustimmen würde. Nur klar ist die absolut nicht geworden. Und so wie sie jetzt dort steht ist sie schlicht und ergreifend falsch (formuliert).

Zitat von Oliver222

Danke für das Feedback. Doch daran glaubst Du nicht wirklich? Für JS kann es – ausser dem geschlossenen Intranet - keinen standardisierten Weg der sicheren Script-Umsetzung geben, da die Interpretationsmöglichkeiten der unterschiedlichen Browser-Kombinationen dies nicht zulassen können.

??? JavaScript ist schlecht, weil es unterschiedliche Implementierungen gibt? Nenn mir mal lieber eine ernstzunehmende Sprache, für die es nur eine Implementierung gibt.

Zitat von Oliver222

Siehe z.B. die aktuellen Diskussionen der HTML5 Inkompatibilitäten innerhalb der sog. „A-Grade Browser“.

Was hat JavaScript mit HTML5 zu tun? Das ist eine völlig andere Baustelle.

Zitat von Oliver222

Falsch. Innerhalb Java´s stellen die verschiedenen Objekte, Klassen und Instanzen unterschiedliche Konzepte dar, während dagegen bei JS alle Objekte gleichzeitig auch Instanzen sind. Hast Du darüberhinaus eigentlich schon mal etwas von „clientseitiger Interpretations-Fragmentierung“ (Fehlende Kontrolle des Clients) gehört?

Nein hab ich nicht. Google bis zu deinem Post auch nicht. Bitte gib mal nen Link was das sein soll.
Aber BTT: JavaScript hat ne Prototyp-basierte Vererbung statt einer Klassen-basierten. Aber was genau ist daran jetzt schlimm? Klar, es ist anders. Und wer Klassen gewohnt ist, und/oder versucht, Klassen nachzuahmen, der kommt damit nicht gut zurecht. Aber das ist die Beschränkung des Programmierers, nicht der Sprache.

Zitat von Oliver222

Blödsinn.Wie kommst Du darauf?

Nix Blödsinn.
http://www.trustedsource.org/blog/248/New-M…Browser-Attacks
http://www.techzoom.net/publications/i…ceberg/index.en

Zitat von Oliver222

Unter direkter Nutzereinwirkung stellten die durch JS herbeigeführten Integer-Overflows, bzw. die über den Event-Handler möglichen Darstellungsveränderungen von HTML-Seiten (Spoofing) in der Vergangenheit ein weitaus grösseres Gefahrenpotential dieser Scriptsprache dar.

Böses Foul! Es gibt in JS keine Integer (nur 64bit-Floats) und die können auch nicht überlaufen, weil das bei jeder Rechenoperation extra geprüft wird. Wer den Wertebereich der Zahlen in JS sprengt, bekommt Number.POSITIVE_INFINITY oder Number.NEGATIVE_INFINITY.

Und Spoofing hat auch erstmal nichts mit JS (oder gar Events) zu tun. Klar, damit kann die Seite ein Fenster mit weniger Browser-Oberfläche aufmachen, um den Rest zu fälschen, aber gerade mit Flash (z.B. Vollbild) oder Java (z.B. Webstart) geht das mindestens genauso gut.

Dr.Evil fragte u.A. Folgendes:

Zitat

[...]Was hat JavaScript mit HTML5 zu tun? Das ist eine völlig andere Baustelle.[...]

Nein. JavaScript stellte bisher nur eine Ergänzung zum HTML-Kontext dar und konnte somit zur Laufzeit der Verarbeitung i.d.R. auch nur durch die einzelnen Web-Browser selber interpretiert werden. Damit erkläre ich Dir ganz bestimmt nichts Neues.

Die Konsolidierung (also Gleichstellung) der unterschiedlichen Interpretationsmöglichkeiten verschiedener Clients (Browser) würde jedoch durch die zentrale HTML5-Eigenschaft - z.B. durch die Definition eines einheitlichen und abwärtskompatiblen HTML-Parsers (im Zuge eines einheitlichen Sprachkonzeptes) – somit auch zu einer einheitlichen Richtlinienkompetenz führen können. (Ausschluss einer: „clientseitigen Interpretations-Fragmentierung“).

Dr.Evil stellte u.A. Folgendes dar:

Zitat

JavaScript hat eine Prototyp-basierte Vererbung statt einer Klassen-basierten.[...]

Nützt leider nichts, sofern die Terminologie der Sprache nicht eingeschränkt gehandhabt werden kann.
Klassen > Objekte. (Java / eingeschränkte Polymorphie).
Objekte = Objekte. (JavaScript / liberale Ausgestaltung).

Objekte sind – unter JavaScript – somit generell an keine Richtlinien gebunden. Objekte geben unter JS somit nur Initialwerte vor.

Dr.Evil stellte darüberhinaus u.A. Folgendes dar:

Zitat

[...]Böses Foul! Es gibt in JS keine Integer (nur „64bit“???-Floats) und die können auch nicht überlaufen, weil das bei jeder Rechenoperation extra geprüft wird.[...]

Du hast leider Recht. Ich verwechselte JS mit C. Ich hatte mich diesbezüglich geirrt.

Oliver

Zitat von Oliver222

JavaScript stellte bisher nur eine Ergänzung zum HTML-Kontext dar

Nun ja, das ist der Standard-Fall. Es gibt aber z.B. auch serverseitiges JavaScript, JavaScript-Shells, und nicht zu vergessen XULRunner-basierte Programme wie Firefox, die auch verdammt viel JavaScript völlig ohne HTML/XML verwenden. Aber zugegeben, das sind Spezialfälle und die Kombination mit HTML der Regelfall.

Zitat

Die Konsolidierung (also Gleichstellung) der unterschiedlichen Interpretationsmöglichkeiten verschiedener Clients (Browser) würde jedoch durch die zentrale HTML5-Eigenschaft - z.B. durch die Definition eines einheitlichen und abwärtskompatiblen HTML-Parsers (im Zuge eines einheitlichen Sprachkonzeptes) – somit auch zu einer einheitlichen Richtlinienkompetenz führen können. (Ausschluss einer: „clientseitigen Interpretations-Fragmentierung“).

In HTML5 wird unter anderem ziemlich genau definiert, wie ein HTML-Parser auszugucken hat. Mit JavaScript hat das rein gar nichts zu tun.

JavaScript wird schon seit Ewigkeiten bei der ECMA standardisiert ("ECMAScript"). (Wie bei HTML hält sich da aber bisher aus Kompatibilitätsgründen auch niemand zu 100% dran.)

Zitat

Nützt leider nichts, sofern die Terminologie der Sprache nicht eingeschränkt gehandhabt werden kann.
Klassen > Objekte. (Java / eingeschränkte Polymorphie).
Objekte = Objekte. (JavaScript / liberale Ausgestaltung).

Objekte sind – unter JavaScript – somit generell an keine Richtlinien gebunden. Objekte geben unter JS somit nur Initialwerte vor.

Ok - JavaScript ist nicht fest typisiert. Das ist doch mal was! Hat beides seine Vor- und Nachteile, aber wer Befürworter fest typisierter Sprachen ist, sieht darin natürlich einen Nachteil.