Ganz einfach, hätte ich fast gesagt - nämlich einmal über die Eingabe von:
Okay, also tatsächlich so kompliziert, wie ich es mir über die Konsole vorgestellt hatte. Der „normale” Weg, solche Optionen zu verändern, wäre about:config. Dort kann einfach per Doppelklick auf die entsprechende Zeile zwischen aktiviert und deaktiviert gewechselt werden.
undefined ist zwar etwas seltsam
Die Konsole gibt immer den Rückgabewert aus. Die „Rückgabe” wird auch durch das Pfeil-Symbol nach links symbolisiert. Und die Funktion setBoolPref() hat keinen Rückgabewert. Demnach ist undefined das erwartete Ergebnis.
Was den besagten Bedarf angeht, pflege ich Javascript - eigentlich - immer nur bei Vorliegen zweier Voraussetzungen einzuschalten
Ich vermute mal, dass das auf der völlig veralteten Denkweise beruht, dass JavaScript etwas Schlechtes sei. In den Anfangszeiten des Internets war das eine verbreitete Sichtweise. Heute ist das freundlich ausgedrückt ein Mythos. JavaScript ist ein wesentlicher Bestandteil der Webplattform, der auf einer Stufe mit CSS und Bildern steht.
Wie richtig das tatsächlich ist, musste ich Anfang Januar erkennen
Deine Schlussfolgerung ist falsch. Ja, über JavaScript können Sicherheits-Thematiken entstehen. Es gab aber auch schon Sicherheitslücken in CSS und in den Bild-Dekodern. Und ich vermute mal stark, CSS und Bilder schaltest du auch nicht nur bei Bedarf ein. Wie kommst du also zur Annahme, dass JavaScript Schuld an deinem Befall war? Folgendes kann es jedenfalls nicht sein:
aber nach Aufruf eines neuen Suchergebnisses i. S. Programmierung fand ich mich unversehens auf eine iranische & Sekundenbruchteile später auf eine kasachische Webseite weitergeleitet
Weiterleitungen können auch via HTML oder sogar serverseitig erfolgen. Weiterleitungen sind nicht zwingend auf JavaScript zurückzuführen.
immer nur bei Vorliegen zweier Voraussetzungen einzuschalten, nämlich dass: […] 2. Ich der jeweiligen Seite über den Weg traue
In der Theorie gut gedacht. In der Praxis werden es Angreifer aber auch auf die vermeintlich vertrauenswürdigen Websites absehen, um diese zu kompromittieren. Das siehst du als Nutzer nicht. Dadurch kann die Gefahr dort sogar größer sein, weil du der Seite ja vertraust und deswegen mit ihr interagierst, während du eine offensichtlich uneriöse Website vermutlich sofort schließst. Insofern würde ich die eigene Beurteilung der Website als Beurteilungskriterium nicht zu hoch bewerten.
Bezogen auf die Angriffssituation selber ist sicherlich klar, dass man da jetzt nichts mehr aus dem Log herauslesen kann. Das abzuspeichern hatte ich nicht unmittelbar auf dem Schirm
Selbst, wenn du auf dem Schirm gehabt hättest: Wenn die Konsole zum betroffenen Zeitpunkt nicht bereits geöffnet war, hätte es dir nichts gebracht. Du erhältst in der Konsole keine Meldungen rückwirkend. Und auch dann wäre es immer noch höchst zweifelhaft, dass in der Konsole irgendetwas gestanden hätte, was für dein Anliegen relevant ist.
Was ich mir bzgl Konsole aber sehr wohl denke ist, wohlgemerkt unterstellt da könnte auch was rootkit-mäßiges auf der Kiste gelandet sein - dass man den Meldungen schon etwas müsste entnehmen können, wenn es als ggw. Wirken auf Grundlage evtl. payloads bspw. verdeckte, meinetwegen auf Cross-Site-Basis oder was immer sonst beruhende Fremd-Server-Kontakte etc., ge- oder mißglückte heimliche Skriptausführungen usw. usf. gäbe.
Zunächst einmal würde die Konsole nur Meldungen der Website ausgeben, nicht von irgendwelchen Rootkits auf deinem System. Als nächstes wäre festzuhalten, dass die Browser-Konsole keine „Fremd-Server-Kontakte” loggt, dafür gibt es andere Werkzeuge. Gleiches gilt für sogenannte Payloads von Anfragen. Und „mißglückte heimliche Skriptausführungen” (sic!) sind für dein Problem nicht entscheidend. Wenn überhaupt, wären es die geglückten. Und die geben in der Browser-Konsole nichts aus.
Mal abgesehen davon, dass ich nicht verstehe, was das für ein „Bedarf” sein soll.
