Feedback zur Website

Der Typ heisst Arno :beanwat:

1 „Gefällt mir“

Moin Moin,

du musst mir unbedingt einmal erklären, wieso Cookies sicherer sein sollten als der LocalStorage. Beides kann ich mittels XSS sehr einfach auslesen. Das ganze hat auch nichts mit Verschlüsselung zu tun. Wenn ich Zugriff auf den Computer habe, macht es keinen Unterschied, ob ich die (pseudeo) Verschlüsselten Cookies oder den LocalStore auslese.

Der Grund wieso wir versuchen möglichst alle Cookies auszusperren ist die Cookie Compliance auf Basis der EU-Richtlinien. Unsere Webseite benutzt aktuell keine Cookies, nur Kekse von 3d-Party anbietern (wie zum Beispiel von Youtube) werden gesetzt. Und das nicht innerhalb unseres Webseiten-Scopes.

Ich bin wirklich neugierig auf interessante neue Konzepte und Ideen. Die Lösung für jegliche Probleme ist jedoch nicht, dass wir erneut alles in Cookies speichern. :slight_smile:

3 „Gefällt mir“

Inwiefern hilft das? Dass die eine “Technik” Cookie genannt wird und die andere nicht, wird wohl nicht der Grund sein. Und das frage ich jetzt unabhängig von einer Sicherheitsdiskussion.

Alle Cookies kriegt ihr mit dem Forum und Cloudflare unter eurer Domain auch nicht abgelöst.

Mir ist ehrlich gesagt auch neu, dass localStorage unsicherer sein soll als Cookies. Beide basieren auf den selben Prinzipien und Security Policies, u.a. dass sie nur von der Webseite ausgelesen werden können, die sie gesetzt hat. Der Vorteil an localStorage ist hierbei sogar, dass dies bei localStorage ausschließlich der Fall ist, während man beim Setzen von Cookies fälschlicherweise eine „falsche“ (Sub-)Domain setzen kann, die dann die Rechte hätte, Daten auszulesen.

Im Falle von XSS haben beide Storage Methoden das selbe Problem, dass die Daten ausgelesen werden können, da die Attacken ja lokal ausgeführt werden.

Ein weiterer Vorteil von localStorage gegenüber Cookies wäre indes, dass - anders als bei Cookies - die Daten in der localStorage nicht bei jedem Request an den Server mit übermittelt werden - was a) unnötiger Overhead ist und b) abgefangen werden kann.


Die Nachteile bei localStorage sehe ich persönlich daher weniger bei der Security, sondern dass es nur mit JS und nicht in Web Workern genutzt werden kann. Wobei vor allem Ersteres ein Nachteil ist, der für eine SPA wie die RBTV-Website nur bedingt gilt.

Wäre aber auch daran interessiert zu erfahren, inwiefern localStorage signifikant unsicherer sei. Man lernt ja ungern je aus. :slight_smile:

2 „Gefällt mir“

Ganz klare Sache: Beides ist eine offene Tür, wenn man XSS nicht so gut es geht unterbindet.
Aber, man muss auch kurz über die httpOnly und secure-Flags für Cookies reden (Also allen voran httpOnly).
Nur ich weiß natürlich, dass das für SPAs eine Sache ist, die nicht so sexy ist. xD

Vielleicht noch als kleinen Nachsatz: Ich muss dazusagen, dass ich noch von der alten Dev Schule bin (HTML, PHP, JS) und mich erst recht frisch mit dem „klassischen SPA Workflow“ auseinandersetze. Profi bin ich also bei Gott keiner.
Aber eine best practice die mir immer wieder unterkommt ist eben:

Server returns JWT to client in a session cookie marked httpOnly

Und das muss ja einen Grund haben… :thinking:

1 „Gefällt mir“

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.

3 „Gefällt mir“

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. :slight_smile:

2 „Gefällt mir“

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.

4 „Gefällt mir“

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.

3 „Gefällt mir“

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. :slight_smile:

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. :blush:

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.

13 „Gefällt mir“

Patch Tales Folge 1 ging auf Sendung. Was geliefert wird sieht man im Link

@DoomDesign
Das random Youtube Ding sagt mir leider das :ok_man:

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.

Liegt eventuell daran

1 „Gefällt mir“

Achso, dachte wenn das passiert bekommt man das auch so gesagt. Möglich

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. :beanjoy:
2FA bekommt ein dickes Lob von mir. Tolle Sache!

1 „Gefällt mir“

Ja.

1 „Gefällt mir“

2FA aktiviert. :beangasm:

2 „Gefällt mir“

August 2018

April 2019
grafik
:beangasm:

4 „Gefällt mir“

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

1 „Gefällt mir“

Gibt es erstmals nur für den Blog aber das solltest du nicht machen. Wenn du den Blog abonniert hast :wink: