Zunächst zur Klarstellung: Es geht mir auf keinen Fall darum, dass alles in Cookies gespeichert werden soll. Allein durch die Beschränkung der Größe auf 4KB sind die ja auch gar nicht unbedingt darauf ausgelegt. Ich finde die Storage API auch super und nutze sie selbst, ich finde nur, empfindliche Daten - und dazu würde ich das Session-Token auf jeden Fall zählen - sollten nicht völlig offen im LocalStorage liegen.
Mithilfe der httpOnly-Option ist es bei einem Cookie ja zumindest in gängigen Browsern schon mal möglich, dass er clientseitig nicht ausgelesen werden kann. Mit der secure-Option wird zudem nur noch über eine HTTPS-Verbindung gesendet, wodurch sich das Abfangen verhindern lässt (@Cyberblitzbirne). Bliebe nur noch die Möglichkeit per XST darauf zuzugreifen. Das lässt sich wohl auch nicht endgültig verhindern, moderne Browser blocken TRACE-XMLHttpRequests aber zumindest. Natürlich wird auch ein Cookie niemals zu 100% sicher sein.
Ich bin mir sicher, dass ich dir (bzw. euch) auch nicht wirklich etwas grundlegend Neues dazu erzählen kann. Ich empfinde es persönlich als unsicherer und würde empfindliche Daten wie das Session-Token daher in einem Cookie speichern. Mein Wissensstand ist auch, dass es als Bad Practice gilt, den LocalStorage dafür zu nutzen, siehe bspw. HTML5 Security Cheat Sheet Abschnitt “Local Storage”.
Letztlich wird das Schicksal der Welt aber nicht davon abhängen und ich wollte hier auch keine Panik auslösen oder andere User verunsichern, sondern lediglich meine Sicht der Dinge darlegen, da ich es eben nicht für die beste Lösung halte.
Das ist korrekt, allerdings hilft die httpOnly-Option nicht, wenn ein Angreifer in der Lage ist, ein Script in Dein Frontend injecten zu können. Mit dem Script kann derjenige dann HTTP-Requests zum Server ausführen (direkt im Browser des „Opfers“) und bei jedem Request hängt dann das Cookie mit dran am Request (trotz httpOnly-Option), und der Angreifer kann es problemlos auslesen.
Ich glaube, im Falle eines XSS-Vorfalls ist man beiden Methoden ähnlich schnell „am Arsch“. Der Angreifer muss nur einen anderen Weg gehen, aber an die sensiblen Storage-Daten kommt er leider in beiden Fällen recht problemlos. Von daher sehe ich persönlich nachwievor nicht, wieso Cookies hier deutlich sicherer sein sollen (das beziehe ich übrigens nicht nur auf Behauptungen in diesem Thread hier, sondern habe das in der Tat auch schon öfter im Web gelesen).
Vielleicht missverstehe ich die httpOnly-Option aber auch nur grundlegend. Werd’ mal die Gelegenheit nutzen, und mein Wissen dahingehend auch mal wieder auffrischen.
Das Problem ist, dass wir ja genau das benötigen. Ich weiß nicht, in wiefern du dir mal die Requests der Webseite angeschaut hast, aber es gibt zwei Tokens: Einen, den der Client ständig bei jedem Request zum Server schickt, und einen zweiten, mit welchem das Frontend selbstständig sich einen neuen Token holt, der erneut nur eine bestimmte Zeit gültig ist.
Das ist aber eher ein Persönliches Empfinden und zumindest für mich kein relevanter Punkt. Faktisch sind Cookies genau so einfach auszulesen wie der Local Storage. Nur, dass dieser nicht unter die Cookie-Richtlinie fällt.
Grundsätzlich empfinde ich unseren Umgang mit den Daten unserer Nutzer als sehr Vorbildlich.
Beispiel: Alle personenbezogenen Daten werden zusätzlich verschlüsselt in der Datenbank gespeichert. Die personenbezogenen Daten, die wir nur zum Abgleich brauchen speichern wir ausschließlich in gehashter Form. E-Mails versenden wir nur mit vorheriger Nachfrage. Und selbst die Adresssysteme sind voneinander getrennt. Beispiel hier: Gewinnspiele und Supporters Club. Beide “Felder” haben bei uns intern einen anderes Secret und können so selbst nicht vergleichen werden. Sollte also aus welchem Grund auch immer die Datenbank exportiert werden können, sind trotzdem zum aktuellen Stand alle relevanten Daten doppelt abgesichert.
Ich möchte keineswegs mit diesem Post quasi zu einen Rundumschlag ausholen, sondern nur aufzeigen, dass wir uns wirklich Gedanken darüber machen, wie wir Datenschutzrelevante Daten speichern und dass wir uns wirklich viele Gedanken über genau solche Themen machen.
Tobi, ich glaube ich spreche für alle, die diesen Punkt angesprochen haben, wenn ich dir sag, dass wir auch nicht geglaubt haben, dass ihr mit unseren Daten total fahrlässig umgeht. Das kann man aus dem Punkt auch garnicht schließen und ich persönlich setze auch das Vertrauen in euch.
Ich glaub es ging den meisten, mir zumindest jedenfalls, nur darum mal zu fragen wieso localStorage wo doch die meisten best practices im Internet sagen, dass httpOnly-Cookies the way to go sind.
Man muss aber dazu sagen, dass das „meckern“ auf hohem Niveau ist. Das Wichtigste ist halt mal eine anständige Absicherung gegen XSS und da bin ich tiefst überzeugt, dass ihr die habt. Damit ist die Angriffsfläche ja stark reduziert bzw. sogar eliminiert, wenn man nix übersehen hat.
Ich bin wirklich komplett entspannt. Ich wollte nur einmal darlegen, wieso wir bestimmte Dinge so tun, wie es aktuell ist. Wir möchten euch einen etwas größeren Einblick in unsere Entwicklungen und Gedankengänge geben, deswegen meine Offenheit zu diesem Thema. Ich kann für das komplette Entwickler-Team sprechen und sagen, dass wir immer für Coole Ideen und anderen Input offen sind.
Mein ganzer Post sollte nur dazu dienen euch zu Informieren, sollte er anders rüber gekommen sein, muss ich ehrlich sagen, dass es so nicht gedacht war. Ich bin kein Community-Profi und auch kein Social Media Experte.
Ich hoffe weiterhin auf Konstruktive Kritik und Ideen, und ich kann Euch versichern, dass wir regelmäßig hier ins Forum und insbesondere diesen Thread schauen um eben auch dieses Feedback einzuholen.
Edit:
Was ich noch unbedingt sagen wollte: Ich begrüßte den Umgangston hier sehr. Konstruktive Kritik - egal ob erst einmal nachvollziehbar oder nicht - ist für uns absolut wichtig. Und deswegen freue ich mich umso mehr, dass wir auf dieser Ebene hier diskutieren können.
Da YouTube uns nur eine begrenzte Anzahl an Aufrufen pro Tag zur Verfügung stellt, kann das Spiel bei zu starker Frequentierung leider auch mal den Geist aufgeben.
Kurze Nachfrage dazu: Wird Adresszeile 2 für eure Zusendungen inzwischen berücksichtigt?
Das ist nämlich ein toller Platz zum Eintragen von Türnummer o.Ä. und ich hab damals meinen RBSC Brief ohne die bekommen, was dann nur durch das, dass ich freiwillig meinen Namen am Briefkasten stehen hab richtig zugeordnet wurde. Aber das ist ja heutzutage kaum mehr der Fall.
Ansonsten: Als hätten wir es gerochen, dass am Login noch ein wenig geschraubt wurde.
2FA bekommt ein dickes Lob von mir. Tolle Sache!
Ist es eventuell möglich ohne viel Aufwand für euch eine “deabonnieren” Funktion einzubauen? Ich habe z.B. Florentin abonniert aber gucke nie RoE bekomme aber fast jede Woche eine Benachrichtigung weil Florentin dabei ist. Wenn ich RoE quasi stummschalten könnte wäre es etwas komfortabler
Viel Aufwand wäre es schon und evtl auch nur für die Poweruser interessant; aber um die Website noch attraktiver zu machen fänden wir es auch nett. Muss man aber durchkalkulieren und sehen, wo es zeitlich reinpasst oder ob eben andere Dinge erstmal wichtiger sind.
Einzelne KHDs zu filtern könnte EEECHT schwer werden bei der Umsetzung eines solchen Filters, weil die einfach so speziell sind derzeit. Das Gleiche für “Pen And Paper”.
Höchstens wenn wir beginnen, alles und jeden mit (Hash)-Tags zu versehen.
