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

Naja...

  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. Zum Login

Stellenmarkt
  1. über duerenhoff GmbH, Raum Ingolstadt
  2. Kassenärztliche Vereinigung Mecklenburg-Vorpommern, Schwerin
  3. NetCom BW GmbH, Ellwangen
  4. DATAGROUP Köln GmbH, Frankfurt am Main

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. täglich neue Deals bei Alternate.de


Haben wir etwas übersehen?

E-Mail an news@golem.de


Razer Blade Stealth 13 im Test: Sieg auf ganzer Linie
Razer Blade Stealth 13 im Test
Sieg auf ganzer Linie

Gute Spieleleistung, gute Akkulaufzeit, helles Display und eine exzellente Tastatur: Mit dem Razer Blade Stealth 13 machen Käufer eigentlich kaum einen Fehler - es sei denn, sie kaufen die 4K-Version.
Ein Test von Oliver Nickel

  1. Naga Left-Handed Edition Razer will seine Linkshändermaus wieder anbieten
  2. Junglecat Razer-Controller macht das Smartphone zur Switch
  3. Tartarus Pro Razers Tastenpad hat zwei einstellbare Schaltpunkte

Minikonsolen im Video-Vergleichstest: Die sieben sinnlosen Zwerge
Minikonsolen im Video-Vergleichstest
Die sieben sinnlosen Zwerge

Golem retro_ Eigentlich sollten wir die kleinen Retrokonsolen mögen. Aber bei mittelmäßiger Emulation, schlechter Steuerung und Verarbeitung wollten wir beim Testen mitunter über die sieben Berge flüchten.
Ein Test von Martin Wolf


    Jobs: Spielebranche sucht Entwickler (m/w/d)
    Jobs
    Spielebranche sucht Entwickler (m/w/d)

    Die Hälfte aller Gamer ist weiblich. An der Entwicklung von Spielen sind aber nach wie vor deutlich weniger Frauen beteiligt.
    Von Daniel Ziegener

    1. Medizinsoftware Forscher finden "rassistische Vorurteile" in Algorithmus
    2. Mordhau Toxische Spieler und Filter für Frauenhasser

    1. Raumfahrt: Die Esa lässt den Weltraum säubern
      Raumfahrt
      Die Esa lässt den Weltraum säubern

      Es ist voll in der Erdumlaufbahn: Immer mehr Satelliten kreisen im Orbit, und auch immer mehr Weltraumschrott. Die einzige Möglichkeit, des Problems Herr zu werden, ist laut Esa, ihn zu beseitigen. Für 2025 ist die erste europäische Aufräummission geplant.

    2. San José: Bosch und Daimler starten autonomen Taxidienst
      San José
      Bosch und Daimler starten autonomen Taxidienst

      Nach Waymo und Uber testen auch deutsche Firmen selbstfahrende Taxiflotten in den USA. Bosch und Daimler geht es dabei nicht nur um die Entwicklung autonomer Autos.

    3. Sachsen-Anhalt: Großes kommunales Netz startet mit 500 MBit/s für alle
      Sachsen-Anhalt
      Großes kommunales Netz startet mit 500 MBit/s für alle

      Im Landkreis Börde hat das Großprojekt Glasfaserausbau von ARGE Breitband und DNS:NET ein erstes Teilgebiet fertiggestellt. Die Datenraten sind sehr hoch.


    1. 18:55

    2. 18:42

    3. 18:21

    4. 18:04

    5. 17:38

    6. 16:32

    7. 16:26

    8. 15:59