[gelöst]Schutz vor bösen Cookies

Alles rund um sicherheitsrelevante Fragen und Probleme.
Benutzeravatar
paul1234
Beiträge: 1927
Registriert: 28.06.2014 15:41:15

[gelöst]Schutz vor bösen Cookies

Beitrag von paul1234 » 27.09.2015 09:38:13

ich will hier nochmal das Thema aufgreifen, nachdem wir neulich speziell über das google.pref diskutiert haben: viewtopic.php?f=37&t=157250
Grundsätzlich habe ich im Iceweasel folgende Einstellung:
http://imgur.com/fTkaRPm - also alle Cookies werden nach Sitzungsende gelöscht.
Zusätzlich habe ich noch Coockiecontroler am Start
und da hab ich jetzt diesen Beitrag gefunden:
http://www.golem.de/news/security-cooki ... 16504.html speziell interessiert mich dieser Auszug:
Cookies sind verwundbar, weil sie nicht in jedem Fall eine Identitätsprüfung vornehmen, etwa bei Geschwister-Domains. Angreifer können also Webnutzern, die über eine unverschlüsselte Verbindung surfen, ein gefälschtes Cookie unterschieben, das später eine verschlüsselte Verbindung der gleichen Domain angreift.
Denkbar ist, dass ein Angreifer bei einer Kommunikation mit einer unverschlüsselten Subdomain, etwa foo.beispiel.com, ein Cookie mit dem Domain-Attribut beispiel.com setzt. Eine spätere Verbindung mit der Seite bar.beispiel.com könnte Angreifern dann über das manipulierte Cookie vertrauliche Nutzerdaten preisgeben, wenn Schwachstellen der Serverkonfiguration ausgenutzt werden.
meinen die Server im Sinne von Netzwerkservern, dh. ich mit meinen 2 Einzelplatzanwendungen im Homenet hinter ner Fritzbox brauch mir keine Sorgen machen?
welche Schwachstellen bei einer Serveranwendung sind da gemeint?
Zuletzt geändert von paul1234 am 20.10.2015 06:37:42, insgesamt 2-mal geändert.
HP 250 G8 SP 2W8X8EA debian bullseye XFCE4 4.16

wanne
Moderator
Beiträge: 7664
Registriert: 24.05.2010 12:39:42

Re: Schutz vor bösen Coockies

Beitrag von wanne » 27.09.2015 20:38:44

Das sind ne ganze Reihe von Angriffen. Das Grundliegend Problem ist wie immer die Existenz von HTTP. Und der Idee, dass das ohne probleme mit HTTPS zusammen spielen können soll.
Wir hatten das Thema auch schon hier im Debianforum.

Hier mal eine Erklärung. (Habe das Paper nur überflogen. Man verbessere mich, wenn ich etwas falsches schreibe.)
Wenn man die Cookies hat, ist man meist Herr über den Account. Cookies klauen ist deswegen schon lange so der Klassische Angriffsvektor.
Läuft das ganze jetzt über https ist erstmal Schluss. Man kann die Cookies weder Lesen noch verändern.
Die alt bekannte Variante dazu ist, jemanden von einer HTTPS Seite auf eine HTTP seite zu locken.
Anbieten würde sich hier z.B. http://wiki.debianforum.de . Klinkt jemand der im Debianforum angemeltet ist auf diesen Link, bekommt man, da das eine Subdomain ist, das cookie nun auch über die unverschlüsselte Verbindung und kann nun im Namen eines anderen Users posten.
Man kann jetzt wie feltel sagen, ist ein Problem des Users, darf halt keine http-Links anklicken, die auf debianforum.de enden. Hält man das ein ist man weiterhin sicher.

