Beiträge von boardraider

unix_samurai wrote:

Zitat

Es gibt nur ein Programm namens Privoxy und ja, es ist weit aus mehr. Aber dennoch als Cookiemanager nutzbar. Ich erkenne hier keinen Fehler in meiner Aussage.

Ich wollte an der Stelle keinen Fehler aufzeigen, nur für Klarheit sorgen. Privoxy als Cookiemanager zu bezeichnen ist absolut ungewöhnlich und daher die Irritation. Hätte sein können, dass du von einem Addon sprichst, dass bisher unbekannt ist.

Zitat

cross site request forgery.

Du schriebst im ersten Beitrag:

Zitat

CC behandelt Cookies erst, nachdem sie bereits auf dem PC befindlich sind was bedeutet, dass sämtliche Attacken bereits auf einen User ausgeführt werden können.

CSRF Angriffe machen sich eine vorhandene Session zu Nutze (daher auch die Bezeichnung session riding). Wenn die Session über Cookies gehalten werden dann müssen die Cookies gezwungenermaßen am Client zwischengespeichert werden. Ein Cookiemanager steuert i.d.R. welche Seiten Cookies setzen dürfen, er definiert nicht, ob der Client im Kontext einer Seite automatisch Authentifizierungsinformationen an andere Seiten senden darf.
Wie soll Privoxy denn feststellen, welche Requests potentielle CSRF-Angriffe sind und dort bspw. die Cookies entfernen? Ich stecke nicht so tief drin in Privoxy, mir wäre aber neu, dass Privoxy Anti-CSRF-Maßnahmen anbietet. Dazu müsste Privoxy wohl vorgehen wie Request Rodeo.
Wenn Privoxy also Cookies blockiert, dann verhindert der Proxy auch den regulären Login. Umgekehrt - lässt Privoxy Cookies durch, dann bietet Privoxy auch keinen clientseitigen Schutz gegen CSRF.

Zitat

Ich denke, der Sinn sollte nun klar sein.

Klarer ja. Aber wie genau gehst du dabei vor? Hast du mal ein konkretes Konfigurationsbeispiel?

Wenn man verschiedene Profile nutzt, waren solche Erweiterungen schon immer völlig unnötig.

Im "Öffnen-Formular" spielt das target-Attribut keine Rolle, da du das Formular nie abschickst. Das wäre auch kein JS, soweit korrekt.
Aber du verwendest einen onclick-Handler für den Button, der window.open aufruft und das ist JS.

Wenn der aus dem PCWelt-Forum also behauptet das sei eine Lösung ohne JS, dann schreibt er Blödsinn. Du kannst es aber auch einfach selbst testen. Deaktiviere im Fx JS und teste deinen Code. Nur die Google-Suche wird so funktionieren.

Nachtrag:
Thread
Da er nicht behauptet es sein kein JS nehme ich natürlich den "Blödsinn" zurück.

Ja korrekt, alternativ natürlich auch hinten mit Zeit. Irgendwie meinte ich wohl beides, daher das Kuddelmuddel. Danke für den Hinweis

Ich nutze deinen Editor nicht, daher kann ich dir nicht sagen, wo du darin den Code entsprechend ändern musst. Grundsätzlich solltest du die font-size Angaben ändern.
Ansonsten empfehle ich dir dich etwas mehr mit HTML usw. zu beschäftigen, damit du auf solche Generatoren verzichten kannst. Der Code, den diese Generatoren erzeugen ist oft genug in solcher Hinsicht problematisch.

JetGum wrote:

Zitat

natürlich sitze im Normalfall nur ich im am Rechner, deswegen stört mich selbst das Eingeben des Master passworts nach jedem Start von Fx... Und das möchte ich unterbinden...

Entweder Abfrage oder Masterpasswort deaktivieren. Ohne eine Erweiterung geht das nicht anders. Mir wäre aber keine Erweiterung ad hoc bekannt, die das Masterpasswort einträgt. Dazu müsste die Erweiterung das Passwort irgendwo her haben und dort wäre es dann genauso wenig sicher.

Ohne JavaScript?

onclick="window.open(urlinput.value)"

Wohl kaum...

klaudschv wrote:

Zitat

denn es gibt Seiten die zwar keine Cookies anlegen, aber die vorhandenen auslesen und ein Profil etc. erstellen.

Die vorhandenen sind nur diejenigen die die Seite selbst gesetzt hat. Restriktionen im Browser verhindern, dass man Cookies beliebiger Seiten abfragen kann (modulo Sicherheitslücken, XSS u,ä.).

unix_samurai wrote:

Zitat

und Privoxy 3 nennenswerte Cookiemanager

Was bitte meinst du mit Privoxy? Ich kenne nur den Proxy und der ist weit mehr als ein Cookiemanager.

Zitat

dass sämtliche Attacken bereits auf einen User ausgeführt werden können

Oh mein Gott, der böse Cookie-Angriff!!!!einself
Was bitte für einen Angriff willst du über Cookies starten? Abgesehen von Privacy-Gedanken hat noch kein Cookie irgendeinen Rechner kompromittiert.

Zitat

CS Lite hat den scheinbaren Nachteil, dass wenn man es für bestimmte URLs deaktiviert, aus welchen Gründen auch immer, auch jegliche Filter die es mit sich bringt deaktiviert. Was ist eure Meinung?

Erkläre das mal genauer.

Btw. ist CS Lite kein Cookie-Manager. CS-Lite ist im wesentlichen eine bequeme Oberfläche für den Fx-internen.

Zitat von madblueimp

Nach der Lektüre des Forscher-Berichts denke ich sogar, das der heise-Artikel die Sache verharmlost und in Bezug auf EV-SSL-Zertifikate sogar schlicht falsch ist.

Der heise-Artikel ist etwas schwammig an manchen Stellen. Ob EV-SSL-Zertifikate einen Schutz bieten, ist zunächst eine technische Frage, dann eine Frage des Wissens auf User-Seite.
Ich weiß nicht, ob es möglich ist mit einem gefakten CA-Zertifikat eigene EV-SSL-Zertifikate auszustellen. Das müsste man erst in Erfahrung bringen. Ich gehe aber davon an der Stelle nicht aus. Dann würde der zweite Aspekt greifen, EV-SSL-Zertifikate wären dann kein direkter Schutz aber sie würden dem User die Möglichkeit geben Verdacht zu schöpfen. Wenn man einen Server nutzt, der ein solches EV-SSL-Zertifikat normalerweise verwendet, wird das im Browser auch gesondert dargestellt. Ruft man die Seite nun wie gewöhnlich auf und die EV-SSL-Darstellung fehlt, dann könnte das dem erfahrenen User helfen. Dies setzt aber eben voraus, dass der User die Unterscheidung treffen kann und dass es technisch nicht möglich ist mit einem gefakten CA-Zertifikat EV-SSL-Zertifikate auszustellen.

Zitat

Falls es außer den Sicherheitsforschern jemandem gelungen ist ein Herausgeberzwischenzertifikat zu erstellen würde es meinem Verständnis nach nur helfen die Root-CA des betroffenen Herausgebers aus den Browsern zu entfernen (damit das Herausgeberzwischenzertifikat und vom Herausgeberzwischenzertifikat signierte Zertifikate nicht akzeptiert werden).

Im Prinzip ja, wobei man dadurch u.U. natürlich viele gültigen Zertifikate ablehnt. Des weiteren kann natürlich so etwas wie Perspectives unterstützen.
Im Falle von EV-SSL wäre der User quasi ein eigener lokaler "Notar", der zwar nicht die Zertifikate vergleicht aber die optische Unterscheidung feststellen kann. *gg*

Zitat

Allerdings landen die Daten ja dennoch im Klartext auf dem Rechner des Angreifers, da die Verschlüsselung ja zwischen Client+Angreifer (mit gefälschtem Zertifikat) und Angreifer+Server (mit echtem Zertifikat) stattfindet. Ich hätte besser schreiben sollen, das die Identität einer Webseite nicht mehr sichergestellt werden kann.

Korrekt. Ein Problem jeder PKI ist das Vertrauen in die Schlüssel und die Gewährleistung, dass der präsentierte Schlüssel auch wirklich dem Transaktionsziel gehört. Solange die CAs die Vergabe von Zertifikaten nicht besser absichern, unterstützt wohl nur eine Art Überwachung des Schlüsselsystems im Sinne eines "Web-of-trust" wie es bspw. Perspectives realisiert.

Bist du denn für die Beispielseite verantwortlich?

Man könnte natürlich die relevanten Seiten lokal spiegeln/speichern und sie dann via Erweiterung mit F1 aufrufen.

Allerdings sind die Seiten natürlich dynamischen Änderungen unterworfen (von Zeit zu Zeit die lokalen Seiten auffrischen) und es wäre eine extra Erweiterung nötig die Funktion über F1 aufzurufen. Wenn letzteres nicht gefordert ist, so reicht natürlich auch ein Lesezeichen.

Warum darf denn überhaupt jemand an deinen Rechner mit laufender Nutzersession?
Ich verstehe dabei auch nicht, warum es dich nicht stört, dass derjenige dann einzelne Passwörter auslesen kann.

Zitat von SerAxel

wenn im firefox wäre das übel da wir über 300 member haben und ich nich die geringste ahnung habe wie ich das denen vermitteln kann

Die müssen bei sich nichts ändern. Der Code der Seite muss geändert werden.

<span style="font-family: 'Book Antiqua','Times New Roman',Times,Serif; font-size: x-small;">

Damit ist der Text auf der Beispielseite jeweils eingefasst. Das font-size sollte weggelassen oder auf einen anderen Wert (entsprechende der verlinkten Spezifikation) geändert werden.

Um welches nebulöse Programm geht es denn?

Ansonsten:
http://de.wikipedia.org/wiki/Proxy_Auto-Config
Sollten beide Browser verstehen.

Zitat

welches plugin für meine Zwecke geeignet sein könnte.

Vielleicht definierst du deine Zwecke oder suchst einfach selbst:
https://addons.mozilla.org/

http://support.mozilla.com/de/

Über CSS ist font-size: x-small definiert. Das zeigt der Fx dann auch an.
http://www.w3.org/TR/CSS1/#font-size

Zitat

jedoch startet er mir den Firefox immer nur ohne Addons

Hast du bei den genannten Möglichkeiten die Option Kommandozeilenparameter zu übergeben? Falls ja, dann übergib dem Fx das entsprechende Profil.

madblueimp wrote:

Zitat

gehört das SSL-Zertifikat für blueimp.net zu einer Reihe von Zertifikaten (ca 30% aller HTTPS-Seiten), die von Certificate Authorities mit dem unsicheren MD5-Verfahren signiert wurde.
Es ist daher potentiell kompromittierbar, d.h. Angreifer könnten das Zertifikat, das eigentlich nur für blueimp.net gilt, für einen eigenen Server erstellen.

Ergänzend:
Mit dem Zertifikat von blueimp.net hat es eigentlich gar nichts zu tun, selbst wenn das mit SHA-1 signiert wäre. Der Angriff beruhte darauf, dass sich die Forscher ein eigenes CA-Zertifikat mit einer Signatur eines anderen Zertifikats gebastelt haben. Dass sie die Signatur übernehmen konnten lag daran, dass sie die Schwäche von md5 bei Kollisionsangriffen ausnutzten. Mit dem CA-Zertifikat, dass von einer anerkannten CA signiert wurde, konnten sie sich dann selbst Zertifikate für jede beliebige Domain erstellen. Daher spielt es keine Rolle, ob das Zertifikat von blueimp.net mit md5 oder SHA-1 signiert ist. Die Forscher hätten sich ohnehin ein eigenes ausstellen können.
Entscheiden dabei ist, wie sie den Browser dazu bringen den falschen Server anzurufen bspw. über ARP-Spoofing, DNS-Spoofing oder Pharming. Das setzt aber weitere Schwachstellen oder Gegebenheiten voraus.

Zitat

Das heißt aber noch lange nicht, das der Besuch von blueimp.net (oder einer anderen HTTPS-Seite mit unsicherem Zertifikat) per se unsicher wäre. Es kann nur die Verschlüsselung nicht sichergestellt werden, da sich ein Angreifer mit gefälschtem Zertifikat in die Verbindung einklinken könnte ohne das dein Browser eine Fehlermeldung ausgibt.
Damit ist die Seite aber immer noch mindestens genauso sicher wie eine Seite komplett ohne Verschlüsselung.

Er würde sich nicht "einklinken" im Sinne von mitlauschen (Aufbrechen der Verschlüsselung). Der Angreifer würde die Verbindung von Beginn an zu seinem Server umleiten. Der Verschlüsselung könnte man daher schon vertrauen, nur dem Endpunkt nicht. Bei einem MITM-Szenario (Weiterleitung der Daten zwischen Client und eigentlichem Zielserver) würde eine zweite Verbindung aufgebaut. So dass man nicht davon sprechen kann, dass die ursprüngliche verschlüsselte Verbindung "entschlüsselt" wurde. Sie wurde nur umgeleitet, wobei die einzelnen Kanäle verschlüsselt bleiben.

Siehe auch:
http://www.win.tue.nl/hashclash/rogue-ca/

Zitat

Any website, whether it is secure (i.e. uses SSL) or not, whether it has an MD5-based, SHA-1-based, SHA-256-based, or any other type of certificate, irrespective of which Certification Authority issued the certificate, can be impersonated, in particular not only genuine websites that have an MD5-based certificate are vulnerable.

Zitat

Die SSl-Blacklist bedeutet also in diesem Fall einfach nur, das die Verschlüsselung nicht gewährleistet werden kann, man sich also nicht auf die HTTPS-Verschlüsselung verlassen kann.

Das Beispiel zeigt viel eher, dass die Erweiterung an der Stelle unsinnig ist. Eine Warnung vor md5-Zertifikaten für Clients ist in dem Szenario aus genannten Gründen völlig unnötig und verunsichert nur, wie hier sichtbar.
Viel eher interessant für den Anwender ist Perspectives.
http://www.cs.cmu.edu/~perspectives/
http://www.cs.cmu.edu/~perspectives/md5.html

http://www.firefox-browser.de/forum/viewtopic.php?t=64016