1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Security: Cookies können…

Naja...

Helft uns, die neuen Foren besser zu machen! Unsere kleine Umfrage dauert nur wenige Sekunden!
  1. Thema

Neues Thema Ansicht wechseln


  1. Naja...

    Autor: thecrow2k 25.09.15 - 12:20

    Die im Paper beschriebenen Angriffe sind relativ komplex und IMHO ist die Basis immer eine handwerklich schlecht implementierte Funktion - typischweise fehlt das Escaping der Werte aus den Cookies.

    In einer state-of-the-art Webapplikation sollten abgesehen von einer Session-ID überhaupt keine Werte mehr in Cookies abgelegt werden.

    Bleibt der Angriff einer manipulierten Subdomain auf die Hauptdomain, z.B. via Session-Hijacking. Dieser Vektor ist aber eigentlich schon lange bekannt - da sollte man einfach mit Subdomains vorsichtig sein. Bzw. sie für wichtige Seiten nicht zulassen.

  2. Re: Naja...

    Autor: User_x 25.09.15 - 12:45

    Interessant wäre es, ob man damit über die TLD .de oder .com etc. Angriffe starten könnte?

  3. Re: Naja...

    Autor: Xiut 25.09.15 - 13:05

    User_x schrieb:
    --------------------------------------------------------------------------------
    > Interessant wäre es, ob man damit über die TLD .de oder .com etc. Angriffe
    > starten könnte?

    Dürfte nicht möglich sein, weil z.B. golem.de und golem.com zwei komplett verschiedene Domains sind und man einfach nur einen Cookie für auch "tiefere" Ebenen der Domain "freigeben" kann.

    Also auf golem.de könnte man .golem.de verwenden, damit der Cookie auf allen golem.de Subdomains und allgemein golem.de zur Verfügung steht oder eben z.B. subdomain.golem.de, damit der Cookie nur für die entsprechende Subdomain zur Verfügung steht.

    Sonst würden sich ja auch viele Seiten, die einfach nur eine andere TLD haben in die Quere kommen, auch wenn es kein absichtlicher Angriff ist, nur weil z.B. der Cookie für die Session-ID gleich heißt. Und das ist ja nicht selten, dass diese dann auch verschiedene Inhaber haben.
    Bei Subdomains ist das deutlich seltener. Höchsten bei so kostenlosen Hostern oder so, aber die haben ja entsprechende Möglichkeiten, dass wichtige Cookies nur unter bestimmten Domains zur Verfügung stehen.

  4. Re: Naja...

    Autor: razer 25.09.15 - 14:08

    und selbst dann werden sie bei gängigen frameworks stets verschlüsselt abgespeichert, bspw bei laravel. Da weiss der client nicht mal welche daten überhaupt abgelegt werden

  5. Re: Naja...

    Autor: User_x 25.09.15 - 14:19

    Ich dachte eher an seite1.de zu seite2.de - da wäre .de der gleiche nenner, aber wird denke ich mal eh nicht ins Gewicht fallen...

  6. Re: Naja...

    Autor: LordSiesta 25.09.15 - 14:29

    thecrow2k schrieb:
    --------------------------------------------------------------------------------
    > In einer state-of-the-art Webapplikation sollten abgesehen von einer
    > Session-ID überhaupt keine Werte mehr in Cookies abgelegt werden.

    Und wie soll man dann die »angemeldet bleiben«-Funktion realisieren?

  7. Re: Naja...

    Autor: Xiut 25.09.15 - 14:35

    LordSiesta schrieb:
    --------------------------------------------------------------------------------
    > thecrow2k schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > In einer state-of-the-art Webapplikation sollten abgesehen von einer
    > > Session-ID überhaupt keine Werte mehr in Cookies abgelegt werden.
    >
    > Und wie soll man dann die »angemeldet bleiben«-Funktion realisieren?

    Theoretisch könnte man ja einfach das Verfallsdatum des Cookies mit der Session-ID verlängern, aber ich bezweifel stark, dass das so eine gute Idee ist.

    Es ist ja auch kein Problem für bestimmte Funktionen Cookies zu verwenden. Man sollte nur wissen, wie man mit Cookies umgehen sollte. Vor allem, wenn Cookies eh verschlüsselt und signiert im Browser gespeichert werden, kann mögliche Angriffe sehr verschweren und dann, wenn auch Cookies mit der nötigen Sorgfalt behandelt werden, wird sich ein solcher Angriff eh nicht mehr lohnen.

  8. Re: Naja...

    Autor: thecrow2k 25.09.15 - 14:52

    LordSiesta schrieb:
    --------------------------------------------------------------------------------
    > thecrow2k schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > In einer state-of-the-art Webapplikation sollten abgesehen von einer
    > > Session-ID überhaupt keine Werte mehr in Cookies abgelegt werden.
    >
    > Und wie soll man dann die »angemeldet bleiben«-Funktion realisieren?

    Überleg mal anders herum: Wenn nicht über eine Session-ID, wie willst Du den User sicher wiedererkennen? Die einzige Möglichkeit ist, das Expiry-Date des Session-ID Cookies hochzusetzen - mit allen damit verbundenen Risiken.

  9. Re: Naja...

    Autor: Xiut 25.09.15 - 15:32

    thecrow2k schrieb:
    --------------------------------------------------------------------------------
    > LordSiesta schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > thecrow2k schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > In einer state-of-the-art Webapplikation sollten abgesehen von einer
    > > > Session-ID überhaupt keine Werte mehr in Cookies abgelegt werden.
    > >
    > > Und wie soll man dann die »angemeldet bleiben«-Funktion realisieren?
    >
    > Überleg mal anders herum: Wenn nicht über eine Session-ID, wie willst Du
    > den User sicher wiedererkennen? Die einzige Möglichkeit ist, das
    > Expiry-Date des Session-ID Cookies hochzusetzen - mit allen damit
    > verbundenen Risiken.

    Entsprechend einen zusätzlichen Token sicher generieren und durch geschicktes signieren + verschlüsseln und gegebenenfalls noch einen Mechanismus, um den Cookie wirklich nur für diesen einen Computer gültig werden zu lassen, vor Angriffen schützen.

    So kann man unabhängig von der Session auch dem Nutzer die Möglichkeit geben, dass er z.B. von zu Hause das "angemeldet bleiben" an dem PC in der Schule rückgängig macht, indem der entsprechende Token aus der Datenbank entfernt wird und somit ungültig ist.

    Natürlich wirkt das auf den ersten Blick wie eine zweite Session ID, nur werden ja oft noch mehr als nur der Nutzer, der angemeldet ist, in einer Session gespeichert bzw. mit dieser verknüpft.

  10. Re: Naja...

    Autor: thecrow2k 25.09.15 - 17:01

    Xiut schrieb:
    --------------------------------------------------------------------------------
    >
    > Entsprechend einen zusätzlichen Token sicher generieren und durch
    > geschicktes signieren + verschlüsseln und gegebenenfalls noch einen
    > Mechanismus, um den Cookie wirklich nur für diesen einen Computer gültig
    > werden zu lassen, vor Angriffen schützen.

    Das klingt schön, lässt sich aber mit Cookies nicht erreichen. Dafür braucht man einen private Key, den der Browser nicht heraus gibt, das funktioniert nicht mit Cookies. Die passende Technologie für so etwas ist der Login mit Zertifikaten - geht übrigens mit den gängigen Browsern.

    > ...nur werden ja oft noch mehr als nur der Nutzer, der angemeldet ist, in einer
    > Session gespeichert bzw. mit dieser verknüpft.

    Ganz schlechte Idee. Session IDs können vom selben Container verwaltet werden, aber niemals dürfen sich User eine Session ID teilen. Ansonsten ist die ID Nutzlos, bzw. es handelt sich überhaupt nicht um eine Session ID.

    Sehr wohl kann anders herum ein User natürlich gleichzeitig unter mehreren Session IDs angemeldet sein (damit löst sich auch das o.g. Problem: unterschiedliche Timeouts der Session Cookies je Browser/Gerät)

  11. Re: Naja...

    Autor: Xiut 25.09.15 - 17:22

    thecrow2k schrieb:
    --------------------------------------------------------------------------------
    > Xiut schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > >
    > > Entsprechend einen zusätzlichen Token sicher generieren und durch
    > > geschicktes signieren + verschlüsseln und gegebenenfalls noch einen
    > > Mechanismus, um den Cookie wirklich nur für diesen einen Computer gültig
    > > werden zu lassen, vor Angriffen schützen.
    >
    > Das klingt schön, lässt sich aber mit Cookies nicht erreichen. Dafür
    > braucht man einen private Key, den der Browser nicht heraus gibt, das
    > funktioniert nicht mit Cookies. Die passende Technologie für so etwas ist
    > der Login mit Zertifikaten - geht übrigens mit den gängigen Browsern.

    Signieren ist nicht nur mit einem Private Key möglich und verschlüsseln erst recht nicht.
    Der Browser muss schließlich auch den Inhalt des Cookies nicht kennen.
    Also kann man den Inhalt des Cookies einfach mit AES verschlüsseln und der Schlüssel dafür verlässt nie den Server und zusätzlich wird er auch noch einmal signiert, um Manipulationen leichter zu erkennen.
    Dass das wirklich möglich ist zeigen ja auch Frameworks wie z.B. eben das PHP Framework Laravel.

    Weiß also nicht, wo da jetzt das Problem sein soll...

    > > ...nur werden ja oft noch mehr als nur der Nutzer, der angemeldet ist, in
    > einer
    > > Session gespeichert bzw. mit dieser verknüpft.
    >
    > Ganz schlechte Idee. Session IDs können vom selben Container verwaltet
    > werden, aber niemals dürfen sich User eine Session ID teilen. Ansonsten ist
    > die ID Nutzlos, bzw. es handelt sich überhaupt nicht um eine Session ID.
    >
    > Sehr wohl kann anders herum ein User natürlich gleichzeitig unter mehreren
    > Session IDs angemeldet sein (damit löst sich auch das o.g. Problem:
    > unterschiedliche Timeouts der Session Cookies je Browser/Gerät)

    Ich habe auch nicht geschrieben oder gemeint, dass eine Session-ID mit mehreren Nutzern verknüpft wird, sondern mehr Daten als nur die Information, als welcher Nutzer sich derjenige mit dieser Session-ID angemeldet hat.
    So können auch andere Daten mit der Session-ID verknüpft werden, die nicht generell z.B. zu dem Nutzer gehören, sondern eben nur zu der jeweiligen Session.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. GK Software SE, verschiedene Standorte (Home-Office möglich)
  2. RIEDEL Communications GmbH & Co. KG, Wuppertal
  3. CC-Pharma GmbH, Densborn
  4. Omikron Data Quality GmbH, Berlin, Pforzheim

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. Angebote zu Spielen, PC- und Konsolen-Zubehör, Laptops und Fernsehern)
  2. (u. a. LG OLED65CX9LA 65 Zoll OLED 120Hz für 1.799€, Sony KE-85XH9096 85 Zoll LED für 1...
  3. 745€ (Bestpreis)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Programm für IT-Jobeinstieg: Hoffen auf den Klebeeffekt
Programm für IT-Jobeinstieg
Hoffen auf den Klebeeffekt

Aktuell ist der Jobeinstieg für junge Ingenieure und Informatiker schwer. Um ihnen zu helfen, hat das Land Baden-Württemberg eine interessante Idee: Es macht sich selbst zur Zeitarbeitsfirma.
Ein Bericht von Peter Ilg

  1. Arbeitszeit Das Sechs-Stunden-Experiment bei Sipgate
  2. Neuorientierung im IT-Job Endlich mal machen!
  3. IT-Unternehmen Die richtige Software für ein Projekt finden

Weclapp-CTO Ertan Özdil: Wir dürfen nicht in Schönheit und Perfektion untergehen!
Weclapp-CTO Ertan Özdil
"Wir dürfen nicht in Schönheit und Perfektion untergehen!"

Der CTO von Weclapp träumt von smarter Software, die menschliches Eingreifen in der nächsten ERP-Generation reduziert. Deutschen Perfektionismus hält Ertan Özdil aber für gefährlich.
Ein Interview von Maja Hoock


    Fiat 500 als E-Auto im Test: Kleinstwagen mit großem Potenzial
    Fiat 500 als E-Auto im Test
    Kleinstwagen mit großem Potenzial

    Fiat hat einen neuen 500er entwickelt. Der Kleine fährt elektrisch - und zwar richtig gut.
    Ein Test von Peter Ilg

    1. Vierradlenkung Elektrischer GMC Hummer SUV fährt im Krabbengang seitwärts
    2. MG Cyberster MG B Roadster mit Lasergürtel und Union Jack
    3. Elektroauto E-Auto-Prämie übersteigt in 2021 schon Vorjahressumme