Seriösere Seiten, weisen den Browser allerdings an die Cookies einfach nicht über http Zugriffe herauszugeben. Das ist besonders dann wichtig, wenn einige teile gar nicht über https erreichbar sind. Bei ebay oder amazon hat man ein cookie um den Einkaufskorb zu füllen und kommt auch gar nicht mit https auf die eigentlichen Einkaufsseiten. Am Ende bekommt man ein anderes für den Bezahlvorgang, der dann abgesichert ist.
Die Idee hinter den Angriffen ist es jetzt stattdessen schon vorher über http ein ungesichertes Cookie für den Bezahlvorgang zu setzen. Schluckt der Server das, oder ändert es nur ab kennt der Angreifer, das Cookie und kann auch beim Bezahlvorgang schmu treiben.
Das funktioniert aber eben nur unter der Bedingung, dass
a) Irgend wo über http auf eine Seite der gleichen Domain zugegriffen wird.
b) Der Server nicht merkt, dass ihm da ein faules cookie untergejubelt wird. Stellt der Server fest, dass das Cookie faul ist. (Sprich nicht von ihm gesetzt wurde.) kann er den Angriff in's leere laufen lassen.

Ich bin deswegen eigentlich schon immer der Meinung das Cookies auf http-Verbindungen nichts zu suchen haben. Das wegzufiltern ist eigentlich von je her eine saubere Sache. Sind in 90% der Fälle sowieso nur zur Werbeoptimierung. Leider bricht das eben auch Amazon, Ebay und die meisten anderen Onlinestores, die sich relativ wehement weigern flächendeckend https einzusetzern.
rot: Moderator wanne spricht, default: User wanne spricht.

Benutzeravatar
paul1234
Beiträge: 1927
Registriert: 28.06.2014 15:41:15

Re: Schutz vor bösen Coockies

Beitrag von paul1234 » 27.09.2015 20:42:50

danke wanne, das war sehr informativ u. hilfreich!
HP 250 G8 SP 2W8X8EA debian bullseye XFCE4 4.16

wanne
Moderator
Beiträge: 7664
Registriert: 24.05.2010 12:39:42

Re: Schutz vor bösen Coockies

Beitrag von wanne » 27.09.2015 21:08:40

Weiterer Angriff ist, wohl, dass ein https-Proxy Cookies setzen kann. Ist jetzt für nicht Proxy user nicht so interessant.
Und natürlich XSS. Aber XSS ist ja ein alt bekanntes Problem. Das das jetzt auch mit cookies geht ist nicht weiter verwunderlich.
rot: Moderator wanne spricht, default: User wanne spricht.

debiator
Beiträge: 268
Registriert: 04.10.2015 20:25:21

Re: Schutz vor bösen Coockies

Beitrag von debiator » 04.10.2015 21:08:43

Sehr interessant, danke für die Info!

Ist es aber nicht so, dass man dem Browser nicht sagen kann: "nimm keine Cookies aus http-Verbindungen, sondern nur https"?

Der CookieController hat ja eine Eigenschaft "Cookies nur als aufrufende Seite erlauben" (z.B. bei debianforum.de).
Was ist damit eigentlich genau gemeint?

wanne
Moderator
Beiträge: 7664
Registriert: 24.05.2010 12:39:42

Re: Schutz vor bösen Coockies

Beitrag von wanne » 04.10.2015 21:56:26

debiator hat geschrieben:Ist es aber nicht so, dass man dem Browser nicht sagen kann: "nimm keine Cookies aus http-Verbindungen, sondern nur https"?
Bei den großen Browsern nicht wirklich. IE oder Konqueror kann man fragen lassen. Das ist das Problem. Liegt vor allem daran, dass Cookies älter sind als https. Und da will halt keiner was kaputt machen, indem er die Abwärtskompatibilität bricht. Der Proxy Squid kann dass. Aber Sowohl auf Server Seite wie auch auf Clientseite findet sich da mehr oder minder nichts. Nur überhaupt keine Inhalte von http annehmen implementieren einige Browser oder plugins.
rot: Moderator wanne spricht, default: User wanne spricht.

debiator
Beiträge: 268
Registriert: 04.10.2015 20:25:21

Re: Schutz vor bösen Coockies

Beitrag von debiator » 04.10.2015 22:29:19

