News WordPress über unverschlüsseltes Cookie angreifbar

Wenn man https verwendet (zwangsweise) kein Problem, richtig?
 
Klar, wenn man seinen Cache danach nicht löscht.. :D
 
Das mag ja stimmen, aber wer sichert seinen Bananen-Blog hinten und vorne mit nem (teilweise recht teuren) Cert ab?

Der Fehler liegt, mal wieder, in der grundsätzlich bescheuerten Art und Weise, wie WP aufgebaut ist. Cookie Spoofing gibts bei WP schon seit Jahren. Das ist nur der nächste Auswuchs.
Aber mal ganz ehrlich: Hat so etwas denn Auswirkungen? Nein, Wordpress wird immer weiter empfohlen. Gerade Einsteiger stürzen sich drauf wie Fliegen aufs Aas.
 
Ich tue das und das Cert kostet mich keinen cent .. (Gibt auch legale Kostenlose zertifizierte single domain certs)
 
dMopp schrieb:
Ich tue das und das Cert kostet mich keinen cent .. (Gibt auch legale Kostenlose zertifizierte single domain certs)

echt? wusste ich garnicht.. wo gibt's denn so nette zertifikate, könnte das auch brauchen.. und 2. wie hast du die integriert?
 
https://www.startssl.com :)

Und ich habe nen Bundle aus der Chain erstellt und das als CRT eingebunden. (nginx supportet nur auf diesem weg die Chain)
 
Das mag sein, aber schon eine meiner liebsten Informationsquellen, davidwalsh.name, hat kein Cert, nciht einmal ein kostenloses. Und er solltes eigentlich besser wissen.
Es ist schlichtweg nicht üblich, eine einfache Homepage erst großartig mit nem Cert zu versehen. Den Aufwand tut sich keiner an.

Der Fehler liegt nicht an fehlender SSL-Verschlüsselung der Webseite sondern darin, wie Wordpress den Auth Cookie setzt. Schau mal aufs Datum dieses Blogeintrags. Cookie-basierte Angriffe sind so alt wie Wordpress selbst, aber weil die WP-Macher eben nie einsehen, dass sie für einen Zuwachs an Sicherheit eben auch einen harten Schnitt im Code machen müssen, wird das auch ewig so bleiben. Da wird nur ein Patch draufgekleistert, der ganze WP-Teppich besteht nur aus Patches, da ist kein Bit mehr "geplanter" Code.
 
Das Problem ist ja, dass es im Browser eine Warnung gibt, wenn es ein SELBST erstelltes Zertifikat gibt, bei einer reinen http Seite gibt es das nicht.. Sinn ? Jeder Browser sollte primär https versuchen und erst dann (als Fallback) auf http zurück greifen und ne Warnung ausgeben (gelbe Leiste zB).


Ich stelle mir das so vor:

http -> Gelb, Warnung
https selfsigned -> Weiß (wie jetzt http)
https signed -> Weiß mit Häkchen oder so
https chain ungültig -> Rot ! (oder Cert passt nicht zur Domain etc)
 
Hmm, wenn ich das richtig verstanden habe, ist hier der Knackpunkt hier ebend nicht das Session-Hijacking, denn das bleibt immer ein pauschales Problem im unverschlüsselten Verkehr. Es ist vielmehr so, das mit dem Wert von wordpress_logged_in erneut ein zuteil eingeloggter Zustand erreicht werden kann, obwohl zuvor explizit ausgeloggt wurde.

Ich hab dies gerade bei einem WordPress 3.8.1 getestet. Dabei wird im Frontend tatsächlich die obige Leiste angezeigt. Und wahrscheinlich werden so Informationen (von Modulen) angezeigt, die diesen eingeloggten Zustand nicht korrekt prüfen. Bei mir konnte ich jedoch ausser der Leiste keine finden, und ins Backend kommt man nicht ohne ein echtes erneutes Login. Es scheint also weniger ein Problem des Cookies zu sein, sondern vielmehr falsche oder ungeprüfte Rechte einzelner Module, so meine Vermutung.
 
@dMopp
So funktioniert es aber nicht. Wenn du (als Entwickler) von Haus aus davon ausgehst, dass deine Seite einfach nie HTTPS benötigen wird, dann wirst du stellenweise externe Quellen (z.B. das Google CDN für JS Frameworks oder Fonts) auch nur via HTTP einbetten. Die Verbindung von sicheren und unsicheren Inhalten klappt nicht.

Außerdem sind HTTPS-Aufrufe ein Stück komplexer als HTTP-Aufrufe. Nur in Verbindung mit SPDY kommt HTTPS ansatzweise an HTTP ran oder kann sogar schneller sein. Jeden Bananen-Aufruf zu verschlüsseln ist ziemlich sinnfrei, pure Ressourcenverschwendung. Was noch ins Gewicht fällt: HTTPS verhält sich anders hinsichtlich des Referers. Es sendet keinen... Seit Google & Co quasi nur über HTTPS angesprochen werden, kann man als Seitenbetreiber keine Suchbegriffe mehr auswerten.
Und dann ist da noch die Sache mit SNI... Mti dem Ende von XP und ner stetig fallenden Verbreitung von Android 2 wird SNI zwar immer weniger zum Problem, aber es existiert einfach noch.
 
Und deshalb sollen alle anderen Rücksicht nehmen? SPDY/HTTPS enforcen und gut ist. Schritt 1 wäre halt Bewusstsein schaffen über die verschiedenen Browser. Nur weil die Menschheit zu Faul ist sich endlich mal vorwärts zu bewegen muss ich da nicht mitmachen.

Siehe: www.dmopp.de https/spdy enforced und Performancetechnisch kein unterschied (dank cryptodev geht auch https richtig fix).

Es macht nunmal keinen Sinn, dass eine http Verbindung als sicherer gilt wie eine https Verbindung mit eigenen Zertifikat, oder willst du mir da widersprechen ?

Thema Referrer:
- Komisch, mein nginx loggt die referrer und das bei einem https direktlink ?!

Thema SNI:
- Wäre mit IPv6 vom Tisch
- Auch unter Android4 ein Problem (Dank Oracle, Java6 kann per default kein SNI)
 
Thema Referrer, geh auf google.de, schau das es auch die HTTPS verschlüsselte Seite ist (was zu 95% der Fall sein dürfte), gibt einen Suchbegriff ein mit dem Du deinen Blog findest, klick drauf und sag uns ob Du durch den Referrer den dein Nginx erkennt, siehst, welchen Suchbegriff Du eingetragen hast.

Wenn das funktioniert, würden wohl ganz schön viele Analyse-Tool Betreiber, SEOs etc. sofort auf Nginx setzen, nur damit sie tracken können mit welchen Suchbegriffen die Leute auf Ihre Domains kommen.

Was das Thema WordPress angeht, das Cookie "wordpress_logged_in" habe ich auch, aber da ist noch ein Hash dran gehängt. Wie ist dieser denn jetzt so einfach zu knacken? :freak:
 
dMopp schrieb:
Siehe: www.dmopp.de https/spdy enforced und Performancetechnisch kein unterschied (dank cryptodev geht auch https richtig fix).
...das ist dann aber wohl deine eigene Maschine, die du zu 100% selbst administrierst. Das kannst du nicht mit der realen Hosting-Landschaft vergleichen.

Es macht nunmal keinen Sinn, dass eine http Verbindung als sicherer gilt wie eine https Verbindung mit eigenen Zertifikat, oder willst du mir da widersprechen ?
None-SSL -> ich stelle eine unsichere Verbindung zu einem unsicheren Ziel her und bin mir der Problematik bewusst
Self Signed -> Ich stelle eine sichere Verbindung zu einem unsicheren Ziel her. Meine Daten, die ich sicher wähne, sind eigentlich nicht sicher.

- Wäre mit IPv6 vom Tisch
IPv6 existiert nicht.
Da kommt HTTP/2 raus, bevor sich bei IPv6 wirklich was tut.
Ergänzung ()

Domi83 schrieb:
Was das Thema WordPress angeht, das Cookie "wordpress_logged_in" habe ich auch, aber da ist noch ein Hash dran gehängt. Wie ist dieser denn jetzt so einfach zu knacken? :freak:

Wordpress setzt nicht auf Sicherheit. Überall wird nur mit MD5 gehasht, auch bei der Passwörtern in der DB. Eine aktuelle Grafikkarte killt dir das Ding in ein paar Stunden.
 
Naja Anfängern kann man sicherlich keinen Vorwurf machen wenn diese Wordpress nutzen. Es ist eben schön einfach. Aber ab einer bestimmten Größe des Blogs sollte man sich dann doch nach Alternativen oder einer Eigenbau-Lösung umschauen.
 
Eigenbau ist selten sicher. Da wird dann genau derselbe Pfusch geliefert wie bei WP.
Nein, man kann Neulingen keinen Vorwurf machen. An allen Ecken und Enden wird ihnen WP als DAS SYSTEM angepriesen... und zugegeben, es ist auch unglaublich gut bedienbar. Von Bedienkonzepten verstehen die Jungs was.

Nein, die Vorwürfe gehen einzig und allein an die Wordpress-Entwickler, die n Teufel tun und ihren Saustall mal richtig ausmisten.
 
Naja, was sind denn gescheite Alternativen zu Wordpress? s9y, dotclear und wie sie alle heißen sehe ich, um ehrlich zu sein, nicht mal ansatzweise auf Augenhöhe mit WP... Aber bin gerne für Vorschläge offen. Spiele aktuell nämlich mit einiger Blog-Software rum und habe noch keine 100% zufriedenstellende Lösung gefunden.
 
Zuletzt bearbeitet:
Daaron schrieb:
None-SSL -> ich stelle eine unsichere Verbindung zu einem unsicheren Ziel her und bin mir der Problematik bewusst
Self Signed -> Ich stelle eine sichere Verbindung zu einem unsicheren Ziel her. Meine Daten, die ich sicher wähne, sind eigentlich nicht sicher.

Falsch.

SelfSigned ist grundsätzlich sicherer wie kein Cert. Klar, wer noch alles nen Key zum entschlüsseln hat weist du nicht, aber es sit dennoch um den Faktor X sicherer wie keine Verschlüsselung.

Und Thema IPv6:
- Telekom: Check
- KDG: Check

Beide setzten schon auf IPv6 und das sind die 2 größten in DE, andere Länder andere Sitten, aber auch da wirds Zeit.
 
Zurück
Oben