• Nachtrag: Gerade eben habe ich den Effekt mit meinem Android-Smartphone (FF unter Android 5.1.1) nochmals reproduzieren können. Daß er bei anderen nicht auftrat, lag also mutmaßlich daran, daß diese sich nicht über die https-Seite eingeloggt haben, was die Fehlerursache doch deutlich eingrenzt. @Gerhart wies ja bereits darauf hin, daß das betreffende Photo nur per http eingebunden wurde. Unverschlüsselte Inhalte während einer verschlüsselten Verbindung: Ein guter Browser streikt dann. In diesem Fall wird dann vermutlich die gesamte Verbindung auf http umgestellt, womit das Sitzungs-Cookie seine Gültigkeit verliert. Insoweit verhalten sich sowohl die Browser (sogar der vielgescholtene IE) als auch die Forensoftware eigentlich korrekt.

    ebayForumKopfverkl.jpg
    Peter Viehrig

    "Glaube ist die Überzeugung, dass etwas wahr ist, weil die Belege zeigen, dass es falsch ist."
    (Andreas Müller)

  • Um nochmal klarzustellen, was genau passiert:
    Ausgangssituation: Mein Browser hat nen Cookie "wcf_cookieHash", der nur über https gesendet wird. Dank dieses Cookies bin ich eingeloggt.
    Nun lade ich ein Bild, , über http (also kein https!).
    Mein Browser schickt den Cookie nicht mit, denn das darf er ja nicht. Der Webserver denkt sich: Oh, der hat noch kein Cookie, schick ich mal einen neuen:

    Code
    Set-Cookie: wcf_cookieHash=a73d8de528d632b998164ee4b6b36105eb458e4b; path=/; domain=www.radverkehrsforum.de; HttpOnly

    Der Browser ersetzt nun den existierenden Cookie. Dieser wird dann auch über https gesendet.
    Mit dem neuen Cookie bin ich aber nicht eingeloggt, also bin ich nun ausgeloggt.

    Beschrieben ist das Problem im Prinzip in RFC6265, Kapitel 8.6, Absätze 3 und 4.
    Der einzige Schutz gegen so einen Angreifer dürfte in HTTP Strict Transport Security liegen. Das wäre auch ein Workaround gegen das hier vorliegende Problem.

    Die Browser verhalten sich korrekt. Das Problem ist einerseits das bekloppte HTT-Protokoll, andererseits ein Fehler in der Forensoftware: Aus irgendeinem Grund ist das Bild als http verlinkt, das sollte nicht passieren.

    Abhilfe schnell: HTTP Strict Transport Security anschalten, http am Besten ganz wegschmeißen: Port im Apache deaktivieren oder Redirect auf https (wieder mit HSTS).

    Und mal gucken ob ich das Problem nachstellen kann:
    2223-kaputt-jpeg
    Einfach oben in der Toolbar auf "Bild" gehen und ein Link mit http einfügen, z. B. nachdem man einen Anhang hochgeladen hat.