IE und Konqueror können zwischen http- und https-Cookies entscheiden??

Was ist wenn man in about:config von Firefox

security.mixed_content.block_display_content
security.mixed_content.block_active_content

auf true setzt?

gilt es dann auch für die Cookies?
Dann wäre http zumindest halbwegs sauber von https getrennt.

wanne
Moderator
Beiträge: 7664
Registriert: 24.05.2010 12:39:42

Re: Schutz vor bösen Coockies

Beitrag von wanne » 04.10.2015 22:48:20

debiator hat geschrieben:IE und Konqueror können zwischen http- und https-Cookies entscheiden??
Unterscheiden kann jeder Browser. Das Problem ist, dass http cookies auch auf https funktionieren. Nur der Umgekehrte weg ist blockiert. Bei IE und Konqueror kannst du halt jedes mal nachfragen lassen. Und dann von Hand ablhen was http ist. Eigentlich will man da ein Plugin für. Habe sowas aber noch nicht gefunden. Und wie gesagt, es gibt massenhaft Seiten, die von dem Mechanismus gebrauch machen. Amazon und auch das Debian-Forum nutzen schlicht http-Cookies für alle Verbindungen. Schaltet man das ab, tut das halbe Internet nicht mehr. Auf Anhieb fällt mir nur die DiBa ein, die wirklich nur HTTPS-Cookies verwendet.
Alle anderen verlassen sich auf den funktionierenden Mischbetrieb.
Das ist halt das Problem, wenn man sicherheitstechnisch grenzwertige Funktionen einbaut. Die bekommt man nicht mehr los. Baut irgend jemand das aus, laufen ihm die Nutzer davon, weil sachen nicht mehr funktionieren, die sonst überall wunderbar tun. Und überhaupt: Never change a running system...
debiator hat geschrieben:Was ist wenn man in about:config von Firefox

security.mixed_content.block_display_content
security.mixed_content.block_active_content

auf true setzt?

gilt es dann auch für die Cookies?
Nein. Es geht dabei um Webseiten, die sowohl http wie auch https Inhalte enthalten. (Z.B. Die Seite ist in https aber die Bilder/Videos/Scripte sind in http. Ziemlich dämlich aber weit verbreitet.) Cookies bleiben aber. Es reichen also zwei völlig getrennte Webseiten. Eine mit http und eine mit https.
rot: Moderator wanne spricht, default: User wanne spricht.

debiator
Beiträge: 268
Registriert: 04.10.2015 20:25:21

Re: Schutz vor bösen Coockies

Beitrag von debiator » 04.10.2015 22:57:38

na mit dieser about:config Einstellung kann man ja gemischte Inhalte blocken, was natürlich die Usabilität der Seiten deutlich einschränkt und an sich gar nicht durchführbar ist, weil, wie Du sagst, zu viele Seiten Inhalte mischen. Aber dann haben die Cookies damit nichts zu tun... eine ganz schön verzwickte Sache.

Deswegen sollte man wenigstens fürs Banking eine HBCI-Software wie Hibiscus nutzen. Dann hat man den Salat mit den Cookies nicht mehr.

Benutzeravatar
Blackbox
Beiträge: 4289
Registriert: 17.09.2008 17:01:20
Lizenz eigener Beiträge: GNU Free Documentation License

Re: Schutz vor bösen Coockies

Beitrag von Blackbox » 04.10.2015 23:43:34

Hallo,

die kommende Firefox Version 42 soll einen besseren Trackingschutz im privaten Modus erhalten.
Eine News dazu, wurde vor ein paar Tagen bei Pro-Linux veröffentlicht: http://www.pro-linux.de/-0h215905.
Wann diese allerdings in Debian einfließt weiß ich nicht, da ich nur Debianmidori und Debianchromium verwende.
Eigenbau PC: Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Desktop PC: Dell Inspiron 530 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Notebook: TUXEDO BU1406 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Alles Minimalinstallationen und ohne sudo/PA/PW.
Rootserver: Rocky Linux 9.3 - Kernel: 5.14

Freie Software unterstützen, Grundrechte stärken!

debiator
Beiträge: 268
Registriert: 04.10.2015 20:25:21

Re: Schutz vor bösen Coockies

Beitrag von debiator » 04.10.2015 23:48:10

ich weiss ja nicht... es ist so unglaublich viel Müll in Firefox (auch Iceweasel), was dem Tracking dient, da ist mit die Einstellung per about:config sicherer und eindeutiger.

Benutzeravatar
paul1234
Beiträge: 1927
Registriert: 28.06.2014 15:41:15

Re: Schutz vor bösen Coockies

Beitrag von paul1234 » 06.10.2015 08:58:48

debiator hat geschrieben:ich weiss ja nicht... es ist so unglaublich viel Müll in Firefox (auch Iceweasel), was dem Tracking dient, da ist mit die Einstellung per about:config sicherer und eindeutiger.
und welche Einstellungen hast du da gesetzt? Oder hast du einen Link zum Thema?
HP 250 G8 SP 2W8X8EA debian bullseye XFCE4 4.16

uname
Beiträge: 12539
Registriert: 03.06.2008 09:33:02

Re: Schutz vor bösen Coockies

Beitrag von uname » 06.10.2015 10:25:28

Die Sicherheitseinstellungen wirken wie die Einträge in about:config . Dort kann man jedoch noch mehr angeben wie z.B. den Verzicht auf einen Disk-Cache.

Ich lasse kein Drittanbieter-Cookies zu, lösche alle Cookies beim Beenden, speichere nie Passwörter, lasse die Chronik beim Beenden löschen und cache nur im RAM.
Und falls alles nicht greift liegt natürlich ~/.mozilla bei mir auf der Ramdisk, wodurch spätestens beim Neustart sämtliche Iceweasel-Strukturen neu angelegt werden müssen.
Iceweasel konfiguriere ich natürlich über /etc/iceweasel/pref/iceweasel.js . Unter ~/.mozilla macht das ja wenig Sinn bei einer Ramdisk ;-)

debiator
Beiträge: 268
Registriert: 04.10.2015 20:25:21

Re: Schutz vor bösen Coockies

Beitrag von debiator » 06.10.2015 18:26:56

Die Einstellungen sind relativ umfangreich, aber wenn Du Nerven und Zeit hast... probiere sie aus.
Aber bitte bei mir dann keine Beschwerden, dass etwas nicht funktioniert.
Man sollte wenigstens so ganz grob wissen, was man da tut.
Aber Vieles ist von sich aus nachvollziehbar.

Viel Spaß! :D

Hier ist die Einstellung der about:config --> http://nopaste.debianforum.de/38861

ansonsten wie uname bereits geschrieben hat. Ja keine Passwörter speichern. Für Passwörter KeyPassX verwenden. Die Cookies mit Addon CookieController verwalten und NUR manuell nicht automatisch annehmen. Und ansonsten auch ein paar Addonns (nur open source. Das sieht man auf der jeweiligen Addon-Seite unten) installieren:

uBlock Origin – blockiert nervige Werbung und Tracker, die das Surfverhalten speichern.

No Script (iFrames unter Einstellungen verbieten) – Skripte wie JavaScript, die sehr für schädliche Manipulationen bekannt sind, kann man mit dieser Erweiterung manuell erlauben. Damit die meisten Webseiten funktionieren, brauchen sie Skripte, allerdings brauchen sie lang nicht alle Skripte, die geladen werden. Am Anfang ist es etwas nervig, bei den jeweiligen Webseiten die Skripte zu erlauben, damit sie funktionieren. Da man aber oft wiederkehrende Seiten benutzt, kann man die Einstellungen für diese Seiten dauerhaft erlauben (und nicht temporär).

RequestPolicy – verhindert unkontrollierte und unbemerkte Weiterleitungen an andere Webseiten. Manchmal ist dies notwendig (z.B. für Webspace-Cloud-Server oder Subdomains der jeweiligen Seiten) doch oft geht es um Werbung und Tracking. Es verhält sich ähnlich wie mit NoScript. Man kann auf den bekannten Seiten die jeweiligen Erlaubnisse dauerhaft speichern.

DNSSEC/TLSA Validator – prüft Zertifikate der verschlüsselten Webseiten.

FB Phishing Protector – schützt vor Scriptattacken auf Facebook und blockiert Facebookskripte auf anderen Seiten, die das Surfverhalten schnüffeln.

Facebook Disconnect – blockt ebenfalls das Facebook-Tracking über die Seiten hinweg. Es ist unklar, ob es zu dem vorigen Addon installiert werden muss, aber es schadet nicht.

Random Agent Spoofer – gibt einem die Möglichkeit eine andere Identität des Browsers und einige andere Einstellungen vorzutäuschen. Bedenken Sie, dass mit manchen vorgetäuschten Browsern manche Seiten nicht so funktionieren werden, wie Sie es sollen. Dazu müsste man in den Einstellungen lediglich die aktuellen Browser und Betriebssysteme lassen und die anderen deaktivieren (abhacken).

Cookie Controller – damit kann man die Cookies deutlich besser verwalten (manuell erlauben).

Canvas Blocker – blockt eine cookie-ähnliche Tracking-Taktik.

Better Privacy – löscht Flash-Cookies, es scheint aber nicht open source zu sein, was nichts Schlimmes bedeuten muss, die Vertrauenswürdigkeit sinkt dadurch allerdings etwas. Es ist keine öffentliche Kritik bekannt.

Easy Youtube Video Downloader Express – erlaubt es einem, Videos von den Webseiten herunter zu laden.

Modify Headers – ist für fortgeschrittene Benutzer und ist leider nicht open source. Es erlaubt einem, dem jeweiligen Webserver eine IP-Adresse vorzutäuschen, die hinter der eigenen IP vom Provider steht. Somit denkt der Webserver man ist ein Proxy und leitet die angegebene IP nur weiter (X-forwarded-for). Manchmal kann man damit die eigene Herkunft für Videostreams vortäuschen. Ist aber nicht zu verwechseln mit dem Vortäuschen einer IP-Identität durch die Benutzung eines anonymen Proxy-Servers!

uMatrix – ist für fortgeschrittene Benutzer und nicht unbedingt notwenig. Man kann damit zusätzlich sehr feine Einstellungen für Skripte, Cookies und andere Inhalte vornehmen.


ALLERDINGS(!) bedenke, dass Du für die jeweiligen Seiten manuell Dinge erlauben musst, damit die Seiten funktionieren. Nicht überall, aber bei NoScript, Request Policy, CookieController und manchmal musste Du manche Addonns deaktivieren, damit eine Seite geht. Man muss sich eben damit einwenig beschäftigen. Ist aber halb so wild.

debiator
Beiträge: 268
Registriert: 04.10.2015 20:25:21

Re: Schutz vor bösen Coockies

Beitrag von debiator » 06.10.2015 18:39:45

Noch ein kleiner Zusatz:

Flash (adobe, shockwave) sollte man nur bei Bedarf (Surfen nach Videos) unter Addons/Plugins einschalten und danach wieder deaktivieren, da dieses Programm Inhalte auf der Festplatte zwischenspeichert und somit einen schädlichen Code einschleusen kann. Vor allem auf zwielichtigen Webseiten oder beim wilden Herumsurfen sollte Flash deaktiviert sein. Viele Videos werden auch ohne Flash über HTML5 (Webgestaltungs-Programmiersprache) laufen, z.B. bei Youtube. Pornoseiten sind übrigens voll von Schadcodes, weil sie alle mit Flash laufen ;-)

Wie bereits geschrieben. Unter Einstellungen – Privatsphäre den „privaten Modus“ aktivieren und die automatische Speicherung von Cookies deaktivieren. Das Addon Cookie Controller hat ein Symbol in der oberen Browser-Leiste (ansonsten mit Rechtsklick/Anpassen das Symbol hinzufpügen), mit dem man die jeweiligen Cookies auf der Seite speichern kann (bei den Seiten mit Zugangsdaten ist es meist notwendig). Unter Sicherheit aktiviert man „warnen wenn Seiten addons installieren wollen“. Unter Erweitert - Netzwerk stellt man den Cache auf 0 und aktiviert „Cache automatisch überschreiben“. Das untere Kästchen „sagt Bescheid, wenn eine Seite versucht offline-Inhalte zu speichern“ muss aktiviert sein. Unter Inhalt – Erweitert deaktiviert man das Kästchen „den Seiten erlauben eigene Schriftarten zu laden“. Das lässt manche Seite nicht so hübsch aussehen, gibt aber dafür einen Schub an Sicherheit, da durch das Nachladen der Schriften Schadprogramme auf die Festplatte geladen werden können. Unter Erweitert – Zertifikate das unnötige und bereits geknackte, aber für das Tracking des Surfverhaltens zu nutzende OCSP ausschalten. Manches ist davon bereits durch das konfigurierte about:config geklärt... aber doppelt hält besser.

Wenn eine Seite nicht funktioniert (keine Bilder anzeigt oder manche andere Inhalte nicht lädt, liegt es höchstwahrscheinlich an einem Addon bzw. den Einstellungen darin. Man kann nach und nach alle Addons deaktivieren und so den „Übeltäter“ herausfinden, dann passt man die Einstellungen bei diesem Addon an. Im schlimmsten Fall startet man Firefox mit deaktivierten Addons im „Safe mode“, was nur bei vertrauenswürdigen Seiten sinnvoll ist.

seeker
Beiträge: 34
Registriert: 06.10.2015 15:49:48

Re: Schutz vor bösen Coockies

Beitrag von seeker » 06.10.2015 18:59:31

debiator hat geschrieben: Hier ist die Einstellung der about:config --> http://nopaste.debianforum.de/38861
Danke, nützliche Liste! Eine sehr umfangreiche Liste gibt es auch auf ghacks.net, die den Vorteil hat, dass sie sich bequem als user.js abspeichern lässt.
uBlock Origin – blockiert nervige Werbung und Tracker, die das Surfverhalten speichern.

No Script

RequestPolicy
Die beiden letzten braucht man nicht, da sich dasselbe mit den Dynamischen Filtern von uBlock0 erzielen lässt. Siehe auch die verschiedenen Blocking modes.
FB Phishing Protector – schützt vor Scriptattacken auf Facebook und blockiert Facebookskripte auf anderen Seiten, die das Surfverhalten schnüffeln.

Facebook Disconnect – blockt ebenfalls das Facebook-Tracking über die Seiten hinweg. Es ist unklar, ob es zu dem vorigen Addon installiert werden muss, aber es schadet nicht.
Braucht man ebenfalls nicht, weil auch dies mit uBlock Origin zu machen ist, indem man Facebook global blockt und nur im Rahmen einer lokalen Regel erlaubt.
Random Agent Spoofer – gibt einem die Möglichkeit eine andere Identität des Browsers und einige andere Einstellungen vorzutäuschen. Bedenken Sie, dass mit manchen vorgetäuschten Browsern manche Seiten nicht so funktionieren werden, wie Sie es sollen. Dazu müsste man in den Einstellungen lediglich die aktuellen Browser und Betriebssysteme lassen und die anderen deaktivieren (abhacken).

Cookie Controller – damit kann man die Cookies deutlich besser verwalten (manuell erlauben).

Canvas Blocker – blockt eine cookie-ähnliche Tracking-Taktik.

uMatrix – ist für fortgeschrittene Benutzer und nicht unbedingt notwenig. Man kann damit zusätzlich sehr feine Einstellungen für Skripte, Cookies und andere Inhalte vornehmen.
Die ersten drei braucht man nicht mit uMatrix, da dieses das auch (optional) bietet. Deutlich besser als Noscript und die optimale Ergänzung zu uBlock Origin vom selben Autor. Wenn man beide zusammen benutzt, sollte man allerdings das Dynamische Filtern in uBlock Origin abstellen und uMatrix überlassen. Außerdem sollte man die hosts-Dateien in uBlock deaktivieren, die auch schon in uMatrix enthalten sind.

debiator
Beiträge: 268
Registriert: 04.10.2015 20:25:21

Re: Schutz vor bösen Coockies

Beitrag von debiator » 06.10.2015 19:29:36

ich würde es einem nicht raten, die js.Datei einfach nur reinzukopieren. Da weiss man dann nicht, was passiert ist. So lernt man einwenig etwas über den Stand und die Bedeutung des Browsers.

ja, bei uMatrix braucht man viel nicht... aber uMatrix muss einer auch verstehen... ich kann es... ein Anfänger würde da absolut nichts durchblicken.

das mit dem Facebook, da haste wahrscheinlich Recht. Ich habe es nicht gegenseitig gecheckt, aber zu vermuten wäre es. Allerdings muss man bedenken, dass uBlock Origin deutlich komlizierter ist als so ein NoScript oder Facebook-Blocker. Es schreckt manche ab, kann ich mir vorstellen.

ich werd mich mal mehr mit uBlock Origin beschäftigen... es scheint wirklich Vieles zu ersetzen. Obwohl ich nicht feststellen kann, dass die anderen Addons mein IW sonderlich langsamer machen. Aber weniger Code ist mehr.

seeker
Beiträge: 34
Registriert: 06.10.2015 15:49:48

Re: Schutz vor bösen Coockies

Beitrag von seeker » 06.10.2015 19:45:35

debiator hat geschrieben:ich würde es einem nicht raten, die js.Datei einfach nur reinzukopieren. Da weiss man dann nicht, was passiert ist. So lernt man einwenig etwas über den Stand und die Bedeutung des Browsers.
Ja, das ist schon richtig. Die einzelnen Einstellungen muss man sich auf jeden Fall genau anschauen. Der Vorteil einer user.js ist aber, dass die Modifikationen übersichtlich zusammen gefasst sind und sich bei Neuaufsetzen eines Systems oder beim Systemwechsel leicht mitnehmen lassen.
ja, bei uMatrix braucht man viel nicht... aber uMatrix muss einer auch verstehen... ich kann es... ein Anfänger würde da absolut nichts durchblicken.

das mit dem Facebook, da haste wahrscheinlich Recht. Ich habe es nicht gegenseitig gecheckt, aber zu vermuten wäre es. Allerdings muss man bedenken, dass uBlock Origin deutlich komlizierter ist als so ein NoScript oder Facebook-Blocker. Es schreckt manche ab, kann ich mir vorstellen.
Man muss schon in die Dokumentation reinschauen. Dafür ist es aber auch nur eine Erweiterung und nicht gleich mehrere. :wink: Das hat übrigens auch Vorteile, was das sog. Fingerprinting angeht: Je mehr Erweiterungen man benutzt, umso einzigartiger und damit wiedererkennbarer wird der Browser.
Übrigens lässt sich das mit Facebook natürlich auch in uMatrix machen: Einfach im Globalen Geltungsbereich auf die Blacklist setzen und nur im Domain-spezifischen Geltungsbereich (den man eh standardmäßig benutzen sollte) erlauben. So wird ein Tracking völlig unmöglich.
ich werd mich mal mehr mit uBlock Origin beschäftigen... es scheint wirklich Vieles zu ersetzen.
Lohnt sich. Musste mich mit uBlock0 und uMatrix zwangsläufig genauer beschäftigen, da ich für beide die deutsche Übersetzung besorgt habe.

Radfahrer

Re: Schutz vor bösen Coockies

Beitrag von Radfahrer » 06.10.2015 19:49:14

Nur mal nebenbei:
Kann nicht mal der TE oder ein Mod den Fehler im Threadtitel korrigieren?

debiator
Beiträge: 268
Registriert: 04.10.2015 20:25:21

Re: Schutz vor bösen Coockies

Beitrag von debiator » 06.10.2015 19:50:36

seltsamerweise zeigt bei mir uBlockO Hyroglyphen bei den Einstellungsbuttons... uMatrix auch. Kann noch nichts nachvollziehen an was es liegt. Vielleicht an der about:config :D

Ja... das mit Fingerprint habe ich glatt vergessen.... ich les mal durch :)


