Rocket Beans Community

Feedback zur Website


#492


#493

Ich mag das neue Design, aber mit der Arvo-Typo kann ich mich einfach nicht anfreunden.


#494

Der Typ heisst Arno :beanwat:


#495

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:


#496

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.


#497

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:


#498

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:


#499

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.


#500

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:


#501

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.


#502

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.


#503

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.


#504

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


#505

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


#506

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


#507

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


#508

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!


Spam-Thread VI- Die RĂŒckkehr des Spams
#509

Ja.


#510

2FA aktiviert. :beangasm:


#511

August 2018

April 2019
grafik
:beangasm: