Hallo allerseits, eventuell passt meine Frage nicht genau zum Forum. Weil mir aber in der Vergangenheit hier stets sehr gut geholfen wurde, möchte ich den Versuch nicht unterlassen, euch um Rat zu fragen. Es geht um das Thema Web-Programmierung und Cookies. Ich habe untersucht, welche Datren/Cookies der Online-Versandhändler otto.de lokal auf meinem PC speichert. Ergebnis war, dass unter anderem Suchanfragen, angesehene Artikel und Wunschlisteneinträge gespeichert wurden. Frage: Aus welchem Grund speichern so viele Webseiten, Daten in Cookies? Warum speichern Sie die Daten nicht einfach in ihren eigenen Datenbanken. Hat das Performance-Gründe? Danke!
Torben S. schrieb: > Frage: Aus welchem Grund speichern so viele Webseiten, Daten in Cookies? > Warum speichern Sie die Daten nicht einfach in ihren eigenen > Datenbanken. Hat das Performance-Gründe? Wenn du nicht bei einer Seite angemeldet bist, bist du dort auch nicht zuverlässig identifiziert. Willst du beim nächsten Besuch jene Produkte angeboten bekommen, die irgendein vielleicht passender Vorgänger interessant fand - und umgekehrt?
Cookies sind oldschool, es gibt auch noch Webstorage (mit localstorage, sessionstorage) und indexedDB, dort ist noch viel mehr gespeichert vor allem in der indexedDB.
(prx) A. K. schrieb: > Torben S. schrieb: >> Frage: Aus welchem Grund speichern so viele Webseiten, Daten in Cookies? >> Warum speichern Sie die Daten nicht einfach in ihren eigenen >> Datenbanken. Hat das Performance-Gründe? > > Wenn du nicht bei einer Seite angemeldet bist, bist du dort auch nicht > zuverlässig identifiziert. Willst du beim nächsten Besuch jene Produkte > angeboten bekommen, die irgendein vielleicht passender Vorgänger > interessant fand - und umgekehrt? Verstehe. Allerdings würde es in diesem Fall ja ausreichen einfach nur eine ID in einem Cookie zu speichern und die restlichen Informationen wie Sucheinträge, Wunschlisteneinträge etc. mit Referenz auf diese ID in der Datenbank.
Für den Speicher in den Cookies muss der Versandhändler nichts bezahlen. Für die Lösung "Cookie mit ID, Rest in irgendeiner serverseitigen Datenbank" eben schon. mfg mf
Und wenn einer wegen "DSGVO! Lösch all meine Daten!" ankommt, gibt's eine Anleitung zum Cookie-Löschen als Antwort. Wie machst du das, wenn die Daten Serverseitig liegen, aber nur mit einer ID im Cookie verknüpft sind? Die Lösch-Aufforderung muss die Cookie-ID nicht mit enthalten, löschen musst du die Daten trotzdem.
Da steckt da kein Plan dahinter. Das wird von Subunternehmern koordiniert, die sich nur um Akquise und Kundenbetreuung kümmern, keine Ahnung von der Technik haben. Die Entwicklung vergeben die an weitere Subunternehmen. Jedes Scrum Team trifft eigene Entscheidungen. Daten als Cookies abspeichern können die selbst implementieren. Für einen Datenbankserver müssten die sich über zig Wasserkopfabteilungen hinweg mit dem Subunternehmen für den Server koordinieren. Teilweise werden die Daten doppelt und dreifach abgespeichert. Jedes Subsubsubunternehmen macht es anders. Die DSGVO-Kompetenz-Teams schreiben den Subunternehmen irgend einen Unfug vor. Bei jeder neuen Vorschrift lassen die irgend welche Teile unkoordiniert umbauen. Und dann werden andauernd inkompetente Subunternehmer durch andere inkompetente Subunternehmer ersetzt, Macht die Sache auch nicht besser.
Vor allem: Welcher "Webseitenprogrammierer" versteht die technischen Zusammenhänge, wenn er sich aus verschiedenen Frameworks seinen Krempel zusammenklickert?
> Welcher "Webseitenprogrammierer" versteht...
Die Karawane ist weiter gezogen. Um 2000 rum hatten die besten Leute
Webprogrammierung gemacht.
Browser waren damals ein Sammelsurium von Unzulänglichkeiten und
Fehlern. Datenbanksysteme waren auf 10000 Benutzer ausgelegt. Trotzdem
hatten sie weltweite Dienste mit 100 Millionen Benutzern zustande
gebracht. Amazon, Yahoo, Napster...
Heutzutage machen die fähigen Leute KI.
Torben S. schrieb: > Frage: Aus welchem Grund speichern so viele Webseiten, Daten in Cookies? Auf Deinem Bildschirm gibt es rechts oben ein kleines rotes Feld mit weißem Kreuz darin. Einfach darauf klicken, und alles ist gut. Sei ein Mann!!!
Irgendwo habe ich mal aufgeschnappt, dass die Cookies, die auf einer Seite gesetzt werden, auf einer anderen Seite dazu verwendet werden, um individualiserte Werbung zu schalten. Stichwort Drittanbieter-Cookies. Und ja es leuchtet in diesem Kontext natürlich auch ein, das Benutzerverhalten in clientseitig zu speichern als über eine Datenbank, weil auf die Datenbank in Normalfall niemand anderes als der Online-Händler entsprechende Zugriffsrechte besitzt.
>auf einer anderen Seite dazu verwendet werden, um >individualiserte Werbung zu schalten Die Datenhändler wollen diese Daten verkaufen. Die Werbetreibenden sollen auf die Daten nur Zugriff haben, wenn sie dafür bezahlen. Wenn jemand direkt auf die Cookies zugreifen kann, ist das für die Datenhändler der Supergau. Damit Konkurrenz und Trittbrettfahrer nicht auf die Daten zugreifen können, dürften die Werbenetzwerke nur den Schlüssel für ihre geheime Datenbank auf deine Platte schreiben.
Xanthippos schrieb: >>auf einer anderen Seite dazu verwendet werden, um >>individualiserte Werbung zu schalten > > Die Datenhändler wollen diese Daten verkaufen. Die Werbetreibenden > sollen auf die Daten nur Zugriff haben, wenn sie dafür bezahlen. Wenn > jemand direkt auf die Cookies zugreifen kann, ist das für die > Datenhändler der Supergau. > > Damit Konkurrenz und Trittbrettfahrer nicht auf die Daten zugreifen > können, dürften die Werbenetzwerke nur den Schlüssel für ihre geheime > Datenbank auf deine Platte schreiben. sehr interessant. Danke für den Beitrag!
Setzen die nennenswerten Browser nicht sowieso seit einiger Zeit „same origin“ durch? FF tut das, soweit ich weiß – damit können Seiten eben keine Cookies lesen, die andere Seiten gesetzt haben.
:
Bearbeitet durch User
> damit können Seiten...
Nicht die Seiten. Jedes einzelne Script kann die Cookies seiner Domain
lesen.
mikrocontroller.net lädt wie viele andere Seiten das Script von
doubleclick.net So kann Google auf mikrocontroller.net ein Cookie setzen
und auf anderen Seiten, die sich auch das Doubleclick Script laden
wieder lesen.
Ich habe fünf Kekse von mikrocontroller.net, und alle scheinen legitime Forencookies zu sein, i.e. keine Kekse von Drittscripten.
es gibt ja auch die Möglichkeit die Cookies beim Neustart des Browsers zu löschen, nur wenn der 24/7 läuft greift das nicht, aber vielleicht geschieht das inzwischen schon wenn man den Tab schließt.
Torben S. schrieb: > Aus welchem Grund speichern so viele Webseiten, Daten in Cookies? Wenn du dich mit deinem Account identifizieren wirst, dann wird eventuell alles auch aus der Datenbank ausgelesen. Doch, wenn du nicht angemeldet bist, dann woher soll die Seite wissen deine vorherigen Vorlieben? Aus den Cookies.
Torben S. schrieb: > Verstehe. Allerdings würde es in diesem Fall ja ausreichen einfach nur > eine ID in einem Cookie zu speichern und die restlichen Informationen > wie Sucheinträge, Wunschlisteneinträge etc. mit Referenz auf diese ID in > der Datenbank. Und sich damit die lokalen Speichermedien vollmüllen? Das würde doch kein halbwegs intelligenter Entwickler machen, oder? Sicherheitsrelevantes Zeugs, keine Frage: das gehört nicht in clientseitige Speicher, sondern serverseitig gespeichert. Aber Suchanfragen und Kundenhistorien?
Xanthippos schrieb: > Das wird von Subunternehmern koordiniert, die sich nur um Akquise und > Kundenbetreuung kümmern, keine Ahnung von der Technik haben. Die > Entwicklung vergeben die an weitere Subunternehmen. > > Jedes Scrum Team trifft eigene Entscheidungen. Daten als Cookies > abspeichern können die selbst implementieren. Für einen Datenbankserver > müssten die sich über zig Wasserkopfabteilungen hinweg mit dem > Subunternehmen für den Server koordinieren. Du hast noch nie für den Betreiber einer Webseite mit viel Traffic und großen Kunden- und Produktdatenbanken gearbeitet, kann das sein?
Sheeva P. schrieb: > Du hast noch nie für den Betreiber einer Webseite mit viel Traffic und > großen Kunden- und Produktdatenbanken gearbeitet, kann das sein? Was hat Ihrer Meinung nach Xanthippos falsch geschrieben? Wenn Sie konkret auf seiner Worte zugehen würden, dann ist es viel besser, als irgend etwas ihm zu unterstellen. Ich kann ihm aber zustimmen, dass gerade heute mit viellen agilen Anstrengungen - genau das Gegenteil entsteht. Keiner hat für den gesamten Prozess den E2E Überblick. Es ist mehr Silo-Denken entstanden, als früher der Fall war. Dazu noch - keiner trägt irgendeine Verantwortung. Egal wofür. Fürs Falsch-Planen,für Falsch-Umsetzen, für Nicht-Termintreue, für schlechte Qualität usw - für nichts. Und noch eine Sache, die zum Thema sehr passt. Obwohl es eigentlich agil heißt, sind die Umsetzungs-Prozesse egal wofür unglaublich langsamer geworden. Und viele Anforderer wissend, dass der Sprint/PI/usw. für irgendeine Anforderung mehere Wochen oder Monate dauern wird, überlegen sich Workarounds. Und in den Cookies etwas mehr zu speichern - kann genauso so ein Workaround sein. Und bitte - mir brauchen Sie nicht zu schreiben, dass ich die Abläufe nicht kenne. Seit mehr als 7 Jahre bin ich drin in solchen, agilen Entwicklungen.
Ich hatte in letzter Zeit auch diverse Probleme weil unser Verwaltungssystem mit Weboberfläche damals in mehrere Domains aufgeteilt wurde für Kunden/themen/Mitarbeiterbereich bei verschiedenne Hostern, allerdings komplett verknüpft.. Ja und heute nennt sich das Drittanbietercookie ;) Ich musste alles auf Subdomains umstellen damit die cookie Systemübergreifend funktionieren. Du wirst auch beim storage das gleiche Problem bekommen, wenn es sicher bleiben soll.. Das sind nur Workarounds.
:
Bearbeitet durch User
Val D. schrieb: > Was hat Ihrer Meinung nach Xanthippos falsch geschrieben? Wenn Sie > konkret auf seiner Worte zugehen würden, dann ist es viel besser, als > irgend etwas ihm zu unterstellen. Er schreibt -- nicht nur hier -- so viel Unfug, daß nicht einmal das Gegenteil richtig wäre. > Ich kann ihm aber zustimmen, dass gerade heute mit viellen agilen > Anstrengungen - genau das Gegenteil entsteht. Keiner hat für den > gesamten Prozess den E2E Überblick. Es ist mehr Silo-Denken entstanden, > als früher der Fall war. Dazu noch - keiner trägt irgendeine > Verantwortung. Egal wofür. Fürs Falsch-Planen,für Falsch-Umsetzen, für > Nicht-Termintreue, für schlechte Qualität usw - für nichts. Mit dem "Silo-Denken", das Du unterstellst, wären die Realisierung und der Betrieb moderner High-Traffic-Websites gar nicht möglich. Mag sein, daß das bei der kleinen Internetagentur im Hinterhof so läuft, aber bei sehr großen Webseiten läuft das definitiv nicht so. Dazu kann man sich auch recht leicht einen kleinen Einblick verschaffen, indem man mal darauf schaut, was diese Anbieter als OpenSource-Software anbieten: die verteilten Streamprocessing-Frameworks Apache Storm und sein Nachfolger Apache Heron stammen von Twitter, der PostgreSQL-Cluster Patroni von Zalando, das ML-Framework PyTorch und das NLP-Framework fastText von Meta (Facebook) -- und das sind nur ein paar Beispiele aus dem Backend. Die Geschichte mit dem Falsch-Planen, Falsch-Umsetzen, Nicht-Termintreue und so weiter waren im Übrigen überhaupt erst der Grund dafür, warum die agilen Methoden entwickelt wurden. Die klassische Softwareentwicklung aus dem Lehrbuch mit Lasten- und Pflichtenheft funktioniert mit zunehmender Projektgröße, -Komplexität und -Dauer nämlich nicht mehr, sogar dann wenn die Ersteller der Lasten- und Pflichtenhefte von vorneherein alles bedacht haben. Während der Laufzeit eines größeren Projekts ist es zudem nicht mehr die Ausnahme, sondern die Regel, daß Anforderungen sich ändern: sei es weil der Gesetzgeber oder sei es, weil der Kunde sich was Neues ausgedacht hat. Vor einigen Jahren habe ich mal eine Studie gelesen, daß 80% der Projekte im Softwarebereich die Zeit, das Budget oder beides gesprengt haben oder die gestellten Erwartungen nicht erfüllt haben. Die neueste Studie, die ich dazu gelesen habe, spricht nurmehr von 66% -- was ich persönlich immer noch sehr viel finde, aber trotzdem eine kleine Verbesserung darstellt, und das vor dem Hintergrund, daß die meisten mir von innen bekannten Unternehmen bei ihrer agilen Entwicklung gerne... "kreative" Wege gehen, die mit den agilen Ideen nicht unbedingt immer kompatibel sind. > Und noch eine Sache, die zum Thema sehr passt. Obwohl es eigentlich agil > heißt, sind die Umsetzungs-Prozesse egal wofür unglaublich langsamer > geworden. Wirklich? Das glaube ich nicht. Meine Sicht ist, daß die Anforderungen im Laufe der Jahre wesentlich gestiegen und immer komplexer geworden sind. Zu der Zeit, als ich bei Sun Microsystems gearbeitet und mit Hochverfügbarkeit angefangen habe, da ging es nur um Ausfallsicherheit. Heute geht es um ganz andere Dinge, insbesondere um Performance und Skalierbarkeit. Klar, so eine kleine Flask- oder Django-Webapplikation mit PostgreSQL-Backend kann ich auch heute noch ratzfatz runterschreiben. Aber das skaliert dann halt nicht mehr über 10 Millionen Besucher mit 200 Millionen Pageviews täglich, da muß ich mir schon ein paar sehr kluge Tricks einfallen lassen. Und wenn man die Webseiten der 90er oder 2000er mit den heutigen SinglePage-Webapps oder gar mit Programmen wie Google Docs, MS Teams, oder den Produkten von Atlassian vergleicht, stellt man sehr schnell fest: Webentwicklung ist heute deutlich komplexer und komplizierter geworden, sogar wenn man dabei den Aspekt der Skalierbarkeit kurz mal außen vor läßt. Und deswegen geht das auch heute gar nicht mehr anders, als mit Frameworks und allerlei Helferlein zu arbeiten. Entwickel' doch mal eine Website mit sagen wir, React oder Angular oder Bootstrap mal von Hand nach, so wie wir das früher gemacht haben. Ich bin gespannt, was unsere Urenkel dazu sagen werden, wenn Deine Website dann irgendwann mal online geht. > Und bitte - mir brauchen Sie nicht zu schreiben, dass ich die Abläufe > nicht kenne. Seit mehr als 7 Jahre bin ich drin in solchen, agilen > Entwicklungen. Wie gesagt: die Geschichte mit den Teams und den Verantwortlichkeiten ist doch nun wirklich nichts neues, das gab es schon vor agilen Prozessen. Die agilen Prozesse versuchen, Dinge wie steigende Komplexität, Feature Creep, Out-of-Time und Out-of-Budget in den Griff zu bekommen, Veränderungen und Probleme möglichst früh zu sehen und dem entgegen zu wirken. Und ich habe nach gut 30 Jahren in der Entwicklung auch den Eindruck, daß das relativ gut funktionieren würde, wenn da nicht noch ein anderes Problem wäre... Du kennst sicherlich den unter Entwicklern beliebten Ausspruch: "immer wenn man etwas idiotensicher gemacht hat, kommt die Natur und erfindet bessere Idioten". Das läßt sich sinngemäß auch auf die erwähnte Sache mit der oben erwähnten Komplexität übertragen: "immer wenn wir Methoden gefunden haben, um mit der gestiegenen Komplexität umzugehen, kommen die Kunden (die Natur, der Gesetzgeber, die User... you name it) und fordern mehr Komplexität" -- und dann stehen wir wieder vor der Frage, wie wir sie beherrschen können. Insofern ist es einfach vollkommen inkompetent zu behaupten, daß agile Methoden das Problem wären. Das Problem gab es schon lange, lange vorher, und die agilen Methoden sind ein Lösungsansatz dafür sein. Dieser Ansatz mag nicht optimal sein und stößt gerade auch bei älteren Entwicklern oft auf Ablehnung und Widerstand. Aber da ist es ein bisschen so wie mit der Wissenschaft, die ja auch nur beste aktuelle Stand des Irrtums ist, oder wie mit Churchills Aussage über die Demokratie: sie sei die schlechteste aller Regierungsformen mit Ausnahme aller anderen, die von Zeit zu Zeit versucht worden seien. Wer weiß, vielleicht hast Du eine Idee, wie sich steigende Anforderungen, steigene Komplexität, kürzere Releasezyklen und all diese Dinge besser, schöner, angenehmer und im Idealfall einfacher realisieren ließen. Aber Methoden aus der Steinzeit mit Lasten- und Pflichtenheften haben damals schon nicht gut funktioniert und würden es heute noch viel weniger. Trust me on this one: been there, done that, got the t-shirt.
Sheeva P. schrieb: > Mit dem "Silo-Denken", das Du unterstellst, wären die Realisierung und > der Betrieb moderner High-Traffic-Websites gar nicht möglich. Mensch, Sie weichen gewaltig vom Thema ab. Die Frage war wieso in der Zeit der vielen Datenbanken, einiges bis vieles in Cookies doch gespeichert wird. Die Frage war nicht - welche Größe eine Seite besitzt, welche Ausfallsicherheit gewährleistet wird usw. Ein kleines Feedback zu ihrer Überzeugung vom Agil. Ein Atomkraftwert, eine MRT, eine Brücke über einen Fluss, eine Bahn, ein Auto, ein Flugzeug, ein Hochhaus, eine Ampel und ähnliches stehen für Qualität und Zuverlässigkeit. All diese Produkte werden bis heute nach Lastenheften und Pflichtenheften gebaut. Auch, wenn dort viel Software drin ist. Eine Webseite steht für nichts, wenn eine Webseite nicht funktioniert, dann sind es max. unzufriedene Kunden. Die totale Ausfälle von WhatsApp und Co. haben das bewiesen. Bei den oberen Produkten steht das Leben dieser Kunden auf dem Spiel. Daher - bitte mehr Respekt vom alten und "idiotischen", jedoch klassischen Projektmanagement.
Hm, ich hab jetzt nicht alles gelesen, aber evtl. kann ich ein paar Dinge aus der Praxis dazu sagen. Niemals eine Datenbank durch Cookies ersetzen. Cookies sind von der Webseite aus gesehen öffentlich und alles andere als sicher. Du hast damit eine Datenbank, die der Benutzer komplett lesen, verändern oder wenn er Lust hat auch zerstören kann. Also Du hast kein bißchen Sicherheit, darfst dem Inhalt der Cookies keinesfalls vertrauen. Der Benutzer könnte sich auch Späße erlauben, wie "Zahl=123" in "Zahl=EinsZweiDrei" zu ändern. Ein bißchen Paranoia schadet hier nicht, jeder User ist ein potentieller Angreifer, genau weiß man das immer erst hinterher. Richtig schlimm wird's, wenn man unverifiziert Referenzen auf Daten in Cookies speichert, bspw "BenutzerVerzeichnis=/user123/home" - das lädt geradezu dazu ein, diesen Pfad zu ändern, zB. mal zu schauen was user122 und user124 so treiben, oder ob sowas wie "/../admin" funktioniert. Was ich mache, um sowas sicher zu kriegen, in Cookies von "meinen" Webseiten bzw. die ich geschrieben habe, gibt's nur noch eine Benutzer-ID und einen schwachen Login-Schlüssel mit ordentlicher Länge. Damit wird ein schwacher Login ausgeführt, heißt die Seite erkennt dich, du kannst alles sehen, aber wenn du kritische Dinge machen willst wie Kennwort/Userdaten ändern oder als Beispiel Guthaben transferieren, dann kommt noch ein "starker" Login mit Kennwort eingeben, 2FA wenn nötig. Wenn besonders geschützte Informationen angezeigt werden sollen, könnte man den ebenfalls anfordern, aber ein Warenkorb fällt da nicht drunter. Eine Seite wie ein Webshop ist auch sehr daran interessiert, daß man sofort auf das gewünschte Produkt kommt und es dem Warenkorb möglichst schnell hinzufügen kann. Dafür führen viele Seiten sogar sowas wie ich nenne das "blinde Logins" durch, heißt sie weisen einem unbekannten Benutzer sofort einen "schwachen Login" zu um ihn daran wiederzuerkennen und seinen Warenkorb speichern zu können, aber ohne Benutzerdaten. Diese werden erst abgefragt wenn man z.B. tatsächlich etwas kaufen möchte, dann muss man ein Kennwort wählen und bekommt einen "echten" Account. Wenn der "weak key" lang genug ist, daß ihn ein Angreifer nicht mit realer Chance innerhalb der Cookie-Lebensdauer erraten kann, dann ist das schon sehr sicher. Die maximale Lebensdauer sind so 14..30 Tage, ältere "weak keys" akzeptiere ich nicht mehr (dann ist der "schwache" Login halt weg und man muss sich direkt beim Betreten der Seite anmelden). Weak Keys, die korrekt, aber älter als 1..3 Tage sind, werden akzeptiert und anschließend ausgetauscht, heißt gibt einen neuen Cookie mit neuem Key und neuer Lebensdauer. Größere Seiten benutzen nicht nur eine Datenbank, sondern mehrere. Dabei ist meist eine kritische Datenbank vorhanden, in der alle Daten stehen, die für den Betrieb der Seite absolut notwendig sind (bspw. Login-Daten). Dann vielleicht eine weniger wichtige für irgendwelche Produkte, wenn die mal (in Teilen) nicht erreichbar ist, funktionieren weite Bereiche der Webseite trotzdem. Bei einem Webshop könnte man evtl. nicht einkaufen (oder nicht alle Angebote) bis der Fehler behoben ist, hätte aber trotzdem Zugriff auf seine eigenen Accountdaten. Als dritte Ebene wäre evtl. noch eine für den Betrieb der Webseite komplett unwichtige Datenbank, die z.B. Nutzungsstatistiken enthält. Schön wenn man sie hat, aber auch nicht schlimm sollte man diese komplett verlieren oder irrelevant wenn einige Daten falsch/unvollständig sind (z.B. ein paar nicht gezählte Klicks). Ich würde auch sagen, daß Platz in Datenbanken heute sehr preiswert geworden ist. Ich weiß nicht wieso man daran sparen und seine Daten deswegen in Cookies auslagern sollte, wo es keinerlei Sicherheit für Verfügbarbarkeit und Integrität gibt. Agile Softwareentwicklung... jaja, schönes Thema. Auch das hatten wir "früher" schon, da nannte man das noch "code and fix" - und wie sicher oder zuverlässig größere Projekte unter dieser Doktrin werden, hat man auch sehr schön gesehen.
Xanthippos schrieb: > Heutzutage machen die fähigen Leute KI. Ne, als KI wird jeder Mist bezeichnet, obwohl da nichtmal ansatzweise "I" enthalten ist. Aber die Natürliche Intelligenz ist inzwischen so tief gesunken ist, daß man selbst Bubblesort als KI ansieht.
Ben B. schrieb: > Was ich mache, um sowas sicher zu kriegen Man könnte einfach die Daten des Cookies verschlüsselt hinterlegen, was wohl auch gemacht wird. Mit einem der anerkannten Verfahren ist die Wahrscheinlichkeit, dass ein User die Daten gezielt manipuliert, nahe Null – das Einzige, was er hinbekommen wird, ist, den Keks unbrauchbar zu machen (weil’s der Server nicht mehr entschlüsseln kann). Da man in Cookies aber sowieso nur ersetzbare Daten speichert, denn der User kann ja auch mal mit ’nem anderen Endgerät aufschlagen, oder sein System mal aufgeräumt haben, oder auch ein Browser-Addon wie „Cookie Auto Delete“ verwenden. Und man sollte das Szenario im Hinterkopf behalten, dass ein Angreifer auf der Seite des Users auch die ganze Cookie-Datenbank kopieren kann.
> Man könnte einfach die Daten des Cookies verschlüsselt hinterlegen
Man kann vieles machen, ich frage mich da immer was es bringt.
Ich habe Experimente mit einer Checksumme gemacht, die über den
Cookie-Inhalt und einen zusätzlichen Zufallsdaten-Block in der Datenbank
berechnet wurde. Ein Angreifer hat dadurch keine Möglichkeit mehr,
allein eine gültige Checksumme für die Daten eines von ihm manipulierten
Cookies zu berechnen. Aber wie er versuchen könnte, eine
Bruteforce-Attacke gegen den weak key zu fahren, könnte er das genau so
gegen die Checksumme probieren. Daher ist das nicht sicherer als ein
ausreichend langer weak key und ich habe das verworfen.
Verschlüsselung würde ich nur machen wenn ich durch irgendwelche
Umstände gezwungen wäre, Daten beim User (als Cookie) abzulegen, die
dieser aus irgendwelchen Gründen möglichst niemals lesen können soll.
Ansonsten bevorzuge ich Modelle/Ansätze, die auch dann noch sicher sind,
wenn der Angreifer den kompletten Code kennt und an den üblichen
Grundsätzen scheitert. Also an einem starken Passwort mit ausreichender
Länge bzw. an einer Teergrube weil die meisten User eine starke Tendenz
zu schwachen Passwörtern haben (die Frage dahinter wäre wie bekommt man
auch "susi" als Passwort so sicher wie möglich).
Zweites Problem ist wie ich schon angesprochen habe, die Verfügbarkeit
der Daten. Also welcher Schaden entsteht dem User oder dem
Webseitenbetreiber, wenn die Daten im Cookie verschwunden oder zerstört
sind? Ist das völlig egal, ist es zumindest lästig oder ist es
gravierend? Allein daher ist ein Cookie als Datenbank-Ersatz in den
meisten Fällen wohl unbrauchbar.
Ben B. schrieb: > Verschlüsselung würde ich nur machen wenn ich durch irgendwelche > Umstände gezwungen wäre, Daten beim User (als Cookie) abzulegen, die > dieser aus irgendwelchen Gründen möglichst niemals lesen können soll. Eigentlich dachte ich eher an das Verändern, das dabei verhindert wird. Tatsächlich könnte man bei einem asymmetrischen Verfahren den passenden Schlüssel zum Entschlüsseln in einem weiteren Cookie speichern, sodass der User jederzeit schauen kann, was dort gespeichert ist. Gerade als Firma wär’s mir heutzutage wichtig, soviele personenbezogene Daten wie möglich beim User zu speichern – denn was nicht zentral gespeichert ist, kann nicht in Massen rausgetragen werden. Letztlich muss man wohl im Einzelfall schauen, was jeweils sinnvoll und insbesondere auch sinnvoll umsetzbar ist.
> Gerade als Firma wär’s mir heutzutage wichtig, soviele > personenbezogene Daten wie möglich beim User zu speichern > – denn was nicht zentral gespeichert ist, kann nicht > in Massen rausgetragen werden. Das ist ein böser Trugschluss. Sieh das in solchen Fällen mal so, nicht Du bestimmst, wo das Datenleck ist, sondern das bestimmt der ausreichend fähige Angreifer. Spätestens wenn er es irgendwie schafft, auf Deinen Server zu kommen und dort Code zu verändern oder Speicher auszulesen, war's das. Dann kann alles, was User dort machen oder hochladen (egal ob in Form von Dateien oder Cookies, ist technisch das gleiche), umgeleitet oder geleakt werden, egal wo es zuvor gespeichert war. Also man muss sich da definitiv (vor allem rechtlich) absichern, falls Dinge passieren, die nicht immer unbedingt in Deiner Verantwortung liegen müssen. Ein verärgerter User, dessen Daten geleakt wurden, interessiert sich nicht dafür, auf welchem Wege der Angreifer da drangekommen ist und welcher Server-Betreiber dafür evtl. verantwortlich ist - sondern nur wie er dafür möglichst viel Schadenersatz absahnen kann. Es gibt Anwälte, die Betroffenen geradezu sprichwörtlich in den Arsch kriechen, nur um da tätig werden zu dürfen - ich könnte mir vorstellen, daß die da prima dran mitverdienen. Auch dazu habe ich vor einiger Zeit Tests gemacht, die wirklich etwas paranoid waren - eine komplett verschlüsselte Datenbank, die ohne legitimierten User auch nicht vom Server entschlüsselt werden kann. Heißt es gab keine Schlüssel im Code, sondern einen Hauptschlüssel (lang und zufallsgeneriert), der mit allen User-Schlüsseln verschlüsselt war. Kein User kannte den Hauptschlüssel, ein Verlust aller User-Schlüssel hätte den Verlust der kompletten Datenbank bedeutet. Einem Angreifer hätte man den kompletten Programmcode und die komplette Datenbank in die Hand drücken können, er hätte damit nichts anfangen können solange die verwendeten Schlüssel und Verschlüsselungsfunktionen sicher sind. Aber selbst das wäre nicht davor sicher, daß der Angreifer den Server selbst kompromittiert und evtl. Logins legitimer User loggt, egal ob durch Modifikation des Codes oder ein anderes Programm, was sowas mitlesen kann.
Ben B. schrieb: > Spätestens wenn er es irgendwie schafft, auf Deinen > Server zu kommen und dort Code zu verändern oder Speicher auszulesen, > war's das. Der typische Angreifer macht aber nicht solche Sonderlocken – die Leute müssen auch ökonomisch arbeiten. Stattdessen greift er, was sich möglichst schnell und unauffällig greifen lässt. Solange ich also kein besonders wertvolles Ziel bin, ist die Wahrscheinlichkeit eher gering, dass ein Angreifer derartige Ressourcen in mich investiert. Ausgeschlossen ist’s hingegen nicht – aber das ganze Spiel ist letztlich ein Spiel der Wahrscheinlichkeiten. Ben B. schrieb: > Ein verärgerter User, dessen Daten geleakt wurden, interessiert > sich nicht dafür, auf welchem Wege der Angreifer da drangekommen ist und > welcher Server-Betreiber dafür evtl. verantwortlich ist - sondern nur > wie er dafür möglichst viel Schadenersatz absahnen kann. Wenn beim User gespeicherte Daten dort ausgeleitet worden sind, und man nicht nachweisen kann, dass die Daten über etwa das weiter oben von dir genannte Szenario über mich abhandengekommen sind, dann kann er von soviel Schadenersatz träumen, wie er möchte. Kann sich dann ja selbst auf Zahlung desselben verklagen …
Na in dem Moment wo man nicht nachweisen kann, wie oder auf welchen Wegen die Daten geleakt wurden, hat sich das doch sowieso erledigt... oder wie soll man dann irgendwem eine Schuld nachweisen? Man wird sich als Firma aber nie davor schützen können, daß z.B. ein untreuer Mitarbeiter seiner Firma schadet, indem er z.B. solche internen Daten verkauft oder weitergibt. Das ist verdammt großen Playern wie als bestem Beispiel der NSA nicht gelungen... möchte nicht wissen, wo die eigene IP und Metadaten heute überall landen, wenn man nach Edward Snowden googelt.
Ben B. schrieb: > Man wird sich als Firma aber nie davor schützen können, daß z.B. ein > untreuer Mitarbeiter seiner Firma schadet, indem er z.B. solche internen > Daten verkauft oder weitergibt. Das ist verdammt großen Playern wie als > bestem Beispiel der NSA nicht gelungen. Wie gesagt: es geht um Wahrscheinlichkeiten. Völlige Sicherheit gibt es bekanntermaßen nicht. Und auch ein untreuer Mitarbeiter hat erheblich mehr Aufwand, die Daten von jedem Kunden einzeln auszulesen, wenn dieser sich einloggt, als eine komplette Datenbank einmal zu kopieren und rauszutragen; außerdem würde das weit eher auffallen. Die Wahrscheinlichkeit wäre also auch hier geringer, wenn die Daten nicht in der Firma vorliegen. Und die NSA ist eher Teil des Problems, indem sie beispielsweise Kenntnisse über Sicherheitslücken für den Missbrauch durch sie selbst zurückhält – den Laden würde ich nun nicht ernsthaft anführen. Ben B. schrieb: > Na in dem Moment wo man nicht nachweisen kann, wie oder auf welchen > Wegen die Daten geleakt wurden, hat sich das doch sowieso erledigt... > oder wie soll man dann irgendwem eine Schuld nachweisen? Ist nicht so schwer: wenn der klagende Kunde der Einzige im Kundenstamm ist, dessen Daten ausgeleitet wurden, dann kann man mit einiger Sicherheit davon ausgehen, dass die Daten auf seiner Seite abgegriffen worden sind.
Val D. schrieb: > Sheeva P. schrieb: >> Mit dem "Silo-Denken", das Du unterstellst, wären die Realisierung und >> der Betrieb moderner High-Traffic-Websites gar nicht möglich. > > Mensch, Sie weichen gewaltig vom Thema ab. Ehre, wem Ehre gebührt: es war nicht Sheeva, der mit dem "agile Entwicklung ist unser Untergang" angefangen hat. > Ein kleines Feedback zu ihrer Überzeugung vom Agil. Ein Atomkraftwert, > eine MRT, eine Brücke über einen Fluss, eine Bahn, ein Auto, ein > Flugzeug, ein Hochhaus, eine Ampel und ähnliches stehen für Qualität und > Zuverlässigkeit. All diese Produkte werden bis heute nach Lastenheften > und Pflichtenheften gebaut. Die Komplexität moderner Software mit einer Ampel oder einer Brücke gleichzusetzen, erscheint mir zumindest... sagen wir: gewagt. > Auch, wenn dort viel Software drin ist. Also irgend etwas stimmt an Deinen Ausführungen nicht, denn die Autobauer wie VW, BMW und Porsche, genauso wie Siemens als Kraftwerksbauer, Airbus und Boeing als Flugzeughersteller setzen allesamt auf agile Methoden, und Boeing war 2008 sogar ein "early adopter". > Eine > Webseite steht für nichts, wenn eine Webseite nicht funktioniert, dann > sind es max. unzufriedene Kunden. Die totale Ausfälle von WhatsApp und > Co. haben das bewiesen. So ein Unsinn... sowas kann natürlich immer passieren, und zwar vollkommen unabhängig von der Entwicklungsmethode. Den ersten klassischen HA-Cluster der Website "Formel1.de" hat seinerzeit ein Kollege offline genommen, der gleichzeitig auf beiden Maschinen fehlerhafte Patches eingespielt hat und sich nicht die Zeit nehmen wollte, auf den Reboot der ersten zu warten... > Bei den oberen Produkten steht das Leben dieser > Kunden auf dem Spiel. Daher - bitte mehr Respekt vom alten und > "idiotischen", jedoch klassischen Projektmanagement. Nö, sicher nicht. "Respekt" ist heute eh so ein Wieselwort, das alle und jeder für sich einfordern, vor allem auch jene, die anderen nicht einen Funken desselben entgegenbringen wollen. Und jetzt fordern sogar schon Entwicklungsprozesse "Respekt" für sich ein? OMG. PS: In diesem Forum sprechen wir uns üblicherweise mit "Du" an.
Ben B. schrieb: > Niemals eine Datenbank durch Cookies ersetzen. Cookies sind von der > Webseite aus gesehen öffentlich und alles andere als sicher. Du hast > damit eine Datenbank, die der Benutzer komplett lesen, verändern oder > wenn er Lust hat auch zerstören kann. Also Du hast kein bißchen > Sicherheit, darfst dem Inhalt der Cookies keinesfalls vertrauen. Durch Verschlüsselung kann man die Daten durchaus sichern, wenn man will. > Größere Seiten benutzen nicht nur eine Datenbank, sondern mehrere. Kluge benutzen sogar häufig mehrere verschiedene Datenbanktechnologien, beispielsweise ein klassisches relationales DBMS, einen In-Memory-Key-Value-Store für hochperformante Dinge, und eine Volltext-Suchmaschine für Daten, die effizient abgefragt und durchsucht werden sollen, ohne daß die Sicherheits- und Konsistenzgarantien eines RDBMS notwendig sind. > Ich würde auch sagen, daß Platz in Datenbanken heute sehr preiswert > geworden ist. Ich weiß nicht wieso man daran sparen und seine Daten > deswegen in Cookies auslagern sollte, wo es keinerlei Sicherheit für > Verfügbarbarkeit und Integrität gibt. Weil Cookies für Daten, die weder sicherheitsrelevant noch für die Kernfunktionalität der Seite wichtig sind, komplett kostenlos sind. Es ist zwar nicht ganz falsch, daß Speicherplatz heute nicht mehr teuer ist, aber die Ressourcen, die ein relationales DBMS benötigt, sind in vielerlei Hinsicht sehr, sehr teuer, und leider nur mit noch viel größeren Aufwänden verteil-, replizier- und skalierbar. > Agile Softwareentwicklung... jaja, schönes Thema. Auch das hatten wir > "früher" schon, da nannte man das noch "code and fix" - und wie sicher > oder zuverlässig größere Projekte unter dieser Doktrin werden, hat man > auch sehr schön gesehen. Richtig. Deswegen kann ich auch immer wieder nur den Kopf schütteln, wenn Entwickler gegen agile Methoden wettern oder gar dagegen, externe, weithin genutzte und getestete Libraries und Frameworks zu benutzen -- oder Fehler und Probleme bei der Entwicklung, dem Testing, dem Deployment oder dem Betrieb auf die Methode oder die Nutzung fremden Codes schieben. Exakt dieselben Probleme (plus NIH!) hatten wir nämlich auch schon, als jeder noch alles selbst geprokelt hat.
Jack V. schrieb: > Wie gesagt: es geht um Wahrscheinlichkeiten. Völlige Sicherheit gibt es > bekanntermaßen nicht. Gerade bei den Keksen und anderen Formen lokaler Datenspeicherung durch Webseiten kann man das übrigens auch wunderbar als Honeypot benutzen: die Suchqueries des Benutzers als verschlüsselte Cookies setzen und wenn ein Benutzer dreimal Daten geliefert hat, die der Server nicht entschlüsseln konnte, wird der Benutzer sofort gesperrt. :-) Aber für sicherheitsrelevante Daten bin ich ganz bei Ben: die müssen serverseitig gespeichert und vorgehalten werden. Danach hängt die ganze Sicherheit natürlich sehr wesentlich an der Session-ID, Session Hijacking ist bei der OWASP immer noch ein heißes Thema -- nicht nur, aber auch in Kontexten wie MITM, MITB und XSS.
Torben S. schrieb: > Hallo allerseits, > > Frage: Aus welchem Grund speichern so viele Webseiten, Daten in Cookies? > Warum speichern Sie die Daten nicht einfach in ihren eigenen > Datenbanken. Hat das Performance-Gründe? Vor der Drittanbieter Cookie Sperre gab es ja af***iate Cookies die als Bypass von einer Marketing Firma verwaltet wurden. Heute ist das glaube ich dsgvo Konformität. Was du im Cookie hast müssen die nicht speichern und belasten auch keine Server. Ich kann mich noch an die Zeit vor 10 Jahren erinnern.. da hat man etwas auf Otto gesucht, das hat dich dann in kleinen Werbefenstern als aff***ate Werbung über Conrad, Völkner, bild.de etc. verfolgt.
:
Bearbeitet durch User
Cookies für Werbung alleine finde ich nur lästig, aber nicht sicherheitsbedenklich. Also bspw. ein Cookie mit "MachWerbungFür=Funkenflug Industries" bringt angepasste Werbung über verschiedene Websites, aber mehr nicht (ein bestimmter User kann nicht zugeordnet werden weil viele User den identischen Cookie haben). Erstens ist es für den Benutzer technisch belanglos, was da für Werbung eingeblendet wird und zweitens schießt jeder gesunde Mensch die heute sowieso mit einem Adblocker ab sobald er von der nervigen Scheiße genug hat. Da wird im Internet und anderen Medien ja heute dermaßen mit übertrieben, daß der eigentliche Content weit in den Hintergrund gerät und man fast schon direkt zur Nutzung eines Adblockers genötigt wird. Ansonsten klaut mir Werbung einfach Traffic (Handy-Tarife) oder Lebenszeit (Youtube) bzw. beides. Kritischer wäre ein Cookie mit "UserTrackingID=encryptedID", wodurch ein bestimmter User eindeutig und IP-übergreifend über mehrere Internetseiten verfolgt werden kann. Damit kann man je nach Größe des eigenen Netzwerks ziemlich gute Benutzerprofile erstellen, die dann weitere Rückschlüsse durch Data Mining usw. zulassen. Das finde ich wesentlich bedenklicher als ein bißchen personalisierte Werbung. Leider sind die Grenzen fließend und werden teilweise sehr großzügig ausgelegt (z.B. eine eindeutige ID wäre zum Ausliefern personalisierter Werbung technisch notwendig und niemand weiß, was sonst noch alles mit der ID gemacht wird). Aus diesem Grund bin ich auch kein großer Fan von Verschlüsselung mehr, wo sie nicht zwingend gebraucht wird, sondern finde Transparenz begrüßenswert. Bei einem Cookie wie oben "MachWerbungFür=Klartext" weiß ich was das ist und kann das einschätzen, bei einem Cookie wie "Blah=[encrypted Blub]" weiß ich schlicht gar nichts - außer, daß jemand was vor mir verstecken möchte und dann wird's erst recht interessant. Für Sessions braucht man die Cookies leider, bzw. der User muss zwingend bei jedem Request etwas mitschicken, woran er identifiziert werden kann wenn er das möchte. Ich hatte mir in der Zeit bevor diese ganzen Sicherheitsbedenken aufkamen einen eigenen Session-Handler gebaut und entsprechende IDs in den Links mitgeschickt (grob abgesichert durch Abgleich mit der beim Login verwendeten IP, die in der Datenbank hinterlegt wurde), aber das ist kein Sicherheitsgewinn gegenüber PHP-Sessions (allerdings auch kein großer Verlust). PHP-Sessions funktionieren ohne Cookies auf die gleiche Weise, dann wird z.B. ein "PHPSESSID=[blah]" in den Links sichtbar. > wenn ein Benutzer dreimal Daten geliefert hat, die der Server > nicht entschlüsseln konnte, wird der Benutzer sofort gesperrt. :-) Sowas wird ein Eigentor. Um den Benutzer/Angreifer gezielt sperren zu können, müsstest Du ihn bereits zweifelsfrei identifiziert haben und wenn der Angreifer das schafft, bringt Dir der Rest keinen Sicherheitsgewinn mehr. Sperrt man ohne einen solchen Check, fliegt nur die IP in eine temporäre Sperrliste oder der User ist so blöde, einen "IchBinGesperrt"-Cookie mitzuschicken, der 'ne Lebensdauer von einem Tag oder so hat. Neue IPs gibt's wie Sand am Meer und es gibt legitime Benutzer, die standardmäßig über eine wechselnde IP ankommen ohne daß die das beeinflussen können (gerne bei mobilem Internet zu sehen). Wenn man einen User schon sperrt, wenn der Benutzername stimmt, aber 3mal das falsche Passwort eingegeben wird, ist das eine Einladung für einen wirkungsvollen DOS-Angriff. Ich versuche das auf "meinen" Seiten zu verhindern, indem der Login-Name nichts mit dem tatsächlichen Benutzernamen zu tun haben muss und ich verdächtige Aktivitäten unsichtbar sperre. Also beispielsweise der Angreifer hat einen korrekten Benutzernamen und probiert Passwörter aus, wird er nach dem x-ten Versuch unsichtbar gesperrt, heißt IP und Benutzername bekommen für eine bestimmte Zeit nur noch "User nicht bekannt oder Passwort falsch" zurück - auch wenn in dieser Zeit das korrekte Passwort eingegeben wird. Der Angreifer kann somit nicht erkennen ob er gesperrt wurde und das Ergebnis seines Passwort-Scans wird unzuverlässig. Das ist zwar auch eine DOS-Möglichkeit für die Dauer des Angriffs, aber nicht so schlimm wie eine Sperre für 24 Stunden oder so und immer noch besser als ein erfolgreicher Angriff.
Ein T. schrieb: > Die Komplexität moderner Software mit einer Ampel oder einer Brücke > gleichzusetzen, erscheint mir zumindest... sagen wir: gewagt Ich kann nicht garantieren, aber gefühlt - mehr als 50% aller Software in der Welt sind nicht komplexer als eine echte Ampel-Steuerung. Die alles andere als einfach ist. Dazu noch Ampel wurde in der Reihe mit anderen, viel komplexeren Produktarten aufgezählt. Daher - wozu Sie diesen Vergleich reinwerfen - habe ich nicht verstanden.
Na an einer Ampel-Steuerung hängen Leben. Angenommen der Linksabbiegerpfeil bekommt grün während der Geradeausverkehr der Gegenspur noch grün hat, gibt's sofort einen großen Haufen und mindestens Schwerverletzte. Sowas wirklich zuverlässig auszuschließen, auch wenn Programmfehler oder Hardwaredefekte ins Spiel kommen, ist ein echtes Problem!
Für Cookies bzw. Session Daten benutze ich z.b. serialisierte base64 kodierte Json Objekte. Klar kann das jeder sofort knacken und gegebenfalls erkennen.. da steigen aber die meisten erstmal garnicht durch ;) Ich weiß jetzt garnicht, theoretisch geht das mit den Werbecookies doch garnicht mehr.. die ersten Browser Blocken mitlerweile Cookies von Fremddomains in iframe oder jscript. Also die vertrauen unumgänglich nur noch auf bild.de dem Cookie von *.bild.de .
Sheeva P. schrieb: > Mag sein, > daß das bei der kleinen Internetagentur im Hinterhof so läuft, aber bei > sehr großen Webseiten läuft das definitiv nicht so. Mag sein, aber es gibt halt nicht nur "sehr große" Websites. Und wie intelligent die Webentwickler waren, dafür git es u.a. folgendes Merkmal: Die Einstellung der Anzahl der Suchergebnisse: keine Wahlmöglichkeit: struntzdumm oder sehr schlau, je nachdem.... 6, 12, 18, 24: dumm. 6, 12, 24, 48, 96: besser 6, 12, 24, 48, 96, (Alle): wenn möglich (Anzahl der Ergebnisse im sinnvollen Rahmen): am besten. Jedenfalls für mich als Anwender. Ich frage mich auch, warum immer die kleinste Zahl der Standarwert ist. Ich komme häufig auf "sehr großen", "modernen" Sites vorbei, die ein katastrophales UI (modern: "UX") haben. Warum? Ich komme auch häufig auf Seiten vorbei, die derart mit Werbung zugemüllt sind, dass sie dadurch unbenutzbar und deshalb (zumindest von mir) sehr rasch wieder verlassen werden. Aber das ist eine andere Sache... ciao Marci
Xanthippos schrieb: > Die Karawane ist weiter gezogen. Um 2000 rum hatten die besten Leute > Webprogrammierung gemacht. Nein, die fähigen Leute haben damals die Konzepte und Systeme zur Webprogrammierung entwickelt. Die Seiten selbst haben damals Hausfrauen zusammengeklickt. Jedenfalls wurde das damals so erzählt. [...] > Heutzutage machen die fähigen Leute KI. Ja, die fähigen Leute entwickeln heute KI-Systeme. Die weniger fähigen basteln sich dann das entsprechende API in die eigene Seite... Das Problem ist: es gibt halt so viele "weniger fähige" Leute. Die wollen ja auch irgend wie überleben. Laut ChatGPT-Hype-Lesart wird das in Zukunft allerdings eher schwierig. ciao Marci
Sheeva P. schrieb: > Während der Laufzeit eines größeren > Projekts ist es zudem nicht mehr die Ausnahme, sondern die Regel, daß > Anforderungen sich ändern: sei es weil der Gesetzgeber oder sei es, weil > der Kunde sich was Neues ausgedacht hat. Das WAR noch nie die Ausnahme, sondern ein Wunschtraum. <SCNR> ciao Marci
> 6, 12, 24, 48, 96, (Alle): wenn möglich (Anzahl der > Ergebnisse im sinnvollen Rahmen): am besten. > > [..] Ich frage mich auch, warum immer die > kleinste Zahl der Standarwert ist. Gegenfrage: Wie oft benutzt Du bei der Google Standardsuche die Seiten 2 und 3? Es kostet (je nach Suchart mal mehr mal weniger) Resourcen, Dir mehr Suchergebnisse rauszukramen, als Du am Ende brauchst bzw. benutzt. > Laut ChatGPT-Hype-Lesart wird das > in Zukunft allerdings eher schwierig. Die gleiche Prognose gab's schon als Wordpress der Meinung war, alle gängigen Webseiten mit ihrem Baukasten ersetzen zu können. Heute sehen die bis auf wenige Ausnahmen alle potthässlich aus, gleichen sich wie ein Ei dem anderen, können immer noch nicht mehr als vielleicht 'ne eMail verschicken und man erkennt sofort, daß weniger Mühe investiert wurde als in die Visitenkarte. Wer will sowas haben? Ich glaube noch nicht, daß sich daran in absehbarer Zukunft bei KI-generierten Webseiten was ändert.
:
Bearbeitet durch User
Ben B. schrieb: > Für Sessions braucht man die Cookies leider, bzw. der User muss zwingend > bei jedem Request etwas mitschicken, woran er identifiziert werden kann > wenn er das möchte. Ich hatte mir in der Zeit bevor diese ganzen > Sicherheitsbedenken aufkamen einen eigenen Session-Handler gebaut und > entsprechende IDs in den Links mitgeschickt (grob abgesichert durch > Abgleich mit der beim Login verwendeten IP, die in der Datenbank > hinterlegt wurde), aber das ist kein Sicherheitsgewinn gegenüber > PHP-Sessions (allerdings auch kein großer Verlust). PHP-Sessions > funktionieren ohne Cookies auf die gleiche Weise, dann wird z.B. ein > "PHPSESSID=[blah]" in den Links sichtbar. Das ist eine wunderbare Idee... wenn man einem Angreifer das Session Hijacking erleichtern möchte. Ich stelle mir da so einen IRC-Chat vor: A: "Du, kannst Du Dich auf example.com einloggen?" B: "Klar, kann ich." A: "Bei mir läuft da irgendwas schief, kannst Du mir bitte mal einen Link schicken?" B: "Na klar, hier hast Du: https://example.com/index.php?PHPSESSID=..."; Nebenbei bemerkt raten die meisten mit bekannten Sicherheitsframeworks dringend davon ab, spezifische Namen wie "PHPSESSID" oder "JSESSIONID" zu verwenden, weil ein Angreifer anhand dieser Namen erraten kann, welche Technologie serverseitig verwendet wird. Entweder man liefert einen ganz anderen Namen -- also "JSESSIONID" für eine PHP-Applikation oder eben umgekehrt -- oder einen generischen Namen wie "SESSIONID". > Ein T. schrieb: >> wenn ein Benutzer dreimal Daten geliefert hat, die der Server >> nicht entschlüsseln konnte, wird der Benutzer sofort gesperrt. :-) > > Sowas wird ein Eigentor. Um den Benutzer/Angreifer gezielt sperren zu > können, müsstest Du ihn bereits zweifelsfrei identifiziert haben Erstens: könntest Du Dir BITTE endlich abgewöhnen, das "xyz schrieb im Beitrag #abc:" zu löschen? Das ist eine sinnvolle Hilfestellung dieses Forums für User, die mal eben den zitierten Beitrag sehen wollen. Auch Leerzeilen zwischen dem Zitierten und Deiner Antwort erleichtern den Lesefluß, und es nervt, wenn Du sie immer löschst. Zweitens: Du hast nicht verstanden, was ich geschrieben hatte. Wenn mein Benutzer mir mehrmals einen verschlüsselten Wert für meinen Cookie liefert, den mein Server aber nicht entschlüsseln kann, dann hat dieser Benutzer ja offensichtlich versucht, meine Cookies zu manipulieren. Sowas macht aber kein normaler Benutzer und kein normaler Browser. Deswegen kann ich in so einem Fall davon ausgehen, daß der Benutzer nichts Gutes im Schilde führt und proaktive Gegenmaßnahmen gerechtfertigt sind. > Sperrt man ohne einen solchen Check, fliegt nur > die IP in eine temporäre Sperrliste Ach, weißt Du, es gibt eine ganze Reihe von Möglichkeiten, Benutzer im Web relativ zuverlässig zu identifizieren, und die IP-Adresse ist dazu sicher keine sonderlich gute. Aber sogar damit kann man schon gute Ergebnisse erzielen: ja, klar, IPs gibt es wie Sand am Meer, aber für den Angreifer bedeutet ein Wechsel seiner IP erst einmal Arbeits- und Zeitaufwände. Da ein Angreifer zudem davon ausgehen kann, daß solche Dinge geloggt werden, dürften zumindest die klügeren Angreifer alsbald dazu übergehen, sich ein leichteres Opfer zu suchen. > Wenn man einen User schon sperrt, wenn der Benutzername stimmt, aber > 3mal das falsche Passwort eingegeben wird, ist das eine Einladung für > einen wirkungsvollen DOS-Angriff. Davon habe ich gar nicht geredet, aber auch das ist natürlich eine gute Idee. Auf Betriebssystem- und anderen Ebenen ist es auch absolut üblich, sowas zu tun. Unter Linux zum Beispiel gibt es dafür eigens das Programm faillock(8) aus den PAM-Modulen, sowie das Programm fail2ban(1), das die Logdaeien nach fehlgeschlagenen Login-Versuchen durchsucht und den Client nach mehr als n davon temporär sperrt. Das provoziert keine DOS-Angriffe, denn dazu müßte ein Angreifer zuerst einen Usernamen erraten. Es sei denn, daß der Benutzername wie bei diesem Forum hier öffentlich gemacht wird, dann hätte ein Angreifer es natürlich leicht, und in solchen Fällen sind solche Setups natürlich nicht sinnvoll. Eine andere gute Idee ist es übrigens, nach jeder Eingabe eines Paßwortes eine Weile abzuwarten, bis der Login durchgeführt oder abgewiesen wird. Damit, und einer Limitierung der möglichen Verbindungen eines Clients auf meine Login-Seite, kann ich die Rate, mit der ein Angreifer verschiedene Paßworte ausprobieren kann -- egal, ob mit einem Wörterbuch oder per Brute Force -- ziemlich wirksam herabsetzen. Nebenbei bemerkt, folgen diese Überlegungen den Ideen der OWASP, also der "Open Source Foundation for Application Security", die security-bewußten Sysops und Codern zweifellos bekannt sein dürfte. Und wenn ich mich recht entsinne, empfehlen auch professionelle Sicherheitsregularien wie PCI-DSS und HIPAA derartige Schutzmaßnahmen.
Val D. schrieb: > Ein T. schrieb: >> Die Komplexität moderner Software mit einer Ampel oder einer Brücke >> gleichzusetzen, erscheint mir zumindest... sagen wir: gewagt > > Ich kann nicht garantieren, aber gefühlt - mehr als 50% aller Software > in der Welt sind nicht komplexer als eine echte Ampel-Steuerung. Ich würde mich da nicht auf prozentuale Anteile festlegen wollen, zumal dabei natürlich auch die Frage nach der Vergleichsmethodik bestünde. > Die alles andere als einfach ist. Die allermeisten Ampelschaltungen sind von überschaubarer Komplexität, deswegen kommt man in diesen Fällen sicherlich auch mit den klassischen "einfachen" Entwicklungsmethoden zurecht. Wie schon oben erwähnt: agile Entwicklung ist ein Werkzeug, um Komplexität in den Griff zu bekommen. Wo eine solche Komplexität nicht vorhanden ist, braucht man natürlich auch keine Werkzeuge, um sie zu beherrschen. > Dazu noch Ampel wurde in der Reihe mit > anderen, viel komplexeren Produktarten aufgezählt. ... auf die ich eingegangen bin. > Daher - wozu Sie > diesen Vergleich reinwerfen - habe ich nicht verstanden. Mir wiederum ist unklar, was Du nicht verstanden hast, aber ich helfe natürlich jederzeit gerne. Die Ampel und die Brücke waren ja nicht meine Beispiele, sondern Deine?!
> Erstens: könntest Du Dir BITTE endlich abgewöhnen, > das "xyz schrieb im Beitrag #abc:" zu löschen? Ich lösche da nichts, ich kopiere mir lediglich die relevanten Textzeilen aus den Postings. > Das ist eine wunderbare Idee... wenn man einem Angreifer > das Session Hijacking erleichtern möchte. Ich stelle mir > da so einen IRC-Chat vor: [..] Deswegen betrachte ich Sessions allgemein als nicht besonders sicher und versuche sie noch auf anderen Wegen sicherer zu machen, aber sobald der Angreifer persönlich mit dem Opfer spricht, wird's immer schwierig. Er kann das Opfer problemlos auf eine Seite locken, welche speziell darauf ausgelegt ist, ihm weitere Informationen (bspw. die IP) zu liefern. Was die SessionID im Link angeht, was willst denn anderes machen wenn aus irgendwelchen Gründen kein POST-Request geht, aber Sessions funktionieren sollen? Alle Web-Anwendungen, wo bei Missbrauch größerer Schaden entstehen kann, sollten sowieso längst zu einer zwingenden 2FA-Maßnahme übergegangen sein wenn so eine Aktion ausgeführt werden soll. Beispielsweise die TAN beim Internetbanking oder eine 2FA-Abfrage bei kritischen Aktionen egal ob der Benutzer eine Session hat, bei der bereits ein starker Login (korrektes Passwort, ggf. plus 2FA) durchgeführt wurde. Dann kann ein Angreifer trotz erfolgreichem Session Hijacking keinen großen Schaden anrichten, weil ihm dazu das 2FA-Gerät fehlt. Allerdings ist manchen Usern echt nicht zu helfen, die geben dem indischen Mitarbeiter einer deutschen Bank auch ihre Teamviewer-ID und schauen dann zu, wie dieser vor ihren Augen den HTML-Quellcode der Bank-Webseite manipuliert, um fiktive Kontostände anzuzeigen. Was willst da machen, wie willst solchen Leuten Internetsicherheit beibringen? > Nebenbei bemerkt raten die meisten mit bekannten > Sicherheitsframeworks dringend davon ab, spezifische Namen wie > "PHPSESSID" oder "JSESSIONID" zu verwenden, weil ein Angreifer > anhand dieser Namen erraten kann, welche Technologie serverseitig > verwendet wird. Das geht mir zu sehr in Richtung Security by Obscurity und ich finde, das war noch nie eine gute Idee. Ich versuche, meine Anwendungen so sicher zu kriegen, daß sie auch von einem Angreifer mit komplettem Wissen bzw. mit Kenntnis des Quellcodes nicht von außen zu brechen sind, bzw. daß das unbekannte Passwort die kleinste Hürde ist. Bei unbekannter Technologie hindert einen Angreifer nichts daran, einfach auf alle möglichen Technologien zu testen bis er ggf. Erfolg hat. Das dauert nicht mal lange wenn da irgendwas angreifbar ist. Man klingelt einfach an allen Türen, vielleicht geht früher oder später eine auf. > [..] Deswegen kann ich in so einem Fall davon ausgehen, daß der > Benutzer nichts Gutes im Schilde führt und proaktive Gegenmaßnahmen > gerechtfertigt sind. Das stimmt, allerdings weißt Du nicht, ob der Benutzer auch derjenige ist, für den er sich ausgibt. Höchstwahrscheinlich ist er es nicht, wenn man jetzt den User hart für 24h wegknallt, bestraft man ihn für das, was irgend ein unbekannter Angreifer angestellt hat und daraus ergibt sich die DOS-Möglichkeit für einen Angreifer, sobald er den korrekten Login-Namen kennt oder ausreichend viele durchprobieren kann (und für alle einen 24h Bann bestellen kann). Daher bekommst Du bei "meinen" Webseiten auch niemals die Aussage "Passwort falsch", sondern immer nur "User nicht bekannt oder Passwort falsch", "Login-Daten ungültig"... egal ob der Login-Name korrekt war oder nicht. > Da ein Angreifer zudem davon ausgehen kann, daß solche Dinge > geloggt werden, dürften zumindest die klügeren Angreifer alsbald > dazu übergehen, sich ein leichteres Opfer zu suchen. Ganz gefährliche Annahme. Du hast drei Häuser, nur eines davon hat eine gut sichtbare Alarmanlage. In welches Haus möchtest Du als Einbrecher am liebsten rein, wo denkst Du gibt's am ehesten fette Beute zu holen? Nur Scriptkiddies suchen sich ein leichteres Ziel oder wenn jemand ohne großen Aufwand "schnell mal ein paar Bots" braucht. Die kommen mit einem Portscanner oder suchen per Script gezielt nach ihnen bekannten Schwachstellen oder angreifbaren Anwendungen, wenn sie dabei nichts finden ziehen sie weiter. Für die meiner Meinung nach schon eher fähigen Angreifer wird man durch gute Sicherheitsmaßnahmen leider erst richtig interessant. > Eine andere gute Idee ist es übrigens, nach jeder Eingabe > eines Paßwortes eine Weile abzuwarten Das nennt man Teergrube, schrieb ich oben schon bereits.
Val D. schrieb: > Ein kleines Feedback zu ihrer Überzeugung vom Agil. Ein Atomkraftwert, > eine MRT, eine Brücke über einen Fluss, eine Bahn, ein Auto, ein > Flugzeug, ein Hochhaus, eine Ampel und ähnliches stehen für Qualität und > Zuverlässigkeit. All diese Produkte werden bis heute nach Lastenheften > und Pflichtenheften gebaut. Nun ja, zumindest beim Taj Mahal stand im Lastenheft nur sowas wie "höher als alle anderen", im Pflichtenheft dann "schaun wer mal, wie hoch wir kommen". Wie hoch der dann tatsächlich wurde, entschied sich erst während des Baus. Oliver
> Datenbanken. Hat das Performance-Gründe?
Rechtliche Gründe bzgl Speicherort und Nutzerbezogenen Daten.?!
Userdaten auf Firmenrechner gilt als Datenschnüffelei, User-daten auf
User-Rechner (cookies) gilt als Comfort-funktion ...
Ben B. schrieb: >> Erstens: könntest Du Dir BITTE endlich abgewöhnen, >> das "xyz schrieb im Beitrag #abc:" zu löschen? > > Ich lösche da nichts, ich kopiere mir lediglich > die relevanten Textzeilen aus den Postings. Dann kopier doch einfach die Zitatzeilen mit. Meine Güte, das kann doch wohl nicht so schwierig sein. Und wenn man den Link "Markierten Text zitieren" unter den Beiträgen benutzt, ist das sogar komfortabel. >> Das ist eine wunderbare Idee... wenn man einem Angreifer >> das Session Hijacking erleichtern möchte. Ich stelle mir >> da so einen IRC-Chat vor: [..] > > Deswegen betrachte ich Sessions allgemein als nicht besonders sicher Wenn man das richtig macht, dann ist die Sicherheit schon ziemlich hoch. Man muß es halt richtig machen. > Was > die SessionID im Link angeht, was willst denn anderes machen wenn aus > irgendwelchen Gründen kein POST-Request geht, aber Sessions > funktionieren sollen? AJAX existiert, und wenn das nicht funktioniert, dann ist mit sehr hoher Wahrscheinlichkeit etwas an Deinem User Interface kaputt. > Alle Web-Anwendungen, wo bei Missbrauch größerer Schaden entstehen kann, > sollten sowieso längst zu einer zwingenden 2FA-Maßnahme übergegangen > sein wenn so eine Aktion ausgeführt werden soll. Beispielsweise die TAN > beim Internetbanking oder eine 2FA-Abfrage bei kritischen Aktionen egal Super Idee... dann schaffe ich mir schon einmal einen Handkarren und ein Mobiltelefon mit mehr Speicherplatz an, damit ich die ganzen neuen MFA-Geräte und -Apps irgendwie unterbringen und transportieren kann. > Allerdings ist manchen Usern echt nicht zu helfen, Dann versuch's doch nicht, das lohnt sich ohnehin nicht und ist auch nicht Dein, sondern deren Problem. Trotzdem können idiotische Benutzer doch wohl weder als Begründung dafür dienen, auf Sicherheitsmaßnahmen zu verzichten, noch dafür, meine Seiten unbenutzbar zu machen. >> Nebenbei bemerkt raten die meisten mit bekannten >> Sicherheitsframeworks dringend davon ab, spezifische Namen wie >> "PHPSESSID" oder "JSESSIONID" zu verwenden, weil ein Angreifer >> anhand dieser Namen erraten kann, welche Technologie serverseitig >> verwendet wird. > > Das geht mir zu sehr in Richtung Security by Obscurity Du solltest wirklich langsam mal Dein Gehirn einschalten, so vorhanden, und ein bisschen über Sicherheit nachdenken. Wenn ein Angreifer schon durch den Namen Deiner Sessionvariablen herausfindet, welche Technologie Du benutzt, lehnt er sich entspannt zurück und wartet auf eine Sicherheitslücke in der Technologie, die er dann nur noch ausnutzen muß. Dadurch muß er wesentlich weniger Informationen sammeln, wesentlich seltener etwas ausprobieren, hat einen deutlich größeren Aufwand und wird mit geringerer Wahrscheinlichkeit entdeckt -- und mit noch geringerer Wahrscheinlichkeit frühzeitig entdeckt. Dem Angreifer relevante Infos frei Haus zu liefern, halte ich weder für der Sicherheit förderlich noch aus anderen Gründen für klug, zumal alles, was Du dagegen tun müßtest, eine winzige Konfigurationsänderung wäre. Wow. Aus demselben Grund empfehlen die OWASP und alle anderen mir bekannten Sicherheitsframeworks, -Regularien und -Richtlinien, die Serversignatur abzuschalten oder zu verschleiern. Normaler Benutzer sehen die ohnehin niemals und brauchen sie auch nicht. Aber vermutlich sind die, die diese Empfehlungen, Hinweise und Vorschriften entwickeln, alle doof und setzen auf "security by obscurity"... na klar. > Bei unbekannter Technologie hindert einen Angreifer nichts daran, > einfach auf alle möglichen Technologien zu testen bis er ggf. Erfolg > hat. Das dauert nicht mal lange wenn da irgendwas angreifbar ist. Man > klingelt einfach an allen Türen, vielleicht geht früher oder später eine > auf. Das hinterläßt aber Spuren... die man dann entweder postmortem oder sogar proaktiv auswerten kann. Anomalieerkennung existiert. >> [..] Deswegen kann ich in so einem Fall davon ausgehen, daß der >> Benutzer nichts Gutes im Schilde führt und proaktive Gegenmaßnahmen >> gerechtfertigt sind. > > Das stimmt, allerdings weißt Du nicht, ob der Benutzer auch derjenige > ist, für den er sich ausgibt. Kombinationen aus IP-Adreßbereich, Geolocation und Browser-Fingerprint reichen gemeinhin, um einen Benutzer ganz gut zu identifizieren. Und auf Benutzer, die sich mir und meiner Seite gegenüber krampfhaft verschleiern wollen, kann ich wunderbar verzichten. Da gehts mir dann weniger um deren Privatsphäre, als um die Sicherheit von mir und meinen anderen Benutzern. Denen gegenüber habe ich nämlich auch eine Verantwortung. > Höchstwahrscheinlich ist er es nicht, wenn > man jetzt den User hart für 24h wegknallt, bestraft man ihn für das, was > irgend ein unbekannter Angreifer angestellt hat Nö, denn da gibt es zwei Möglichkeiten: entweder es handelt sich um einen angemeldeten Benutzer -- und dann ist das höchstens dann ein unbekannter Angreifer, wenn er den Account eines legitimen Benutzers geknackt hat, und dann ist es sogar im Interesse meines legitimen Benutzers, wenn ich diesen Angreifer sperre, damit daß er dann keinen Schaden mehr im Account meines Benutzers anrichten kann. Im anderen Fall handelt es sich um einen anonymen Benutzer, und den in den Orkus zu schieben, wenn er an meinen Cookiewerten herummanipuliert, macht mir keine Sekunde Kopfschmerzen. Nein: keine Millisekunde. > Daher bekommst Du bei "meinen" > Webseiten auch niemals die Aussage "Passwort falsch", sondern immer nur > "User nicht bekannt oder Passwort falsch", "Login-Daten ungültig"... > egal ob der Login-Name korrekt war oder nicht. Das ist seit über dreißig Jahren der Standard. >> Da ein Angreifer zudem davon ausgehen kann, daß solche Dinge >> geloggt werden, dürften zumindest die klügeren Angreifer alsbald >> dazu übergehen, sich ein leichteres Opfer zu suchen. > > Ganz gefährliche Annahme. Kein bisschen, meine Logdateien werden ständig auf Anomalien und auf bekannte Muster überprüft. Wer bei mir zum Beispiel eine "/wp-login.php" aufrufen will, ist ohnehin kein legitimer Benutzer: au revoir. > Du hast drei Häuser, nur eines davon hat eine > gut sichtbare Alarmanlage. In welches Haus möchtest Du als Einbrecher am > liebsten rein, wo denkst Du gibt's am ehesten fette Beute zu holen? Genau... deswegen geschehen die meisten Einbrüche auch gar nicht in den teuren Villenvierteln, wo es wirklich etwas zu holen gäbe, sondern die meisten Einbrüche geschehen in den mittleren Wohngegenden, wo es immer noch genug zu holen gibt, aber üblicherweise keine Alarmanlagen vorhanden oder zumindest nicht an den stillen, aber teuren Polizeiruf angebunden sind. > Nur Scriptkiddies suchen sich ein leichteres Ziel oder wenn jemand > ohne großen Aufwand "schnell mal ein paar Bots" braucht. Die kommen mit > einem Portscanner oder suchen per Script gezielt nach ihnen bekannten > Schwachstellen oder angreifbaren Anwendungen, wenn sie dabei nichts > finden ziehen sie weiter. > Für die meiner Meinung nach schon eher fähigen Angreifer wird man > durch gute Sicherheitsmaßnahmen leider erst richtig interessant. Und deswegen soll ich die Sicherheitsmaßnahmen unterlassen, oder was ist jetzt Deine Idee? Auf meinen Maschinen nutze ich etliche Techniken, um mir die bösen Buben vom Hals zu halten, sogar dort, wo es gar keine sensiblen Dinge zu schützen gilt. Bisher haben sich die Mistfinken daran erfolgreich ihre Beißerchen ausgebissen, und bislang bin ich ganz guter Dinge, daß das auch in Zukunft so bleiben wird. >> Eine andere gute Idee ist es übrigens, nach jeder Eingabe >> eines Paßwortes eine Weile abzuwarten > > Das nennt man Teergrube, schrieb ich oben schon bereits. Nein, da geht es um eine Kombination aus Connection Limit und Login Policy, und es betrifft alle Benutzer, damit ein potentieller Angreifer a) nicht in der Lage ist, viele gleichzeitige Login-Versuche zu starten und b) auch aus der Antwortzeit meines Servers nicht darauf schließen kann, daß ein Versuch erfolgreich war. Tarpitting funktioniert ein bisschen anders, und betrifft üblicherweise nur erkannte Angreifer, um ihre Ressourcen zu binden.
Der Grund ist, dass der Entwickler keine Sessions für unauthentifizierte Nutzer einplante. Im Optimalfall würden die Cookies nur Session-Informationen enthalten; diese verlinken dann sozusagen auf Informationen in der Datenbank. Nun gibt es prinzipiell benutzerkontounabhängige Einstellungen wie z. B. einen Dark-Mode. Wenn sich der Nutzer ausloggt, heißt das aber nicht zwangsläufig, dass sich die Person ändert. Ein Ausloggen darf also nicht dazu führen, dass sich diese Einstellung plötzlich ändert. Das wäre zwar logisch, in einigen Fällen aber ungewollt, weil ein Ausloggen nicht gleichzusetzen ist mit dem Verlassen der Seite bzw. mit der Änderung der Person, die die Seite bedient. Trennt der Nutzer durch Ausloggen aber die Verknüpfung zu seinem Nutzerkonto auf, gibt es keine Verknüpfung mehr zwischen Session-ID und dem Datensatz in der Datenbank. Entweder realisiert man also die Funktionalität von Sessions für unauthentifizierte Nutzer oder man speichert diese Informationen stattdessen benutzerkontounabhängig in Cookies.
Andreas schrieb: > Der Grund ist, dass der Entwickler keine Sessions für unauthentifizierte > Nutzer einplante. Bitte entschuldige, aber das halte ich für Unsinn, weil... > Trennt der Nutzer durch Ausloggen aber die Verknüpfung zu seinem > Nutzerkonto auf, gibt es keine Verknüpfung mehr zwischen Session-ID und > dem Datensatz in der Datenbank. Entweder realisiert man also die > Funktionalität von Sessions für unauthentifizierte Nutzer oder man > speichert diese Informationen stattdessen benutzerkontounabhängig in > Cookies. Die Session bleibt serverseitig bestehen oder wird in eine neue Session überführt, das ist trivial und die Einstellungen in der Session bleiben dabei natürlich erhalten. Der Logout trennt nur die Verbindung zwischen Session und User, sonst nichts.
Na das grundlegende Problem ist, daß HTTP kein zustandsbehaftetes Protokoll ist. Sprich du schickst dem Server eine Anfrage und bekommst eine Antwort, mehr nicht. Als das Internet dann komplexer wurde und dynamische Webseiten eher die Regel als die Ausnahme wurden, wurde das zum Problem. Der Browser schickt weiterhin nur eine Anfrage, diese enthält nicht mehr nur das Ziel, was man haben möchte, sondern auch Daten wie Cookies oder Formulardaten, die man eingegeben oder angeklickt hat. Der Server verarbeitet das (oder auch nicht, es gibt keinen Zwang) und schickt seine Antwort als statisches Dokument, wie eine Momentaufnahme - und das wars. Danach schont er seine Ressourcen und außer in den Logs bleibt nichts von der Abfrage übrig (oder die Seite schreibt irgendwas in ihre Datenbank, aber das hat nichts mit dem HTTP Server zu tun). Sessions sind der Weg, HTTP zumindest über einen bestimmten Zeitraum Zustände zu verleihen (bspw. eingeloggt oder nicht) und Cookies der Weg der Datenübertragung, damit der Server (bzw. genauer das Programm der Internetseite, dem HTTP Server ist das wurscht) einen Benutzer wiedererkennen kann. Das Übertragen der Session-ID ist nichts weiter als die Bitte, erkenne mich anhand dieser ID wieder. Die Standard-Lebensdauer einer Session bei PHP sind 1440 Sekunden (24 Minuten), danach schmeißt die garbage collection die Daten weg. Dabei fällt mir auch noch ein weiteres Problem der Datenspeicherung in Cookies auf: Die Dinger sind maschinenabhängig. Heißt wenn ich solche Daten auf einer Internetseite habe, die in Cookies gespeichert sind, und ich öffne die gleiche Seite auf einem anderen Gerät, habe ich dort keinen Zugriff auf diese Daten - denn die liegen ja nicht auf der Internetseite, sondern nur auf meinem anderen Gerät.
Εrnst B. schrieb: > Und wenn einer wegen "DSGVO! Lösch all meine Daten!" ankommt, gibt's > eine Anleitung zum Cookie-Löschen als Antwort. > Wie machst du das, wenn die Daten Serverseitig liegen, aber nur mit > einer ID im Cookie verknüpft sind? Die Lösch-Aufforderung muss die > Cookie-ID nicht mit enthalten, löschen musst du die Daten trotzdem. DIe DSGVO ist ein zahnloser Tiger. Du musst eben doch verlangen, dass dir entweder die ID mitgeteilt wird und wenn Name und ID getrennt nicht miteinander in Verbindung gebracht werden können musst du gar nichts machen. Außerdem gab es noch nie Fälle wo eine Behörde wirklich in deine Datenbankstruktur schaut und nachvollziehen will, ob du am Ende des Tages wirklich gelöscht hast. Das können die auch gar nicht leisten.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.