Coockies ist natürlich ziemlich weird :D

wanne
Moderator
Beiträge: 7664
Registriert: 24.05.2010 12:39:42

Re: Schutz vor bösen Coockies

Beitrag von wanne » 06.10.2015 20:15:48

So als Anmerkung fast alle der Genannten plugins sind völlig nutzlos gegen den Angriff. Weil sie eben nicht zwischen http://debianforum.de und https://debianforum.de unterscheiden. Wie der Browser selbst. Ja ganz nett. Aber es hat eben absolut nichts mit dem genannten Problem zu tun.
rot: Moderator wanne spricht, default: User wanne spricht.

debiator
Beiträge: 268
Registriert: 04.10.2015 20:25:21

Re: Schutz vor bösen Coockies

Beitrag von debiator » 06.10.2015 20:21:34

wanne hat geschrieben:So als Anmerkung fast alle der Genannten plugins sind völlig nutzlos gegen den Angriff. Weil sie eben nicht zwischen http://debianforum.de und https://debianforum.de unterscheiden. Wie der Browser selbst. Ja ganz nett. Aber es hat eben absolut nichts mit dem genannten Problem zu tun.
das ist ganz richtig.
Die Plugins und about:config sollten eher zusätzlich zu einem besser konfigurierten Firefox führen.
Gegen "böse Cookies" hilft es nichts.

debiator
Beiträge: 268
Registriert: 04.10.2015 20:25:21

Re: Schutz vor bösen Coockies

Beitrag von debiator » 06.10.2015 20:31:53

Update:

Hyroglyphen vom uBlockO kommen wegen dem EIntrag von about:config

Code: Alles auswählen

gfx.downloadable_fonts.enabled
setzt man ihn auf false, was schlauer wäre, da ansonsten Schriften aus dem Internet nachgeladen werden, zeigt er nur seltsame Zeichen an... also muss es auf true bleiben, was mir gar nicht gefällt.
seeker hat geschrieben:Lohnt sich. Musste mich mit uBlock0 und uMatrix zwangsläufig genauer beschäftigen, da ich für beide die deutsche Übersetzung besorgt habe.
hast Du da zum Programmierer Kontakt und kannst diesen Kritikpunkt ansprechen? Der könnte doch die Fonts fest einbinden.

Benutzeravatar
paul1234
Beiträge: 1927
Registriert: 28.06.2014 15:41:15

Re: Schutz vor bösen Cookies

Beitrag von paul1234 » 07.10.2015 10:19:25

ui, das war ja jede Menge wichtige Infos. Ein Teil davon hatte ich schon umgesetzt. Das von wanne angesprochene muß ich noch weiter vertiefen, trotzdem aber erstmal bis hierhin Danke!
Bild
HP 250 G8 SP 2W8X8EA debian bullseye XFCE4 4.16

seeker
Beiträge: 34
Registriert: 06.10.2015 15:49:48

Re: Schutz vor bösen Coockies

Beitrag von seeker » 07.10.2015 12:20:10

debiator hat geschrieben: Hyroglyphen vom uBlockO kommen wegen dem EIntrag von about:config

Code: Alles auswählen

gfx.downloadable_fonts.enabled
setzt man ihn auf false, was schlauer wäre, da ansonsten Schriften aus dem Internet nachgeladen werden, zeigt er nur seltsame Zeichen an... also muss es auf true bleiben, was mir gar nicht gefällt.
Das Problem ist bereits bekannt. Dort wird auch eine Lösung genannt.

Antworten