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

Frage

  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.

    ----
    www.dynamicfiles.de - Projekt- und Portfolio-Seite

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

Stellenmarkt
  1. ANDRITZ Fiedler GmbH, Regensburg
  2. PROSIS GmbH, verschiedene Standorte
  3. ConceptPeople consulting gmbh, Hamburg
  4. Deloitte, Frankfurt am Main, Hamburg, München, Berlin, Düsseldorf

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 29,99€
  2. 4,32€
  3. 4,99€
  4. 19,95€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Echo Dot mit Uhr und Nest Mini im Test: Amazon hängt Google ab
Echo Dot mit Uhr und Nest Mini im Test
Amazon hängt Google ab

Amazon und Google haben ihre kompakten smarten Lautsprecher überarbeitet. Wir haben den Nest Mini mit dem neuen Echo Dot mit Uhr verglichen. Google hat es sichtlich schwer, konkurrenzfähig zu Amazon zu bleiben.
Ein Test von Ingo Pakalski

  1. Digitale Assistenten Amazon verkauft dreimal mehr smarte Lautsprecher als Google
  2. Googles Hardware-Chef Osterloh weist Besuch auf smarte Lautsprecher hin
  3. Telekom Smart Speaker im Test Der smarte Lautsprecher, der mit zwei Zungen spricht

Threadripper 3970X/3960X im Test: AMD wird uneinholbar
Threadripper 3970X/3960X im Test
AMD wird uneinholbar

7-nm-Fertigung, Zen-2-Architektur und dank Chiplet-Design keine Scheduler-Probleme unter Windows 10: AMDs Threadripper v3 überzeugen auf voller Linie, die CPUs wie die Plattform. Intel hat im HEDT-Segment dem schlicht nichts entgegenzusetzen. Einzig Aufrüster dürften sich ärgern.
Ein Test von Marc Sauter

  1. Via Technologies Centaur zeigt x86-Chip mit AI-Block
  2. Nuvia Apples Chip-Chefarchitekt gründet CPU-Startup
  3. Tiger Lake Intel bestätigt 10-nm-Desktop-CPUs

Mobile-Games-Auslese: Märchen-Diablo für Mobile-Geräte
Mobile-Games-Auslese
Märchen-Diablo für Mobile-Geräte

"Einarmiger Schmied" als Klasse? Diablo bietet das nicht - das wunderschöne Yaga schon. Auch sonst finden sich in der neuen Mobile-Games-Auslese viele spannende und originelle Perlen.
Von Rainer Sigl

  1. Mobile-Games-Auslese Fantasypixel und Verkehrsplanung für unterwegs
  2. Mobile-Games-Auslese Superheld und Schlapphutträger zu Besuch im Smartphone
  3. Mobile-Games-Auslese Verdrehte Räume und verrückte Zombies für unterwegs

  1. Pentium G3420: Intel verkauft 22-nm-Prozessor von 2013 wieder
    Pentium G3420
    Intel verkauft 22-nm-Prozessor von 2013 wieder

    Die 14-nm-Knappheit bei Intel wird obskur: Der Hersteller hat den Pentium G3420 von 2013 erneut ins Angebot aufgenommen. Der 22-nm-Haswell-Chip ist eigentlich längst ausgelaufen, wird aber reanimiert.

  2. Breitbandausbau: Bernie Sanders will Internet- und Kabelkonzerne zerschlagen
    Breitbandausbau
    Bernie Sanders will Internet- und Kabelkonzerne zerschlagen

    US-Senator Bernie Sanders hat seinen Plan für den Breitbandausbau besonders in ländlichen und armen Regionen der USA vorgelegt. Er will Konzerne zerschlagen und kommunale Strukturen stark fördern.

  3. Korruption: Ericsson zahlt über 1 Milliarde US-Dollar Strafe in den USA
    Korruption
    Ericsson zahlt über 1 Milliarde US-Dollar Strafe in den USA

    Der europäische 5G-Hoffnungsträger war in mehreren Staaten in Korruptionsfälle verwickelt. Die Ericsson-Konzernführung hat dies eingestanden. In den USA zahlt das Unternehmen eine hohe Strafe.


  1. 17:32

  2. 15:17

  3. 14:06

  4. 13:33

  5. 12:13

  6. 17:28

  7. 15:19

  8. 15:03