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

Frage

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

Neues Thema Ansicht wechseln


  1. Frage

    Autor: Netspy 25.09.15 - 12:11

    > Denkbar ist, dass ein Angreifer bei einer Kommunikation mit einer unverschlüsselten Subdomain, etwa foo.beispiel.com, ein Cookie mit dem Domain-Attribut beispiel.com setzt.

    Ok, das ist klar und ließe sich einfach vermeiden, indem man nur verschlüsselte Verbindungen nutzt.

    > Eine spätere Verbindung mit der Seite bar.beispiel.com könnte dann über das manipulierte Cookie von Angreifern mitgelesen werden, selbst wenn sie verschlüsselt ist.

    Wie bitte soll das funktionieren? Der vorher gesetzte Cookie ist zwar noch gesetzt, wie bitte soll aber da ein Angreifer die Verbindung mitlesen können? Ein Cookie ist eine Textdatei, die im Browser gespeichert ist und die überträgt keine Daten zu irgendwelchen Angreifern.

  2. Re: Frage

    Autor: FibreFoX 25.09.15 - 12:21

    Ich glaube das Problem ist, dass man Cookies zu viel Vertrauen schenkt.

    Ansich geht es bei der Problematik darum, dass ich im Browser ein Cookie reinfriemeln kann (egal ob per Javascript oder per Tool oder Testdatei), und dann später bei einer HTTPS-Verbindung dies auch wirklich verwendet wird.

    Wirklich sinnvoll ist der Artikel jedoch nicht, es ist mal wieder Panikmache ;) es ist Freitag. Eine Text-Datei KANN NICHT dafür sein, nur die Applikation, die diese Informationen für echt hält nicht nochmal prüft, was drin steht.

  3. Re: Frage

    Autor: frustbox 25.09.15 - 12:27

    Netspy schrieb:
    --------------------------------------------------------------------------------
    > Wie bitte soll das funktionieren? Der vorher gesetzte Cookie ist zwar noch
    > gesetzt, wie bitte soll aber da ein Angreifer die Verbindung mitlesen
    > können? Ein Cookie ist eine Textdatei, die im Browser gespeichert ist und
    > die überträgt keine Daten zu irgendwelchen Angreifern.

    Mir gefällt die Formulierung im Artikel auch nicht. Klingt so, als würden Cookies selbständig irgendwas machen und Schadcode ausführen können, was nicht der Fall ist. In der Quelle ist es besser formuliert:
    > for example, an attacker may set cookies for example.com that override the real cookie for www.example.com when the victim is loading HTTPS content. By exploiting other weaknesses in the server, the attacker-controlled cookie may be used to obtain private information.

    other weaknesses – das Problem sind also gar nicht die Cookies ...

  4. Re: Frage

    Autor: Xiut 25.09.15 - 12:29

    Ich sehe auch kein Problem mit Cookies an sich. Eher damit, dass viele Entwickler einfach nicht begreifen oder vielleicht auch einfach nur immer wieder vergessen, dass Cookies auch vom Nutzer gesetzt oder anderweitig manipuliert werden können.

    Ich will nicht wissen, wie viele Daten aus Cookies einfach ohne Filterung/Validierung verwendet werden, nur weil der Entwickler denkt, dass er sie ja selbst setzt und niemand sonst darauf zugreifen kann, weshalb er dem Inhalt entsprechend blind vertraut...

    Aber um Cookies wirklich für irgendwas missbrauchen zu können, muss ja vorher schon woanders eine Sicherheitslücke bestehen. Zudem kann man den Zugriff per JavaScript auf alle oder einzelne Cookies verhindern oder auch das Übertragen der Cookies über unsichere Subdomains oder auch generell die Übertragung nur über HTTPS gestatten.
    Und wenn man bestimmte Cookies noch besser schützen möchte, kann man sie auch entsprechend verschlüsseln und/oder signieren, wie es z.B. das PHP Framework Laravel macht.

    Wahrscheinlich wurde die Überschrift des Artikels einfach extra so gewählt, um eine gewisse Panik auszulösen und entsprechend mehr Klicks zu generieren. Schade, dass man so etwas heute als Journalist so nötig hat...

  5. Re: Frage

    Autor: hg (Golem.de) 25.09.15 - 12:49

    Danke für die Hinweise. Das ist in der Tat etwas mißverständlich formuliert - ich werde es überarbeiten und präzisieren.

    Hauke Gierow - Golem.de

  6. Re: Frage

    Autor: smonkey 25.09.15 - 14:18

    > Eine HTTPS-Verbindung kann demnach nicht prüfen, ob das Cookie durch eine sichere Verbindung ausgestellt wurde oder über eine unsichere.

    Gerade das, sollte doch das secure-Flag (https://de.wikipedia.org/wiki/HTTP-Cookie#Cookies_nach_RFC_2109) verhindern?

    Okay, verstanden. Damit geht auch das Paper los:

    >A cookie can contain a “secure” flag, indicating that it should be only sent over an HTTPS connection. Yet there is no corresponding flag to indicate how a cookie was set: attackers who act as a man-in-the-midddle even temporarily on an HTTP session can inject cookies which will be attached to subsequent HTTPS connections.
    https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-zheng-updated.pdf



    2 mal bearbeitet, zuletzt am 25.09.15 14:25 durch smonkey.

  7. Re: Frage

    Autor: Vanger 25.09.15 - 15:39

    Genau das hab ich mich schon immer gefragt: Warum akzeptiert der Browser ein Cookie mit Secure-Flag, das nicht über HTTPS übertragen wurde? Die Grundidee ist ja gerade, dass das Cookie nur mit HTTPS nutzbar ist. Der Use Case bei dem man ein Cookie für HTTPS per HTTP setzen möchte ist mir unklar... Das gehört schlichtweg geändert.

  8. Re: Frage

    Autor: elf 25.09.15 - 22:30

    Was mich eher irritiert ist, dass der "Angreifer" ja auch verschlüsselte Verbindungen bereitstellen kann. Dann wäre eine separate Prüfung auf https sowieso irrelevant für den Browser.

  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. über Hays AG, Baden-Württemberg
  2. über duerenhoff GmbH, Heidelberg
  3. über grinnberg GmbH, Frankfurt am Main
  4. Dürr IT Service GmbH, Bietigheim-Bissingen

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote


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